www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - religious programming

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I can't keep it in any more, I have to share.

I've seen lots of corporate C++ code and coding guidelines and I came
to the conclusion, that they're all bogus.
The vast majority of code, being written in commercial projects use a
very limited subset of the language they use.
The code I work with currently is a purely object-oriented C++ code.
I used to like object-oriented programming until I started working
with that code.
Corporate code is very religious. They use a few specialized
techniques for everything.
They use object-oriented programming when functional programming is
the technique of choice.
They use object-oriented programming when generic programming is the
technique of choice.
The code is unimaginably bloated, flooded with thousands of tiny
redundant classes, each of which do a primitive task, which doesn't
need to be a class at all.
I've discussed D with my colleagues lately and the vast multi-paradigm
and built-in featured of D were discarded with a religious "There's a
class already written for that.".
Why do I keep saying "religious"? Because they are convinced, that
this is the way to go and do not accept any logical arguments.
Why do I talk about this at all? Because corporate code is the one we
need to become D.
But this is not gonna happen with such religious attitude to programming.
They say built-in arrays are useless, because there's always
std::vector and std::list.
They say, functional programming and lambdas are useless, because you
can make functors and base classes for them.
They say garbage collection is useless, because there's always std::shared_ptr.
Well, yes. You do have all that. But look what the code looks like and
how fast it runs!

It's amazing how stupid and ignorant can corporate developers be
sometimes and how smart and considerate open-source developers can be.
I don't know how to cure the people's minds from this religious
plague, that poisons the software development industry.

Can anyone help me out in this quest of enlightening people?
Oct 11 2011
next sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 11.10.2011, 11:57 Uhr, schrieb Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com>:


 I don't know how to cure the people's minds from this religious
 plague, that poisons the software development industry.

 Can anyone help me out in this quest of enlightening people?


So you want to convert the barbarians? Then you must accept, that you  
yourself are a religious person about multi-paradigm programming. Yes the  
devil lies within everyone of us. I have been writing code in Java and it  
is OOP exclusively. The point is, that companies want a language that does  
things one way. It is easy to share code this way and to train programmers  
in that language. There is no "oh what is that construct doing?" in Java  
because the language is primitive and pretty verbose. It is also easier  
for me to only have a few concepts in my head when I write code. Maybe it  
is also the way I'm wired. Everything is an object the has to do X and  
works together with Y and Z is a concept that I can easily apply to almost  
everything.

If these C++ programmers you talk about like the restrictive use of  
language features, then you should respect that. They may have had a hard  
in the past with people writing code like Picasso. I mean, good code that  
uses features that were difficult for others to understand at first. If  
you don't understand other people's code you are likely to introduce bugs.  
As long as they aren't open to what really makes them stick to their style  
rules and language it is hard to say what would make them consider D.  
After all the pitfalls in D will be more confusing to them coming from C++  
than any C++ code could ever be.

Maybe they like the integrated unit tests. I've heard people are more  
likely to actually write them if they are integrated like that. Or at some  
point they say "if I could just define what the object state must be after  
this public method exits I wouldn't have this bug now!" and contracts come  
into play. Anyway, don't put C++ down unless they are open to speak about  
what they wish for and are willing to accept new ideas.
Oct 11 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
You got good points.
Java is indeed a very simple and safe language. But it's a straitjacket.
Java is filled with techniques, developed as workarounds to compensate
for the lack of other paradigms.
All the arguments about ease of collaborative development comes from
developers' unwillingness to learn and pay attention.
At this rate the entire software industry could be build on the idea
that no-one wants to work properly.

On Tue, Oct 11, 2011 at 2:38 PM, Marco Leise <Marco.Leise gmx.de> wrote:

 Am 11.10.2011, 11:57 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I don't know how to cure the people's minds from this religious
 plague, that poisons the software development industry.

 Can anyone help me out in this quest of enlightening people?


 So you want to convert the barbarians? Then you must accept, that you
 yourself are a religious person about multi-paradigm programming. Yes the
 devil lies within everyone of us. I have been writing code in Java and it is
 OOP exclusively. The point is, that companies want a language that does
 things one way. It is easy to share code this way and to train programmers
 in that language. There is no "oh what is that construct doing?" in Java
 because the language is primitive and pretty verbose. It is also easier for
 me to only have a few concepts in my head when I write code. Maybe it is
 also the way I'm wired. Everything is an object the has to do X and works
 together with Y and Z is a concept that I can easily apply to almost
 everything.

 If these C++ programmers you talk about like the restrictive use of language
 features, then you should respect that. They may have had a hard in the past
 with people writing code like Picasso. I mean, good code that uses features
 that were difficult for others to understand at first. If you don't
 understand other people's code you are likely to introduce bugs. As long as
 they aren't open to what really makes them stick to their style rules and
 language it is hard to say what would make them consider D. After all the
 pitfalls in D will be more confusing to them coming from C++ than any C++
 code could ever be.

 Maybe they like the integrated unit tests. I've heard people are more likely
 to actually write them if they are integrated like that. Or at some point
 they say "if I could just define what the object state must be after this
 public method exits I wouldn't have this bug now!" and contracts come into
 play. Anyway, don't put C++ down unless they are open to speak about what
 they wish for and are willing to accept new ideas.
Oct 11 2011
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
Hi,

you fail to see why this is this way.

Corporate code does not have a soul. Every code line needs to be understood 
by
everyone. Regardless if they have a PhD in computer science or just learned 
programming
on the weekends.

Plus the code needs to be simple enough, so that in the course of few months 
you are able
to transfer code ownership to any country in the world, depending on project 
budget.

This is one of the main reasons why the so called "blue collar" languages 
like Java thrive in
the enterprise world.

I don't like this, but it won't change.

If I sound too harsh, maybe I just had too many corporate projects in my 
life.

--
Paulo

"Gor Gyolchanyan" <gor.f.gyolchanyan gmail.com> wrote in message 
news:mailman.37.1318327068.24802.digitalmars-d puremagic.com...

I can't keep it in any more, I have to share.

 I've seen lots of corporate C++ code and coding guidelines and I came
 to the conclusion, that they're all bogus.
 The vast majority of code, being written in commercial projects use a
 very limited subset of the language they use.
 The code I work with currently is a purely object-oriented C++ code.
 I used to like object-oriented programming until I started working
 with that code.
 Corporate code is very religious. They use a few specialized
 techniques for everything.
 They use object-oriented programming when functional programming is
 the technique of choice.
 They use object-oriented programming when generic programming is the
 technique of choice.
 The code is unimaginably bloated, flooded with thousands of tiny
 redundant classes, each of which do a primitive task, which doesn't
 need to be a class at all.
 I've discussed D with my colleagues lately and the vast multi-paradigm
 and built-in featured of D were discarded with a religious "There's a
 class already written for that.".
 Why do I keep saying "religious"? Because they are convinced, that
 this is the way to go and do not accept any logical arguments.
 Why do I talk about this at all? Because corporate code is the one we
 need to become D.
 But this is not gonna happen with such religious attitude to programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.
 They say garbage collection is useless, because there's always 
 std::shared_ptr.
 Well, yes. You do have all that. But look what the code looks like and
 how fast it runs!

 It's amazing how stupid and ignorant can corporate developers be
 sometimes and how smart and considerate open-source developers can be.
 I don't know how to cure the people's minds from this religious
 plague, that poisons the software development industry.

 Can anyone help me out in this quest of enlightening people?
Oct 11 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Gor Gyolchanyan:


 Can anyone help me out in this quest of enlightening people?


Talking about "enlightening people" means assuming a bad starting point, where
you are as much religious as them.

And regarding them, I think that reading books and articles helps widen the
mind a bit. But people have families, children and many hours of work every
day. They are often stopped training their brains as they used to do in very
good schools. Pushing new knowledge into a middle aged brain requires energy
and a bit of pain, not everyone is willing to endure this year after year, in
presence of all other kinds of family and work and health problems. Reducing
the amount of daily work hours to something like 6 helps leave some time to
read books too.

-----------------------

Marco Leise:


The point is, that companies want a language that does things one way. It is
easy to share code this way and to train programmers in that language. There is
no "oh what is that construct doing?" in Java because the language is primitive
and pretty verbose. It is also easier for me to only have a few concepts in my
head when I write code.<


When I program in D I often find several different ways to solve a problem,
with a functional, or with an OOP solution, or with a high level one, or with a
lower level one, or with generic code. Often my first solution is not the best,
and I rewrite the code in a different way. A language that offers only one
programming paradigm avoids this, and this is has its advantages.

Single-paradigm languages (Smalltalk, Haskell) and multi-paradigm ones (Oz, D,
Scala) have both advantages and disadvantages. A language like Scala (and in
past CommonLisp) is very good in the hands of an expert programmer, able to
make it sing like a Stradivari violin. But in the hands of a less skilled
programmer, or a skilled programmer that needs to write certain commercial
programs, a less flexible language is often better.

Regarding Java, it's simpler, but this is especially true if you have to use it
to solve simple problems. If you have to implement a complex algorithm that
works with differently shaped trees, efficiently, doing pattern matching on
them, etc, then a language like OcaML becomes more appreciable that what it
usually is.

The Java simplicity forces you to push part of the program complexity out of
the language and into conventions, patterns, IDE skills, IDE shorcuts, that
increase again the apparent simplicity of Java coding. Generally it's hard to
destroy the complexity, you often just move it around.

Bye,
bearophile
Oct 11 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
You're the second person to say I'm also religious, but you miss the
point of religious programming:
I'm always open to new techniques. I constantly research for new and
better ways of doing what I'm about to do.
My approach to getting things done is dynamic and i never praise my
techniques as the best in the world and fit for every purpose.

About troubles at home and effort: It doesn't take much effort to
learn a language. It doesn't take much effort to pay attention to the
code you read and write. It's just a matter of a habit. Some people
are careful, some people are sloppy, some people are progressive, some
people are lazy.
I have my own family to take care of and I have my own projects to
develop, but it doesn't stop me from being careful and neat with what
i write.
It's just a matter of a habit.

About paradigms. The need for a limited language comes form the fact,
that people don't write maintainable code. Even if a team uses C++
with lots of address arithmetic and obscure type casts it's always
possible to make it easy to read.
Every level of programming and every paradigm has it's ways of writing
a neat and maintainable code.

On Tue, Oct 11, 2011 at 3:39 PM, bearophile <bearophileHUGS lycos.com> wrot=
e:

 Gor Gyolchanyan:


 Can anyone help me out in this quest of enlightening people?


 Talking about "enlightening people" means assuming a bad starting point, =


where you are as much religious as them.

 And regarding them, I think that reading books and articles helps widen t=


he mind a bit. But people have families, children and many hours of work ev=
ery day. They are often stopped training their brains as they used to do in=
 very good schools. Pushing new knowledge into a middle aged brain requires=
 energy and a bit of pain, not everyone is willing to endure this year afte=
r year, in presence of all other kinds of family and work and health proble=
ms. Reducing the amount of daily work hours to something like 6 helps leave=
 some time to read books too.

 -----------------------

 Marco Leise:


The point is, that companies want a language that does things one way. It=




 is easy to share code this way and to train programmers in that language. =
There is no "oh what is that construct doing?" in Java because the language=
 is primitive and pretty verbose. It is also easier for me to only have a f=
ew concepts in my head when I write code.<

 When I program in D I often find several different ways to solve a proble=


m, with a functional, or with an OOP solution, or with a high level one, or=
 with a lower level one, or with generic code. Often my first solution is n=
ot the best, and I rewrite the code in a different way. A language that off=
ers only one programming paradigm avoids this, and this is has its advantag=
es.

 Single-paradigm languages (Smalltalk, Haskell) and multi-paradigm ones (O=


z, D, Scala) have both advantages and disadvantages. A language like Scala =
(and in past CommonLisp) is very good in the hands of an expert programmer,=
 able to make it sing like a Stradivari violin. But in the hands of a less =
skilled programmer, or a skilled programmer that needs to write certain com=
mercial programs, a less flexible language is often better.

 Regarding Java, it's simpler, but this is especially true if you have to =


use it to solve simple problems. If you have to implement a complex algorit=
hm that works with differently shaped trees, efficiently, doing pattern mat=
ching on them, etc, then a language like OcaML becomes more appreciable tha=
t what it usually is.

 The Java simplicity forces you to push part of the program complexity out=


 of the language and into conventions, patterns, IDE skills, IDE shorcuts, =
that increase again the apparent simplicity of Java coding. Generally it's =
hard to destroy the complexity, you often just move it around.

 Bye,
 bearophile
Oct 11 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Gor Gyolchanyan Wrote:


 But this is not gonna happen with such religious attitude to programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.



lambdas and delegates, and constantly introduces new features like linq,
generators, covariant templates.
Oct 11 2011
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.10.2011 13:43, schrieb Kagamin:

 Gor Gyolchanyan Wrote:


 But this is not gonna happen with such religious attitude to programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.



strings, lambdas and delegates, and constantly introduces new features like
linq, generators, covariant templates.


True, but you will see seldom things like LINQ or generators being used 
in corporate projects with offshoring, unless it is somehow required by
the APIs being used.

Corporate world likes to think of programmers as replaceable items, and 
that can only be done with simple programming concepts.
Oct 11 2011
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
They ARE replaceable items, because no good programmer would willingly
get stuck on the same level for too long.
Good programmers tend to grow beyond their current employers all the time.
The difference is, that good programmers get replaced by, let's say,
the ones, who have a hard time grasping more then one programming
technique.

On Tue, Oct 11, 2011 at 7:40 PM, Paulo Pinto <pjmlp progtools.org> wrote:

 Am 11.10.2011 13:43, schrieb Kagamin:

 Gor Gyolchanyan Wrote:


 But this is not gonna happen with such religious attitude to programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.



 strings, lambdas and delegates, and constantly introduces new features like
 linq, generators, covariant templates.


 True, but you will see seldom things like LINQ or generators being used in
 corporate projects with offshoring, unless it is somehow required by
 the APIs being used.

 Corporate world likes to think of programmers as replaceable items, and that
 can only be done with simple programming concepts.
Oct 11 2011
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 11/10/2011 17:40, Paulo Pinto a écrit :

 Am 11.10.2011 13:43, schrieb Kagamin:

 Gor Gyolchanyan Wrote:


 But this is not gonna happen with such religious attitude to
 programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.



 strings, lambdas and delegates, and constantly introduces new features
 like linq, generators, covariant templates.


 True, but you will see seldom things like LINQ or generators being used
 in corporate projects with offshoring, unless it is somehow required by
 the APIs being used.

 Corporate world likes to think of programmers as replaceable items, and
 that can only be done with simple programming concepts.


No doubt why so many IT project are failures.
Oct 11 2011
prev sibling next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
The paradox of good developers is: truly irreplaceable developer is
one, that can be easily replaced.
The better the developer works, the easier it is to get rid of him.
But the one you'll replace him with won't work as good and will make
code, which is expensive to understand for newbies.
So you won't wanna replace him, which makes him irreplaceable.

On Tue, Oct 11, 2011 at 7:40 PM, Paulo Pinto <pjmlp progtools.org> wrote:

 Am 11.10.2011 13:43, schrieb Kagamin:

 Gor Gyolchanyan Wrote:


 But this is not gonna happen with such religious attitude to programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.



 strings, lambdas and delegates, and constantly introduces new features like
 linq, generators, covariant templates.


 True, but you will see seldom things like LINQ or generators being used in
 corporate projects with offshoring, unless it is somehow required by
 the APIs being used.

 Corporate world likes to think of programmers as replaceable items, and that
 can only be done with simple programming concepts.
Oct 11 2011
parent reply Paulo Pinto <pjmlp progtools.org> writes:
There is some truth in what you say Gor, but I have seen it going
in a complete direction all the time.

I lost count the amount of Corporate projects I had contact with, which
were developed multi-site across the globe. With sites being changed in 
a few months, just because some figures in the management Excel did not
look good.

True, most good developers eventually go away. The few ones that stay
around, do so due to other factors besides "coding fun".

I have seen too many Corporate projects where the teams literaly do
body shopping. You don't get the right people for the project, but the
ones which happen to be somehow available.

With time I have become a bit cynic and now consider that C++, D, Scala
and so on, are languages for people with brain, while Java, VB.Net and
others are offshoring/outsourcing languages.


Am 11.10.2011 17:58, schrieb Gor Gyolchanyan:

 The paradox of good developers is: truly irreplaceable developer is
 one, that can be easily replaced.
 The better the developer works, the easier it is to get rid of him.
 But the one you'll replace him with won't work as good and will make
 code, which is expensive to understand for newbies.
 So you won't wanna replace him, which makes him irreplaceable.

 On Tue, Oct 11, 2011 at 7:40 PM, Paulo Pinto<pjmlp progtools.org>  wrote:

 Am 11.10.2011 13:43, schrieb Kagamin:

 Gor Gyolchanyan Wrote:


 But this is not gonna happen with such religious attitude to programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.



 strings, lambdas and delegates, and constantly introduces new features like
 linq, generators, covariant templates.


 True, but you will see seldom things like LINQ or generators being used in
 corporate projects with offshoring, unless it is somehow required by
 the APIs being used.

 Corporate world likes to think of programmers as replaceable items, and that
 can only be done with simple programming concepts.
Oct 11 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Well, to be honest, I'm just as cynic as you :-)
I agree with everything you said. :-)

On Tue, Oct 11, 2011 at 9:19 PM, Paulo Pinto <pjmlp progtools.org> wrote:

 There is some truth in what you say Gor, but I have seen it going
 in a complete direction all the time.

 I lost count the amount of Corporate projects I had contact with, which
 were developed multi-site across the globe. With sites being changed in a
 few months, just because some figures in the management Excel did not
 look good.

 True, most good developers eventually go away. The few ones that stay
 around, do so due to other factors besides "coding fun".

 I have seen too many Corporate projects where the teams literaly do
 body shopping. You don't get the right people for the project, but the
 ones which happen to be somehow available.

 With time I have become a bit cynic and now consider that C++, D, Scala
 and so on, are languages for people with brain, while Java, VB.Net and
 others are offshoring/outsourcing languages.


 Am 11.10.2011 17:58, schrieb Gor Gyolchanyan:

 The paradox of good developers is: truly irreplaceable developer is
 one, that can be easily replaced.
 The better the developer works, the easier it is to get rid of him.
 But the one you'll replace him with won't work as good and will make
 code, which is expensive to understand for newbies.
 So you won't wanna replace him, which makes him irreplaceable.

 On Tue, Oct 11, 2011 at 7:40 PM, Paulo Pinto<pjmlp progtools.org> =A0wro=




te:

 Am 11.10.2011 13:43, schrieb Kagamin:

 Gor Gyolchanyan Wrote:


 But this is not gonna happen with such religious attitude to
 programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.



 strings, lambdas and delegates, and constantly introduces new features
 like
 linq, generators, covariant templates.


 True, but you will see seldom things like LINQ or generators being used
 in
 corporate projects with offshoring, unless it is somehow required by
 the APIs being used.

 Corporate world likes to think of programmers as replaceable items, and
 that
 can only be done with simple programming concepts.
Oct 11 2011
prev sibling parent Kagamin <spam here.lot> writes:
Paulo Pinto Wrote:


 True, but you will see seldom things like LINQ or generators being used 
 in corporate projects with offshoring, unless it is somehow required by
 the APIs being used.
 
 Corporate world likes to think of programmers as replaceable items, and 
 that can only be done with simple programming concepts.


Inheritance and overloading can get really tough, while one can use linq
without reading a line about it.

an example:

class DBException: Exception{}
void Handle(Exception e){ log("Exception handled"); }
void Handle(DBException e){ log("DBException handled"); }
Handle(null); // which method is called?

Can you expect this level of expertise from an average codemonkey?

BTW we found this pattern in our code.
Oct 11 2011
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 11/10/2011 11:57, Gor Gyolchanyan a écrit :

 I can't keep it in any more, I have to share.

 The code is unimaginably bloated, flooded with thousands of tiny
 redundant classes, each of which do a primitive task, which doesn't
 need to be a class at all.


Well, you'll have to admit that you are a religious yourself. I 
currently facing problems with that state of mind, trying to put back a 
project on track.

This lread to very difficult code to maintain and make evolve. The key 
point here is separation of concerns. Even if you have to write a 
function with 2 lines of payload, it will pay in maintenance, testing , 
debug and future evolutions.

That said, I face often the other argument : this 
class/function/whatever is too big. Well if the function contains a damn 
procedure that the program must follow step by step, a long function is 
definitvely the way. Separation of concern as usual.

This doesn't means you software will be bloated. You can use 
metaprogramming to assemble all thoses parts at compile time.

I'm also sometime facing religious behaviour of mine. We all do that. 
The key is to be ready to open up when a logical argument is proposed. 
This is the way you evolve.

Back on the subject, company policies are often made by so called senior 
programmers, that did the same mistakes again and again and again for 
years and enforce them in the company throw policies. This is a fact, 
most people hate change, and will do whatever they can to avoid it (if 
you are interested on the topic, this is broadly studied by 
psychologists). You'll have a natural tendancy to do that yourself, it 
is natural. Fight it every day to be a better programmer :D

The 100% OOP iritate me too (and a part of my job is in java) but it has 
the advantage to avoid people to learn new concept. Sadly, this is what 
they want. And this is sometime what is better for the company, because 
you don't want to work against your employee. They will be demotivated 
and unproductive, but worse, reluctant to do good quality work.

Back to company, I did myself showed to management that I was very 
productive and did quality code (less bugs, easier to evolve to includ 
enew functions). This is important to show that by RESULTS. When you 
have data and facts, you can push good practices in the company.

Now we got better working conditions (better hardware, better workspace, 
etc . . .) and are way more exigent on new employee capacities 
(especially thoses who worked with non mainstream technologies like D 
obviously, but also haskell, erlang, or basically anything that show 
curiosity and eager to learn new stuff and get better). And this is working.

Remembrer : if you can't change the place, just move. IT gives a lot of 
opportunities. By many of them will be in similar conditions than your 
current position. You usually have to change the company or be very 
lucky to find one which already know what software is about.
Oct 11 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Very good point. In fact, I used to be very religious about C++ and i
never wanted to use anything else besides it.
Interestingly enough I was the one to propose to move our project to D
(my brother and I are working on our own projects).
Even since, he doesn't stop telling me how awesome D is (after having
9+ years of C++ experience).
The only way for me (and all others, that agree with me in this) is to
start their own projects and get self-employed.

I'm a run-time performance freak. I want to push my code to the
ultimate limit of performance, which will allow me to use many
seemingly expensive features at once and benefit from unprecedented
functionality (which is unprecedented because of the performance
limitations).

The biggest source of performance hit is workarounds and adapters.
Java is so slow not only because of it's "RAM is cheaper, then CPU"
policy, but also because it's filled with OO adapters around non-OO
concepts.
D is by far the least adapter-hungry software development tool I ever saw.
D has a "right way" to do everything, as opposed to, let's say, Java's
"right way" to implement hierarchically related sets of data and
functions to manipulate them, but with no way to do anything else,
which makes everything else being implemented the "wrong way".

All I want in this respect is to get rid of workarounds, adapters and
"wrong way" of getting things done.
And i can't help but notice, that i highly depend of other people's
work (libraries I use, programmers I'll hire).
That's why I want to help people stop making layers after layers after
layers of wrappers around a smelly implementation to try and cover up
the smell and start doing it the way it was supposed to be done.

On Tue, Oct 11, 2011 at 5:22 PM, deadalnix <deadalnix gmail.com> wrote:

 Le 11/10/2011 11:57, Gor Gyolchanyan a =E9crit :

 I can't keep it in any more, I have to share.

 The code is unimaginably bloated, flooded with thousands of tiny
 redundant classes, each of which do a primitive task, which doesn't
 need to be a class at all.


 Well, you'll have to admit that you are a religious yourself. I currently
 facing problems with that state of mind, trying to put back a project on
 track.

 This lread to very difficult code to maintain and make evolve. The key po=


int

 here is separation of concerns. Even if you have to write a function with=


 2

 lines of payload, it will pay in maintenance, testing , debug and future
 evolutions.

 That said, I face often the other argument : this class/function/whatever=


 is

 too big. Well if the function contains a damn procedure that the program
 must follow step by step, a long function is definitvely the way. Separat=


ion

 of concern as usual.

 This doesn't means you software will be bloated. You can use metaprogramm=


ing

 to assemble all thoses parts at compile time.

 I'm also sometime facing religious behaviour of mine. We all do that. The
 key is to be ready to open up when a logical argument is proposed. This i=


s

 the way you evolve.

 Back on the subject, company policies are often made by so called senior
 programmers, that did the same mistakes again and again and again for yea=


rs

 and enforce them in the company throw policies. This is a fact, most peop=


le

 hate change, and will do whatever they can to avoid it (if you are
 interested on the topic, this is broadly studied by psychologists). You'l=


l

 have a natural tendancy to do that yourself, it is natural. Fight it ever=


y

 day to be a better programmer :D

 The 100% OOP iritate me too (and a part of my job is in java) but it has =


the

 advantage to avoid people to learn new concept. Sadly, this is what they
 want. And this is sometime what is better for the company, because you do=


n't

 want to work against your employee. They will be demotivated and
 unproductive, but worse, reluctant to do good quality work.

 Back to company, I did myself showed to management that I was very
 productive and did quality code (less bugs, easier to evolve to includ en=


ew

 functions). This is important to show that by RESULTS. When you have data
 and facts, you can push good practices in the company.

 Now we got better working conditions (better hardware, better workspace, =


etc

 . . .) and are way more exigent on new employee capacities (especially
 thoses who worked with non mainstream technologies like D obviously, but
 also haskell, erlang, or basically anything that show curiosity and eager=


 to

 learn new stuff and get better). And this is working.

 Remembrer : if you can't change the place, just move. IT gives a lot of
 opportunities. By many of them will be in similar conditions than your
 current position. You usually have to change the company or be very lucky=


 to

 find one which already know what software is about.
Oct 11 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/11/2011 2:57 AM, Gor Gyolchanyan wrote:

 Can anyone help me out in this quest of enlightening people?


There was the same thing with C programmers when C++ was new. People would 
insist that they could do OOP in C, and yes, they could. I've seen it. It works.

It is awful, though.

People who were willing to learn new things moved on to C++. The C community 
didn't go away, but it did become a community of very conservative programmers 
who resisted anything new. Look at the evolution of the C standard since then - 
change is practically nonexistent. All the people that wanted change moved to 
other languages.

So I wouldn't worry about it. We need to concentrate on making D the best we 
can. To help spread the word, the best way is to write articles about D.
Oct 11 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Come to think of it, it's exactly the same situation here.
Some people still use and love C.
One of the most famous programmers is a C guru and he used his
expertise in C to write the even more famous OS kernel., which sits in
the heart of the vast majority of operating systems today.

By making D and DMD open-source and community-driven you ensured it's
usability-oriented evolution.
I can't thank you enough for that. :-)

When I finally finish my first project with my brother and start
selling it, I'll quit my job and get self-employed, which will allow
me to direct more effort in developing D.
After all, D is the source of my future profit. I gotta invest in my own profit.

On Tue, Oct 11, 2011 at 9:55 PM, Walter Bright
<newshound2 digitalmars.com> wrote:

 On 10/11/2011 2:57 AM, Gor Gyolchanyan wrote:

 Can anyone help me out in this quest of enlightening people?


 There was the same thing with C programmers when C++ was new. People would
 insist that they could do OOP in C, and yes, they could. I've seen it. It
 works.

 It is awful, though.

 People who were willing to learn new things moved on to C++. The C community
 didn't go away, but it did become a community of very conservative
 programmers who resisted anything new. Look at the evolution of the C
 standard since then - change is practically nonexistent. All the people that
 wanted change moved to other languages.

 So I wouldn't worry about it. We need to concentrate on making D the best we
 can. To help spread the word, the best way is to write articles about D.
Oct 11 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Gor Gyolchanyan" <gor.f.gyolchanyan gmail.com> wrote in message 
news:mailman.37.1318327068.24802.digitalmars-d puremagic.com...

I can't keep it in any more, I have to share.

 I've seen lots of corporate C++ code and coding guidelines and I came
 to the conclusion, that they're all bogus.
 The vast majority of code, being written in commercial projects use a
 very limited subset of the language they use.
 The code I work with currently is a purely object-oriented C++ code.
 I used to like object-oriented programming until I started working
 with that code.
 Corporate code is very religious. They use a few specialized
 techniques for everything.
 They use object-oriented programming when functional programming is
 the technique of choice.
 They use object-oriented programming when generic programming is the
 technique of choice.
 The code is unimaginably bloated, flooded with thousands of tiny
 redundant classes, each of which do a primitive task, which doesn't
 need to be a class at all.
 I've discussed D with my colleagues lately and the vast multi-paradigm
 and built-in featured of D were discarded with a religious "There's a
 class already written for that.".
 Why do I keep saying "religious"? Because they are convinced, that
 this is the way to go and do not accept any logical arguments.
 Why do I talk about this at all? Because corporate code is the one we
 need to become D.
 But this is not gonna happen with such religious attitude to programming.
 They say built-in arrays are useless, because there's always
 std::vector and std::list.
 They say, functional programming and lambdas are useless, because you
 can make functors and base classes for them.
 They say garbage collection is useless, because there's always 
 std::shared_ptr.
 Well, yes. You do have all that. But look what the code looks like and
 how fast it runs!

 It's amazing how stupid and ignorant can corporate developers be
 sometimes and how smart and considerate open-source developers can be.
 I don't know how to cure the people's minds from this religious
 plague, that poisons the software development industry.


Hear, hear!
Oct 11 2011
prev sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 11/10/11 10:57 AM, Gor Gyolchanyan wrote:

 Can anyone help me out in this quest of enlightening people?


You can only enlighten people if you are enlightened.

I'm not saying that you're not, but how can you know? Do you really know 
everything there is to know about computer programming, and all the 
issues surrounding it? I know I don't.

In my opinion, if you want to show people the merits of D, then show 
them! Write lots of amazing software in D and show it to the world via 
github, reddit, etc. You're not going to convince many people by arguing 
with them, but you will convince them through example.
Oct 11 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Right. But I'm one, they're many.
I don't have enough manpower to do that, while I need those people to
write libraries in D for me to use.
That's the problem.

On Tue, Oct 11, 2011 at 11:35 PM, Peter Alexander
<peter.alexander.au gmail.com> wrote:

 On 11/10/11 10:57 AM, Gor Gyolchanyan wrote:

 Can anyone help me out in this quest of enlightening people?


 You can only enlighten people if you are enlightened.

 I'm not saying that you're not, but how can you know? Do you really know
 everything there is to know about computer programming, and all the issues
 surrounding it? I know I don't.

 In my opinion, if you want to show people the merits of D, then show them!
 Write lots of amazing software in D and show it to the world via github,
 reddit, etc. You're not going to convince many people by arguing with them,
 but you will convince them through example.
Oct 11 2011