My question was general, perhaps I’ll try again – is it easy for a bad
programmer to write overly complicated code?
Do you mean in general or specifically in Ruby vs. other programming
languages? Concluding from code I have seen I would say it is easy
for bad programmers to write overly complicated code - regardless of
language. It may be a tad less easy in Ruby as the syntax is pretty
clean and it is more difficult to produce unreadable code just by
doing syntax tricks.
Subject: Is it easy for a bad programmer to write overly complicated
code? (was: Re: Normal For Loop)
Date: gio 24 ott 13 12:59:40 +0200
Sorry for the delay!
deliberately try out as many new features as they can, in live code,
to improve their own knowledge and to show off
You are putting two opposite concepts in the same basket. To show off
is of course bad. To improve one’s knowledge is not only a good thing
it is one of the fundamental reasons why we are here on this
planet.
The evil here is on the part of corporate employers, who couldn’t care
less about the personal evolution of the programmers they employ, and
are after the fundamentally flawed holy grail of
programmers-as-commodity. You burn one, you get a new one from the
drawer.
These employers are afraid of hiring people who are brighter than they
are, and thus the code that is produced by their people is unescapably
mediocre.
I certainly wrote overly complex and repetitive code when learning Ruby.
Not writing methods, writing all code in main, not using OO… sometimes
you have to make mistakes to fully understand the benefits of doing
things properly.
I chose my words carefully it’s why I said ‘live code’. Anyone
writing anything other than the simplest, easiest code to solve a
problem is (in my book anyway) a bad programmer. I have known any
number to ‘bend’ a solution to fit code they want to write.
It becomes soon evident to anybody who cares for his/her code that
simple, linear (although not easy, at least concept-wise) code cuts
the cake much better than uselessly complex code. I reacted to your
usage of showing off and improving one’s knowledge as comparable
concepts. I believe these two attitudes produce widely different
results. If you consider coding as craftsmanship, the first attitude
is detrimental to code quality, while the second one is instrumental
to code quality.
I want to add that ‘easy’ code can only solve elementary, or
extensively explored problems. At the point when you can use ‘easy’
code, you are very close to the point where you can use code
generators as well.
I reacted to your
usage of showing off and improving one’s knowledge as comparable
concepts. I believe these two attitudes produce widely different
results. If you consider coding as craftsmanship, the first attitude
is detrimental to code quality, while the second one is instrumental
to code quality.
I stand by the idea that putting into production more complex code than
needed just to improve one’s knowledge is showing off – and I’m sure
you’ve seen any number of people do it.
I stand by the idea that putting into production more complex code than
needed just to improve one’s knowledge is showing off – and I’m sure
you’ve seen any number of people do it.
No. Either you do one thing, or you do the other. Notice the
difference: one thing is to write code and somehow improve one’s
knowledge as a more or less welcome side effect. Another thing is to
focus one’s effort on improving one’s knowledge.
In the first case, it may well be that you are motivated by pride
(showing-off, or other). In the second one, you are not.
It is an aspect of the duality Constructiveness|Destructiveness. Quite
a fundamental one.
Subject: Is it easy for a bad programmer to write overly complicated
code? (was: Re: Normal For Loop)
Date: gio 24 ott 13 12:59:40 +0200
Sorry for the delay!
deliberately try out as many new features as they can, in live code,
to improve their own knowledge and to show off
You are putting two opposite concepts in the same basket. To show off
is of course bad. To improve one’s knowledge is not only a good thing
it is one of the fundamental reasons why we are here on this
planet.
I chose my words carefully it’s why I said ‘live code’. Anyone
writing anything other than the simplest, easiest code to solve a
problem is (in my book anyway) a bad programmer. I have known any
number to ‘bend’ a solution to fit code they want to write.
The evil here is on the part of corporate employers, who couldn’t care
less about the personal evolution of the programmers they employ, and
are after the fundamentally flawed holy grail of
programmers-as-commodity. You burn one, you get a new one from the
drawer.
A different discussion indeed…!
These employers are afraid of hiring people who are brighter than they
are, and thus the code that is produced by their people is unescapably
mediocre.
Carlo
People who won’t hire others brighter than themselves in any field are
2nd rate, as you say. It’s an infallible measure, IMO.
On Thu, Oct 24, 2013 at 4:14 PM, Carlo E. Prelz [email protected]
wrote:
I want to add that ‘easy’ code can only solve elementary, or
extensively explored problems. At the point when you can use ‘easy’
code, you are very close to the point where you can use code
generators as well.
Not sure I agree here. If a method can be written with simple
straight forward code that just means that the developer has done a
good job at structuring design and code in a manner that one class /
method / function does one thing properly. I doubt that process can
be automated.
Plus: Ruby is so expressive that the description of requirements for
the code generator is probably not shorter than the Ruby code itself.
“I want all items with price higher than $10” is about as complex as
“items.select {|it| it.price > 10}”. So why generate if you can write
the Ruby down with the same effort?
what I fear is that the variety of Ruby – there seem to be any number
of ways of doing the simplest things – may encourage them.
In Ruby land we usually consider TMTOWTDI to be a good thing. Luckily
many of the multiple ways will be readable because of Ruby’s API
design and clean syntax. I wouldn’t worry too much about this. If
you do, then just pick another language with which you feel more
comfortable.
Plus: Ruby is so expressive that the description of requirements for
the code generator is probably not shorter than the Ruby code itself.
“I want all items with price higher than $10” is about as complex as
“items.select {|it| it.price > 10}”. So why generate if you can write
the Ruby down with the same effort?
When I mention code generators, I mean something that can be operated
without the help of a programmer. For you and me, the complexity of
your two examples is comparable. A non-programmer, on the other side,
will find the meaning of the first example quite obvious, while the
second example may give the impression of being a meaningless jumble
of characters.
On Thu, Oct 24, 2013 at 7:18 PM, Carlo E. Prelz [email protected]
wrote:
When I mention code generators, I mean something that can be operated
without the help of a programmer. For you and me, the complexity of
your two examples is comparable. A non-programmer, on the other side,
will find the meaning of the first example quite obvious, while the
second example may give the impression of being a meaningless jumble
of characters.
Now, this is an interesting question: how formal would an input for a
code generator have to be? Considering current state of affairs of
speech recognition and AI I’d guess that you need at least some
formalism. Well, unless of course you can afford “Deep Thought” or
other non fictional supercomputers (what was the name of this IBM
thingy which won that quiz show again?).
Let us suppose for the moment that all that is true. What do you
intend to do about it?
To me, none of the conditions you specified above are specific to
Ruby, or really any other language that I know. What you are
describing sounds more like a way some people approach learning in
general. It is a general truism that you have to be poor at something
before you can excel at something.
In the Ruby world, like no other I’ve encountered, there is a strong
emphasis on testing, and testing before development, and the concept
of refactoring early and often. I know this is not born out in
practice everywhere, especially in programming shops that happen to be
doing Ruby, and there’s oceans of poorly written and designed Ruby
code out there, yet I’m still of the opinion that rubyists are more in
tune with the craft of programming than other cultures around other
languages. Sturgeon’s Law will hold, regardless.
Goodness me, you seem to think I’m attacking Ruby. I’m not. I was
trawling (not, I hope, trolling) for opinion on a language design
feature. I didn’t mean to offend you, I apologise.
Oh, no, not defending Ruby. The set of assertions you make about bad
programmers, though, is the characteristics of someone learning how to
become a better programmer, given sufficient practice at being bad at
something, receiving feedback and learning to improve.
Goodness me, you seem to think I’m attacking Ruby. I’m not. I was
trawling (not, I hope, trolling) for opinion on a language design
feature. I didn’t mean to offend you, I apologise.
it’s why I said ‘live code’. Anyone