Object Relational Mappers are evil (a meditation)

[J Kenneth King]

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:

> On Wed, 23 Dec 2009 10:55:19 -0500, J Kenneth King wrote:
>
>> Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
>> 
>>> On Mon, 21 Dec 2009 11:44:29 -0500, J Kenneth King wrote:
>>>
>>>> A programmer that
>>>> lacks critical thinking is a bad programmer.  The language they use
>>>> has no bearing on such human facilities.
>>>
>>> That's nonsense, and I can demonstrate it by reference to a single
>>> programming language, namely Python.
>>>
>>> For many years, Python had no ternary if operator:
>
> [...]
>
>> But did the lack of ternary encourage Raymond to become a bad
>> programmer?
>
> No, but Raymond started off in a position of being an excellent 
> programmer. A single buggy idiom lead him to be slightly-less excellent 
> than he otherwise would have been. How many buggy idioms would it take to 
> lead him to become a mediocre coder, if he was unable to change languages?
>
> Because Python is generally an excellent language, the harm done by one 
> or two misfeatures is minor. But less excellent languages encourage 
> coding styles, techniques and idioms that encourage the programmer to 
> write poor code: either complicated, baroque, unreadable code; or slow 
> inefficient code; or buggy code. To avoid starting a flame war, I will 
> avoid mentioning PHP. *cough*
>
> Sometimes you know what you need to do to write non-buggy code, but 
> because covering all the corners are just Too Damn Hard in a certain 
> language, you simply lower your expectations. Error checking is tedious 
> and hard to get right in some languages, like C and Pascal, and hence 
> even good programmers can miss some errors.
>
> Different languages encourage different mind-sets in the programmer: C 
> encourages the coder to think at the low level of pointers and addresses, 
> and primarily about machine efficiency; Java encourages the use of big 
> object hierarchies and design patterns (it's hard to write lightweight 
> code in Java, so everything turns into heavyweight code); Perl encourages 
> cleverness and code-golf (writing a program in as few lines or characters 
> as possible); Haskell and Lisp encourage a heavily abstract approach that 
> often requires an elite coder to follow; Forth encourages you to think 
> like Yoda.

If anyone continues to follow bad idioms without questioning their
usefulness from time to time, I'd question their ability as a
programmer.  Critical thinking is important.  Which is why good programs
can be written in PHP, Forth, Lisp, Perl, and anything else.  However,
if a programmer thinks the only language they will ever need to know is
BF, they have a serious screw loose. ;)

> [...]
>> Good tools make all the difference in the world, I'm not arguing that.
>
> You appear to be arguing against that.

Maybe you need to reconsider my arguments.

It takes a good programmer to recognize the values and trade-offs of the
tools they work with.

Ignorance is not an excuse to blame the language.  It's too easy to say,
"Well Perl sucks because it encourages you to be a bad programmer
because it has all these features that let you shoot yourself in the
foot."  In reality, lots of really great programs are written in Perl
all the time and some very smart people write them.  It just so happens
that in hands of the educated, those very features are useful in certain
cases.

Python doesn't "encourage" you to be a better programmer.  It just
enforces particular idioms and conventions in its design.  As long as
the ignorant programmer follows them they should be better off.  Yet if
they are ignorant, no amount of encouragement will get them to think
critically about Python and find bugs in it.  They will have to rely on
the community of developers to do that thinking for them.

>
>> Just that the tools don't use us; we use them.
>
> Nobody said that tools use us.

But it is being suggested that they influence our thinking.

Pretty smart thing for a language to be able to do.

>> Programming in Python
>> doesn't instantly make me a better programmer.
>
> No, not instantly, but I would argue that after many years of coding in 
> Python you will be a better programmer than after the same number of 
> years of coding in PHP or Basic.

And my argument is that the human element is what will determine who is
better.

There are good programmers who can program in PHP.  Some of the biggest
websites on the Internet are programmed in it.  And like any language
I'm sure it has a good number of inefficiencies and bad design decisions
that the programmers using it had to work around.  Yet despite it being
a poor language in your opinion, they built successful programs with
it.  I wouldn't feel right calling them bad programmers.

(large portions of Facebook and Flickr, for example, are written in
PHP.  They used to be written entirely in PHP before migrating the
bottlenecks out to lower-level languages as they scaled up... as is
common in most high-level languages)

> It also depends on what you mean by "better programmer". Some languages 
> value cleverness above all else. Python is not a language for writing 
> amazing, awe-inspiring hacks that work where nobody but the author can 
> work out why. This is why there is an Obfuscated C contest and an 
> Obfuscated Perl contest but no Obfuscated Python contest -- it wouldn't 
> be anywhere near as awe-inspiring.
>
> So one might argue that the best C and Perl coders are better than the 
> best Python coders, but the average Python coder is better than the 
> average C and Perl coder. 
>
> (I suggest this as a hypothetical, and do not wish to defend it 
> scientifically.)

I should hope not. ;)

Particularly because people often go out of their way to write clear,
concise, and maintainable Perl and C code every day.

In many contexts I'm sure there is reason to use Perl instead of Python
just as there are situations where C is more appropriate than either.

However, the mark of a poor programmer in my line of reasoning is one
who cannot recognize such distinctions.

One must be aware of the benefits and short-comings of their tools.  If
your tools influence the way you think then you are being ignorant of
this principle.  And I would suggest that makes you a poor programmer.