religious programming

[Gor Gyolchanyan]

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 at gmail.com> wrote:
> 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.
>