
What Compsci textbooks don't tell you: Real world code sucks - experiment0
http://www.theregister.co.uk/2012/12/21/financial_software_disasters/print.html
======
kolektiv
Good grief, what a vast amount of supposition backed up by very little
evidence or insight. "People often write bad code." Yes, we know that.
"There's more than one reason for this." Yes, we know that too.

The rest of the article is just random presumptions thrown together, for what
reason I couldn't say. The best developers work in finance because the money's
highest? Yeah, OK then... (To be fair, I think there is a qualifying
"considered to be" in there somewhere) K is impenetrable? Hmmm. Haskell is an
offshoot of ML and unreadable? Umm, factually wrong.

There's lots wrong with software at scale, and the pressures of financial
institutions along with high budgets etc do produce an interesting set of
problems, but this article offers nothing new about anything at all in the
field.

As an aside, I already don't trust an author when they start off with a claim
that textbook code is good code! It's almost universally accepted to be
trivialised and simplified to the point of "don't do this in the real world"
simply because it has to be. Some of the worst code I've seen has been in
textbooks (and that's worst as in "dangerous" rather than as in "badly written
and in need of refactoring/replacement/enclosing in concrete).

Edit to note: I think it's actually beyond incompetent journalism and in to
plain lying to present a piece of code as evidence of Haskell unreadability
when the link to that code on SO refers to it clearly as "obfuscated Haskell
code".

~~~
pretoriusB
> _Good grief, what a vast amount of supposition backed up by very little
> evidence or insight. "People often write bad code." Yes, we know that.
> "There's more than one reason for this." Yes, we know that too._

 _YOU AND ME_ know that. The title of the article is "What Compsci textbooks
don't tell you", so I guess it is targeted at people still in college, to show
them how things are in the "real world".

~~~
cms07
If they are in college and don't have enough interest to already know that,
then they are the problem..

~~~
dhimes
Yes. And there are a shitload of them.

------
EzGraphs
Alan Kay classifies most real world code as pop culture (one of the most
helpful categories for thinking about it):

[http://www.drdobbs.com/architecture-and-design/interview-
wit...](http://www.drdobbs.com/architecture-and-design/interview-with-alan-
kay/240003442)

 _Pop culture is all about identity and feeling like you're participating. It
has nothing to do with cooperation, the past or the future — it's living in
the present. I think the same is true of most people who write code for money.
They have no idea where [their culture came from] — and the Internet was done
so well that most people think of it as a natural resource like the Pacific
Ocean, rather than something that was man-made. When was the last time a
technology with a scale like that was so error-free?_

I appreciate this categorization on many fronts:

\- It explains how non-computer science majors have frequently succeeded. In
music, you will never find a classical musician without formal training, but
frequently find pop musicians who have little or none.

\- It shows how some of the same ideas keep being "discovered" by one group
while another group sighs and exclaims "we knew about that years ago..."

\- Pop culture is inherently youthful, prone to extremes, sensitive to new
trends. Sound familiar?

\- It explains a vast amount of decision making that goes on in industry.
Rather than choosing the absolute best solution from a somewhat abstract
technical perspective, a solution that is new and hip (or fits what I was
doing in the hey-day of the bosses youth) is selected.

It is over simplistic to simplify real world code as "sucking" (though of
course much does). It is like comparing Bach and <fill in your favorite
rock/pop star here>. Both produce valid creations that accomplish something,
but were made with vastly different intentions and for different purposes.

~~~
david927
Real world code? All code sucks. And Alan Kay says something more damning than
that: he says that the whole industry is a pop culture. We are living in the
murky anterenaissance and precious few seem bothered by it.

~~~
signalsignal
You're right. Alan Kay does come across as rather bitter.

~~~
michaelochurch
Alan Kay _has every right to be_ bitter. He's a great software architect, and
came up with OOP as a perfectly reasonable policy for managing complexity. Now
most people associate OOP with commercial garbage and that
VisitorSingletonFactory nonsense.

If you came up with a set of really good ideas that were later bastardized and
mutated into the sort of business horseshit that's destroying software,
wouldn't you be pissed off?

------
peteretep
> Haskell, an offshoot of ML. According to a friend in academia who’s studied
> it, it’s “the Taliban version of ML,” in which it’s all but impossible to
> write readable code

Can we stop posting this crap, please? TheReg was kinda edgy and cool circa
1998, but now it just seems a forum for trollish and content free articles.

------
barrkel
It apparently didn't occur to David that the reason why the code in banks suck
might be because they don't actually employ "the very best".

I live in London, arguably the current world financial capital, but I'd have
to be fairly desperate to work for a bank. (Not suggesting I'm the very best,
of course, but rather taking banker money is like being a whore.)

~~~
antiterra
> rather taking banker money is like being a whore

What if you're a barber who cuts a banker's hair, is that "like being a
whore?" What if you sell software to a banker, or you're a nanny for the
children of a banker? Also: do you have any respect for actual women who
engage in prostitution?

~~~
ucee054
_Further: do you have any respect for actual women who engage in
prostitution?_

No.

Ditto for drug dealers.

~~~
mikegioia
I can understand having little respect for drug dealers as they can negatively
affect communities.

But how on earth can you justify blanket-ly having no respect for the women
themselves that engage in prostitution?

~~~
ucee054
Are you under the delusion that prostitution doesn't negatively affect
communities?

~~~
mikegioia
Well "illegal prostitution" certainly brings about things that negatively
affect communities, but that's not the point I was making, nor the question I
was asking you.

You said you have no respect for the WOMEN who engage in prostitution. Why?

My point about drug dealers is that I can see having no respect for the person
that deals drugs as they themselves produce harm (they could sell to kids).

------
boothead
The little bit of haskell FUD in this article made me largely disregard the
rest (although I've heard my share of horror stories about the software s big
financial institutions). Once you get past the different syntax I find haskell
code to be extremely readable.

~~~
Maro
I recently learned Haskell and am writing code in it on a daily basis,
although I'm still a novice.

In my limited experience, Haskell is like any other PL, you can write clean,
readable code or a horrible mess.

My major concern with Haskell right now is with maintainability/changability
of code. One recent example that bit me in the ass was: I wrote an elegant
solution to check whether a list of files exists, using sth like foldr (&&)
True doesFileExist. Then I realized I really need to print out which file is
actually missing, but only the first N to avoid flooding the user with error
messages. At this point FP becomes a pain IMO, and it'd be much easier to add
a counter variable and printfs in the imperative program and move on. Actually
this is fairly common, think about adding printfs for debugging: not so easy
in Haskell, as IO changes the type signatures of the function and its callers.
So, in my limited experience, changing code in Haskell is expensive and its
effect are not localized.

~~~
gnuvince
Regarding your example, I think that one part of the problem (which you
mentioned in the first paragraph of your comment) is that you are still a
novice. I cannot claim to be an expert in FP or Haskell, but here's how I
would go about your problem.

First, I think your problem really has two tasks to perform: getting a list of
files that don't exist, and selecting only a part of those inexistant files.
It would make sense to decompose these two tasks into two different functions,
and since Haskell has non-strict evaluation, we don't have to worry about
generating too much data (list of inexistant files) for nothing. Starting with
the function to select inexistant files:

    
    
        inexistantFiles :: [FilePath] -> IO [FilePath]
        inexistantFiles files = filterM (\f -> doesFileExist f >>= return . not) files
    

Some Haskellers may prefer to write their functions completely point-free, but
I like to have my variables in the code if it helps me read the coder better.
And then we can write another small function to select only the `n` first
inexistant files:

    
    
        takeInexistantFiles :: Int -> [FilePath] -> IO [FilePath]
        takeInexistantFiles n files = takeM n (inexistantFiles files)
            where takeM n = liftM (take n)
    

(Surely, we'd prefer to just write `takeM` and call it directly on the result
of `inexistantFiles`, but I prefered to go with the specialized function.)
Someone who knows Haskell better than I do could certainly come up with a
cleaner solution, but I think the code is readable, solves the problem you
mentioned and isn't any harder to understand than the equivalent imperative
code.

Have a Merry Christmas!

~~~
mifrai
_and since Haskell has non-strict evaluation, we don't have to worry about
generating too much data (list of inexistant files) for nothing._

Be careful here. Because you're in the IO monad, the entire list of files will
always be computed first (ie. doesFileExist will be called for every file
given).

Non-strict doesn't really buy you much here. The "expensive" operation here
will always be executed. At most, you're avoiding converting some list-
consing-thunks to a list.

------
kokey
It's not just bad coders, management is also very responsible. If management
doesn't make sure code is at least getting documented and shown to co workers,
then a lot of bad code gets written only one person understands and can
develop into the shape of his own fetish, and become a problem when he leaves.
The second point is that I have seen very senior programmers, as in years,
e.g. the guys with multiple decades of experience, that are quite used to
dealing with this. When they take code over they can read through it, add the
necessary comments, and document the structure, and convey it to others.

------
InclinedPlane
Well, not necessarily. There is plenty of good code out there. The dirty
little secret of software development is that bad code is an effort sink. Let
me run through a few truisms about bad code and see where they lead us,
development wise.

Bad code is buggier, so it will require fixing more often.

Bad code is more difficult to understand and sometimes has non-intuitive side
effects or method of operation and so working on it will take longer.

Because of the convoluted way that bad code often works, adding features or
doing maintenance on it often makes it even more convoluted and difficult to
work on.

Bad code typically has lower performance, so it will require more attention to
improve performance. Due to the above 3 factors this becomes a vicious cycle
of sinking effort into the code only to make it that much harder to work on in
the future.

For these simple reasons bad code becomes a huge time sink. Programming tasks
involving good code end up taking up a much smaller portion of the developer-
effort budget because it's so much easier to work on that code, while the bad
code takes so much more effort and often the code base just ends up even worse
than before, perpetuating the phenomenon through to the next cycle of
development.

The only way out of this cycle is to identify the code that is the main source
of bugs and the main sink of effort then budget out more than enough time to
tackle it and improve it. But most development shops aren't proactive enough,
introspective enough, or set aside enough dev-resources to be capable of doing
that. Even though such efforts tend to have an enormous impact on future
development.

------
tluyben2
I think this article sucks, but of course they are right; by far most real
world code is horrible. That goes for academic as well by the way; I cringe
when I see the code people get As & Bs for in universities. "It has to work"
they say and the prof seems to agree. So you can see, yes also in Python, the
most incredible constructions which 'work' but are hardly real code and do not
work outside of the required examples.

Code in real world companies is mostly horrible, especially when the company
gets bigger and older. Spolsky has a bunch of articles about that. To
counteract or prevent that you need heaps of money put into it and most
companies really don't see the need or actually don't have the funds.

------
_pferreir_
In my own experience, the development process is usually to blame, more than
the developers themselves, their capabilities (or lack thereof) or their
paycheck.

The project I work for depends highly on usually inexperienced developers and
we're using a development process that is task-oriented but at the same time
based on continuous feedback and regular code reviews. Should it be any other
way, things would quickly degenerate. That's what happened before I arrived,
and we're still (years later) recovering from the damage that that has caused
to the code base.

Outside the IT industry, most bosses don't want to hear about code. Coding is
actually seen as a pretty trivial step in many cases. It's OK to hire an
intern to add new feature X. Writing good code is not properly rewarded - as
long as it works, it's stable, no-one complains, it's OK.

Not to mention stuff such as niche technologies, that usually create a barrier
to entry that would-be employees have to overcome, thus concentrating the
know-how, power and pay in the hands of a few bored people that won't bother
learning the next thing.

------
mmahemoff
This begs the question, which textbooks do include or at least address real-
world code?

The closest I can recall are those with heavy emphasis on refactoring, because
gradually moving from bad to good is usually the best one can hope for in the
real world. I'm thinking in particular of Bob Martin's Agile Software
Development, because I liked how he made the point in the book that he didn't
just arrive at this beautiful code, but achieved it through TDD and
refactoring.

I think "bad code" is actually what the most talented developers excel at (see
also Duct Tape Programming
<http://www.joelonsoftware.com/items/2009/09/23.html>). A talented programmer
knows when it's worthwhile breaking the rules and, by necessity of getting
things done, does so on a frequent basis.

~~~
InclinedPlane
Well, this brings up another problem. And that is that software development is
not applied computer science. There are plenty of books which will teach you
skills on dealing with real-world code (Refactoring and Working Effectively
With Legacy Code being two of the biggies) and there are books that will teach
you about other important aspects of development processes (such as Code
Complete, Rapid Development, Design Patterns, The Pragmatic Programmer, etc.
although those books are showing their age a bit these days) but none of those
would be considered computer science textbooks.

~~~
mmahemoff
True, though I don't think this article is really talking about pure CompSci.
That would be about as relevant to Register's audience as books on physics.

------
knightni
Most of the time, when stuff I write ends up as 'bad code', it started out as
good code, and then got mangled over time due to a series of requirements
changes (not necessarily due to bad processes - you often just understand your
requirements better as you go along).

This is a fairly natural series of events that can be helped by periodic
refactoring. Unfortunately, because each change is small, none of them on
their own justify the time required for the refactor. That's when you've got
to hope you've got a management team that trusts your judgement, and is
willing to carve out the time necessary for this stuff. Most people, alas,
don't have that.

~~~
watt
Well, first thing, in the Computer Science part of programming, the
requirements are very simple and straightforward. For example, implementation
of hashing algorithm or HashMap.

You just can't compare the requirements of "science" part with requirements of
"real world business system". The "science" requirements are almost laughably
trivial. And the documentation of business system will run into thousands of
pages.

Now, you say if you just refactored the code, if you saw the "grand design"
and rewrote the code to accommodate every little requirement elegantly and
with proper abstractions and so on... I will say you would just end up with
system so abstract and general, no-one would understand exactly how it is
meeting those requirements. Because you would had generalized every special
case (where it should've stayed a special case, and that's that).

So in a way, the simple hacked-together awful program might actually make more
sense than the elegant and grand abstract program. Because you can follow the
hacked-together program, and you can't follow the arhitected program. It's
this "abstractions all the way down", where you can hunt abstractions down for
"how exactly does it do this one thing" all day, and then find out it's a
little config setting in obscure .properties file that actually covers this
one business case. (And if it was there right in code, you would be done in 5
minutes. But alas - it's a config option, so to change behaviour, now you must
write all infrastructure to support another possible config option.)

I say - bad code is just fact of life in real-world business. You should
strive to clean it up, make it elegant, abstract and generalize... but really
business just needs to to chug along.

~~~
knightni
Don't get me wrong, I don't strive for 'perfection'. I passed through the
architecture astronaut phase quite some time ago now :-).

Equally, I don't think that the opposite end of 'hacked together' is some kind
of AbstractAbstractFactoryFactory extravaganza - that's just a different kind
of bad code. To me, good code is code that is simple for other people to
understand, and takes basic precautions with respect to being not-too-brittle
to change. Every so often, I find that once the code has received enough
alterations, it needs a bit of TLC.

------
Swizec
The worst[1] code I've seen is code produced by academics with the purpose of
teaching undergrads.

[1] In terms of needing refactoring, poorly named variables and functions,
just doing The Wrong Thing you don't ever do in real life.

~~~
thibauts
I'd say academics are very good on theory, but tend to lack the real world
experience of working in teams bound by company processes. They make code for
machines and students to read, not for other engineers, I suppose.

------
OldSchool
On this entrepreneurially-focused website I'm going to offer that you can't
afford to be an idealist about both business and engineering- probably
neither. Good-enough at the right time in the right market trumps perfection
without all the outside business forces lining up every time. If you're an
artist at heart, no-surprise, it's far more charming to the world if you're
financially successful.

------
kris_lander
The problem highlighted by this article and the ensuing debate here is that
most people in our industry (management and developers alike) talk about good
code and bad code in purely subjective terms. Until we learn to talk
objectively about the systems we build (where code is just one part of that
system) in terms of function (what a system needs to do), performance (how
"good" the system has to do the functions) and economics (the resource
constraints in building the system) - you know, like proper engineers do,
we'll never move forward. The ugly truth is that would appear that most
banking systems are "good enough" - i.e. they are competitive in the
environment operate in - despite the horrors that undoubtably exist in their
implementation. I see a lot of talk about the consequences of "bad code" but
few have the evidence to back it up. It is our responsibility as engineers to
measure the performance of our systems in the _right_ way so it becomes
painfully obvious where we should focus our efforts to improve things.

------
tossacct
An assumption: code is designed [to get things done].

Another assumption: the [thing to get done] will likely eventually be
transformed via evolution or destroyed, as all natural things like rocks and
species and hydrogen atoms and gluons and the entire known universe
starting[?] with the big bang transforms via evolution or gets destroyed.

A conclusion: code that can not be easily changed and evolved will be
conveniently destroyed via a complete re-write. This is why "facades" and
opaque APIs are so popular - it is theoretically possible to rewrite different
components of the code without rewriting the whole entire dang thing.

Case in point: [http://stackoverflow.com/questions/810129/how-does-
whiles-t-...](http://stackoverflow.com/questions/810129/how-does-whiles-t-
work)

>>>while ( _s++ =_ t++);

This is code that is hard to understand(hence the stackoverflow question),
making it not easily changed. Not a good sign for the survivability of the
code.

JoelonSoftware.com makes a sparse point with this example, in that a "good"
coder _must_ understand what this does. He leaves the reasoning up to the
reader, likely because he is clever enough not to make any claims that can be
disagreed with. Luckily I am not this clever and I will make a claim that
follows from my assumptions and conclusion above:

Claim: a "good" coder needs to understand the above type of obfuscated code so
that they can evolve it or destroy it safely when they see it.

Note that my claim does not say whether a "good" coder would write code like
that. A "good" coder gets the job done, whether it's a write-once-use-once-
read-never perl one-liner or a big part of a big program. I only claim that a
"good" coder must be able to read it, so that they can change it or destroy it
safely.

~~~
stephencanon
> while(s++ = t++);

is _absolutely trivial_ to understand if the reader has taken the time to
actually learn the language in which the code is written. Saying this is "hard
to understand" is like saying that "Ich liebe dich" is hard to understand. I'm
sure it might be if the reader has never encountered German, but that's not
real complexity, and it's not unreasonable for someone writing in German to
assume that her reader has some competency with the language.

~~~
jblow
I disagree. I have 16 years' experience programming in C++ (and substantial
experience in other languages before that), and I find that an important
factor in code clarity is not writing stuff like this.

Yes, you can understand it, but it takes more brainpower to do so than it
should, especially once you get beyond trivial cases. It is much better just
to write it the long way.

~~~
stephencanon
> I have 16 years' experience programming in C++ <

Well, there you go; this is absolutely _not_ idiomatic C++; in C++ (or even in
application-level C code) one would (correctly) use language features or a
library call to perform this copy.

I should have been more specific; this code is completely idiomatic for
standard-library-level C (though standard libraries will generally use more
sophisticated copy implementations). If one is fluent in that particular
dialect of the C language, then this construct is natural and correct.

------
nnq
Trollish but true. Things will only change when we start to treat code as
_knowledge_ and not _just a tool_. And to have _knowledge_ and not just data
that can incidentally be compiled or executed as a program that does
something, you also need: meta-data (comments), documentation (always sucks,
probably because writing good docs is as expensive as writing the code
itself...), history (vcs solves this only if the commits have meaningful
comments, bug-tracker data helps a lot but it would be great to be able to
easily get from a piece of code to either the written requirement or the bug-
request that the code satisfies/solves) and meaningful organization (the UNIX
philosophy of small one-task tools, coupled with exposing these tools through
web/services APIs is still one of the best ideas in the field - just don't
overengineer the interfaces and protocols, keep them thin, keep them dumb).

------
jfb
This is why I don't worry about Kurzweil's singularity. The putative Godlike
AI will be littered with catch (e) {;} and non reentrant signal handlers and
shit. It's the nature if complex systems.

------
queensnake
Yet another reason to work at Google. They're anti- both obscure or clever
code (see their coding standards), and so far in my own experience, you get
the time you need to get the code right. There are periodic 'testing on the
toilet' pieces to remind you to refactor ruthlessly as you go, and, on how to
bring up and gather support for fixing technical debt, with your team. I
haven't seen this at any other place I've worked, quite the opposite. It's a
luxury.

------
elb0w
Real world code doesnt suck in my opinion. The issue is that a lot of the time
it solves problems that these books don't need to. Its easy to build an
alogirthm and print it when you know every edge case.

If you would take the first version of most production code put it in a book
and write the problem it solves, I'm sure you wouldn't think it sucks. My exp
developer 15years, finance industry 7.

------
nanidin
Not that textbook code is that much better ;)

------
rasur
"You are what you eat", when applied to software is something along the lines
of "software's eating the world, and the world is turning to crap".

We've all seen it, at least those in the audience that have worked at some
corporate of any size.. maybe "start-ups" face similar issues, it's difficult
to get a consensus there.

------
ericssmith
A more revealing and accurate look at software in the real world is 'Big Ball
of Mud': <http://www.laputan.org/mud/>

As a Haskell programmer, I thought the Taliban comment was funny.

~~~
geoka9
As a non-Haskell programmer (who's had to deal with code in Haskell) I think
it's spot-on.

------
andybak
Note to OP. Linking to the print version might hide some crud but it makes the
line length too wide to be comfortable reading.

~~~
SquareWheel
I usually use the print version + Readability for the best of both worlds.

------
dscrd
More important: The code you write in the real world will also suck.

------
michaelochurch
This guy shits all over his credibility by turning it into a language war. He
clearly is out of his depth on the Haskell issue, and I know credible people
who think highly of q and kdb (which are rare outside of finance, but
ubiquitous in finance).

That said, he's got a point, but the only solution he gives is "Include some
comments!" I've seen so many shitty comments that I really think this is no
advice at all.

Four levels of software maturity. (There are others. This is a simplified
model.)

Level 1: Your work doesn't exist until it's in version control. It might be
amazing to 2012-era programmers that this could be controversial, because even
the laggards have reached L1 maturity, but at one time, it was. (See: the Joel
test.)

Level 2: Your work doesn't exist until it has tests at multiple levels (e.g.
unit and integration). Otherwise, it has no enforced semantics.

Level 3: Your work doesn't exist until it has well-documented semantics _in
addition to_ the tests, which cannot cover all cases. Otherwise, how does one
even decide what a "bug" is?

Level 4: Your work doesn't exist until you've provided the resources (e.g. a
code walk or an interactive module) to _teach people_ how to use it.

If you're at Level 1, you won't lose source code. If you're at Level 2, your
breakage rate will be reduced, and you can run CI. At Level 3, your system
integrity will remain decent because you don't end up with those software-as-
spec modules that, over time, corrupt the whole system.

Guess what? It takes Level 4 to get good code. Unless there is a culture of
teaching (incremental code reviews are not enough) within the company, you
will not have good code for very long. Since engineers are intolerant of
context switches and in-person teaching doesn't scale, the teaching should be
automatic. Interactive modules or, at the least, code walks should come with
the technical asset being demonstrated. If people don't know _what_ they are
looking at, then how can they be expected to review or maintain code. With the
worst code, it's not even clear _why_ it's bad. It's just incomprehensible.

~~~
mikegioia
Come on! He makes __one __reference to Haskell, links to the SO post on it,
admits he has never used it, and all of a sudden he "shits all over his
credibility by turning it into a language war"? It's an example of how ugly
code can get for goodness sake.

~~~
spacemanaki
The Haskell code snippet is from a _parody_ of Wikipedia, and is purposefully
obfuscated code. Imagine someone holding up a piece of code written in C from
an IOCCC entry, as an example of how C is a language to be avoided.
Additionally, bringing it up is a total non sequitur, because Haskell doesn't
have much to do with the problems the article discusses, and neither does APL.

I think it does ruin the author's credibility. They didn't do the most basic
research before including that code snippet, and are just holding it up as a
distracting side show. The rest of the screed might have some value, but I'm
pretty skeptical of that after reading the last paragraphs.

------
dschiptsov
The problem of bad software is too big for one post, and there are multiple
causation, of course. Mostly it is incompetence, over-management, pay per line
of code in a 9 to 5 shifts, while the resulting product is not anyone's
problem. It has something to do with forced collectivization and wage labor,
while everyone concerned only with oneself.

The good analogy is with writing a poetry and professional writing in general.
There are many examples of technical and scientific books produced by two or
free authors (they could list ten, but actual work was done usually by no more
than a couple). But we haven't seen any decent book produced by a mediocre
writers on 9 to 5 shifts. The idea that this will work for programming is very
naive one.

Another analogy is engineering, which is also done by few capable individuals
with help of others. There are nothing but failures when mediocre groups
trying to engineer anything. On the contrary, we had lots of things invented
by capable individuals, things that later were polished by later generations.

So, if one looking for an example of good software look at individuals, or
small groups lead by one capable visionary, and avoid anything created in
sweat-shops. Most of the really good software we have (Lisp, C, Unix, Plan9,
Emacs, vi, nginx, redis, postgres, Informix, etc) was created by an individual
effort of men of unusual capabilities, and then polished by community.

Good software engineering is as rare as good poetry, and it cannot be produced
by any amount of a manual labor.

There are people who can sell you products and solutions, even ready processes
which, they say, will guarantee that you can create good software employing
mediocre coders in 9-to-5 shifts. It is all Java or Scrum scams is all about.

It is not tools that create software or invent things, it is minds, the same
way no typewriter or fountain pen could make one a poet.

------
gd1
What a terrible article. That line of APL is sheer beauty
(<http://www.youtube.com/watch?v=a9xAKttWgP4>) - being ignorant of a
language's syntax and not willing to invest the time to learn it is no reason
to claim it is 'impenetrable'. I'm sure sheet music, replete with quavers and
semi-breves and treble clefs is impenetrable the first time you see it, but
once learned is far superior to playNote(double hertz, double duration).

Worse, it goes against his point just a paragraph earlier. The whole advantage
of Q/K/J/Haskell style languages is that once skilled in them, the code is
much (as in 10-20 times) denser than the equivalent OO-style code, and the
entire flow can be grok'ed with ease. There is much less danger of over-
engineering in those languages.

