
Programming is for Stupid People - DanielBMarkham
http://www.whattofix.com/blog/archives/2010/10/programming-is.php
======
keyist
"Instead we reward people for being smart -- for learning more and more
details about trivial libraries that will be deprecated in ten years' time."

I get what the author is trying to convey in this post, but I feel he is
unintentionally attacking a strawman.

I don't think many developers set out to memorize small details of libraries
-- it's just something they pick up naturally over time with more usage.

My take is: on the surface, knowledge based on experience often _seems_ like
memorization. That's because when say Alice brings up a better
way/library/tool, she's acting as a layer of abstraction.

You don't immediately get to see the internal processing Alice is doing to
decide which library to use and why it is the best choice for your specific
task. All you see is her output: "here's what you use in this situation". This
isn't about knowing trivial details of libraries. It isn't about rote
learning. It is the practical application of knowledge borne out of
experience.

That experience is what is being rewarded, not the memorization. How to tell
the difference? The best developers come with introspection tools: they are
able and very willing to explain the reasoning behind their recommendations in
detail.

~~~
alextgordon
Writing code is such a small part of our jobs anyway. If it were everything,
our jobs _would_ be easy.

Most of my time is actually spent answering these questions:

    
    
      * Why isn't this working?
      * How could the user fuck this up?
      * How could another programmer fuck this up?
      * What do I want this thing to do?
      * What's the best/fastest/safest way to do it?
    

No amount of abstraction will ever fully eradicate these questions while
leaving a sufficiently general framework to work in - they characterise
programming. And they are by no means "stupid".

------
kls
I think there are two mind sets when it comes to programming, those that
relish in learning every detail in a particular technology and those that find
beauty in simplicity. (technically there is probably a third which is just a
hack).

I don't think that these two programmer see eye to eye. One looks to apply the
chains of functions to a problem to simplify the task at hand. While the other
looks to creatively attack the problem with a minimalistic approach to writing
code. They find beauty in recursion and abstraction, through interfacing
things so that common logic can provide different results based on plug-able
interfaces.

They are different mind sets entirely, where one looks to reuse existing
library code the other looks to not write as little code as possible through
creativity. Both are very valid programmer types and both can achieve mastery,
it is more just a matter of how ones mind works. I myself am the latter, I
love abstracting problems away till they just seem to disappear. I love
closures and delegates, interfaces and anonymous functions. These are my
utensils of mastery.

One thing I have noticed though is that programmers tend to work better with
other programmer of the same type. For most of my career I have worked with
the same development team. Many of the guys I trained and then they trained
others. We are like a caravan of programming gypsies one of us would find a
position at a start-up or find backing and the rest would follow in time.

Anyway, after the sale of the last company we where at I had to go out and
find a real job. I did, and the entire team was of the other type it seems
that they had amassed in a similar fashion as my group of developers and ended
up there. Anyways, I have to say, for the first time in my life I was a drag
on the team it just seemed that my code and their code just never jived, i
mean it all worked properly but when I would have to work on one of their code
or they would have to work on my code it was just hours of lost productivity.
I eventually resigned because it was clear that for the first time in my life
I was not working out as a developer. I was just mediocre at doing it there
way.

Anyway, just food for thought, maybe you are like me Daniel and see the
elegance of code. While the other guy sees the robustness.

~~~
j_baker
"I think there are two mind sets when it comes to programming, those that
relish in learning every detail in a particular technology and those that find
beauty in simplicity. (technically there is probably a third which is just a
hack).

I don't think that these two programmer see eye to eye. One looks to apply the
chains of functions to a problem to simplify the task at hand. While the other
looks to creatively attack the problem with a minimalistic approach to writing
code. They find beauty in recursion and abstraction, through interfacing
things so that common logic can provide different results based on plug-able
interfaces."

You've essentially just described the difference between a left-brained person
and a right-brained person, although I'm not sure this has much to do with
whether you like using libraries or not.

Left-brained people use the language centers of their brain more heavily.
That's why they spend so much time trying to come up with the right names,
adding comments, and adding documentation while ignoring useful abstractions.

Right-brained people build instinctual models in their heads. That's why they
spend so much time thinking out interfaces and how things fit together and so
little time thinking about the semantics.

The only thing I'd be careful of is in using terms like "simplicity",
"creativity", and "elegance". The left-brained guy thinks his code is just as
simple, elegant, and creative as the right-brained guy thinks his is. The
difference is what they're measuring these things by.

In general, I think the ultimate goal is for these two types to learn working
together. That can be a very great thing for a team, but can be fairly
frustrating.

~~~
kls
_The only thing I'd be careful of is in using terms like "simplicity",
"creativity", and "elegance"._

Sure, that is my perspective because it is the code I tend find compelling but
yes they are matters of subjective opinion.

------
dasil003
The article is decent, but the HN-bait title is a work of art.

~~~
rjett
Daniel writes primarily for the HN audience I think, so you might say he
optimized his choice of words in the title, given his audience.

------
8ren
> Things I _probably_ am going to reuse in other projects. [emphasis added]

Fred Brooks said that a "programming product" takes about 3 times as much work
as a plain program (so it becomes a module reusable by anybody). The extra
work is in things like generalizing, testing and documenting. He claimed that
a "programming systems component" takes about three times as much work again
(that is, a module reusable somewhere else), with the work going into things
like precisely defining interfaces, and integration testing. _p.6-7, MM-M_. He
said all that long before _object oriented_ was coined (even before ADTs), so
he wasn't talking about objects, but about code reuse in general.

What's the evidence? We see notoriously few FP libraries, but 10,000's of Java
libraries (as an OO eg). The latter is a major reason touted by JVM languages
for targeting it.

While FP individuals do seem to reuse their own code quite a bit, the code
reuse of _systems programming products_ remains mostly theoretical for FP -
but standard practice for OO.

I think a more relevant distinction is between _component consumers_ and
_component producers_. The former learns libraries; and latter creates them.
The former is closer to the customer and their application domain (where value
becomes tangible); latter is closer to the raw materials, the essence of
programming and nature's wild bounty (where value originates).

~~~
jackfoxy
I'm still very much a novice at FP, but seeing as far as I can through my
keyhole view I think FP offers a different, and in some ways deeper, level of
absraction than OO, providing more re-use to the individual who becomes
proficient, but less publishable reusable code.

Here's what I mean by that. The author, in talking about the reusable
functions he writes for the kind of tasks he performs is really creating a
domain specific language (or fragments of a language) addressing his
programming domain, whatever that is. The extra work that would be involved to
make this reusable for other people is daunting, primarily because he can be
fast and lose in defining his domain for his own personal use (in fact he may
not even reflect on the fact he is defining a domain), but for his domain
specific language to be useful to others he would have to be far more rigorous
in domain definition, with all the attendant documentation, use case testing,
etc. This level of effort is way beyond the level of effort require to define
an OO framework, for instance. Therefore he produces something that provides
him a deeper level of abstraction, but is not useful enough to others.

------
singular
What frustrates me about this article is the false dichotomy of 'smart
solutions to problems' vs 'simple solutions to problems' - especially when it
comes to C# vs. F#, languages I know well.

The whole point of programming languages is to make it easier for human beings
to understand each other's + their own code; a computer could, in theory,
accept code via binary tapped in on a front panel, it really doesn't care how
it gets told what to do.

The point is that code quality is pretty well the same thing as simplicity -
there is no dichotomy here. Like @keyist said, a strawman.

It's also important to remember that there are things that a language can
achieve that simply no library can; the whole point of much of FP is to make
it _easier_ to write code simply. Pattern matching, type inference, tuples,
immutability, these are not 'tools for smart people', they make it easier to
write code which is declarative, and thus more clearly expressing what the
programmer _meant_ rather than how he goes about it.

Additionally, I don't think we should cede to the programmer who says 'I'm
stuck in my ways and can do it all with libraries, blah' - that's a red flag
in my view - a programmer who is not willing to constantly improve and
question their work (can I make this better? How do I improve this?) - is
likely to be the kind of programmer who produces code of a certain (almost
certainly low) quality and has no means of improving on that. The 9-5 Bobs.

Let's not mistake inertia + fear of learning something new for wisdom, please.

~~~
GFischer
In defense of the Bobs, I must say that some of us aren't programming just for
the love of programming, and you have to be pragmatic.

I'm certain there are a lot of better solutions to what I'm doing, but I'll do
them the way I know today, and try to learn a better way tomorrow.

The programmer that doesn't want to learn a new way, ever, yes, that's not a
good programmer.

~~~
singular
Sure, and I don't claim to be a great programmer by any stretch, rather it's
the willingness to improve and to be open to things, within practicality.

'Smart and Gets Things Done' :)

Although I do like 'Done and Gets Things Smart' - [http://steve-
yegge.blogspot.com/2008/06/done-and-gets-things...](http://steve-
yegge.blogspot.com/2008/06/done-and-gets-things-smart.html)

------
argv_empty
_Instead we reward people for being smart -- for learning more and more
details about trivial libraries that will be deprecated in ten years' time._

Having memorized a lot of facts is not what I think of when I hear someone
described as smart. I think of the ability to find and synthesize new
information. Memorizing facts is often a waste of time that could have been
spent working out their implications and deriving new knowledge.

~~~
Tamerlin
In modern culture, that rote memorization is what passes for "smart" now.

Memorizing facts is _always_ a waste of time.

The biophysics professor that I worked for in college had that attitude. He
studied protein structure, but rather than wasting his time memorizing the
structures of amino acids, he just worked with them, and eventually the
knowledge of their structures became second nature. In biochemistry, the
professors tried to make everyone memorize all of those structures... but even
the professors didn't get them all correct.

Those same professors couldn't explain basic things like ionization, or make
sense of the fact that .1 cm = 1mm.

~~~
gaius
_Memorizing facts is always a waste of time._

Not true. Knowing the APIs you most commonly use instead of having to keep
flicking back to the reference makes you much more efficient.

Your professor DID memorize them, he was just smart about how he did it.
Instead of memorizing upfront, he did it in bitesize pieces, and was
productive along the way. That's what a good programmer does too.

~~~
Nekojoe
This way of memorising things is called Chunking -
<http://en.wikipedia.org/wiki/Chunking_%28psychology%29>

Chess champions use this technique too. I remember seeing a TV documentary
where they got a chess champion to look at a board layout for a few seconds
and reproduce it in front of them. They could do this easily for a valid board
layout. But when they got people with no knowledge of chess to design the
board layout in an invalid manner the chess champion could not reconstruct the
board as accurately or as quickly.

I guess a common programming equivalent would be a design pattern.

------
Timmy_C
This article seems to be following the "Microsoft frameworks are for simple
programmers" theme that I've been seeing more and more of here on Hacker News.

I don't know if that's bad or good since I've never really had to work in a
.NET environment but I would hate for this article to be the embers of a
forthcoming flame war.

~~~
contextfree
I don't think that's the point at all. If anything it's "some Microsoft
frameworks are too big and complicated" (but others - F# - aren't so let's try
those)

~~~
hvs
F# is just another CLR language, so the "Framework" is just as big under F# as
it is under C#. It's just a different way of looking at development
(specifically, the OCaml way).

.NET is big because it actually contains _a lot_ of useful APIs. I think this
is a natural outgrowth of a framework that attempts to be all things to all
people.

I'm not a .NET apologist, but I use it every day at work and it has it's
strengths and weaknesses (like everything), but overall it is a fairly well-
designed framework. My biggest beef with most .NET development is that you
have to do it on Windows...

~~~
MartinCron
_My biggest beef with most .NET development is that you have to do it on
Windows..._

I once shocked a Windows "Platform Evangelist" when I told him the only thing
I needed Windows for was Visual Studio.

------
Xurinos
_OO code, on the other hand, is rarely reused._

This is true in situations where OO is done wrong. OO is supposed to help us
implement types, and you can do this portably. You can write bad functions,
too, that have too much dependency on things specific to your framework. This
is not a matter of FP vs OOP but of writing portable code, which neither
approach forces you to do.

FP vs OOP is not a real conflict anyway. The two are compatible.

~~~
jcromartie
I have yet to see OO objects live on from one internal project to another.
It's always the same cycle: design domain model objects; let them grow/bloat
for the purposes of the project; end up redesigning them the "right" way for
the next project.

~~~
Xurinos
Assuming we are talking about classes, I am glad someone released Path::Class
for perl, among many other class packages. This is a social problem, not a
problem with the technology.

~~~
billswift
Except to the extent that the technology exacerbates the social problem. Or
even just enables the social problem to continue.

------
mikeytown2
Over in Drupal land we are talking a lot about the direction we want to take
Drupal 8; FP vs OOP.

The last couple of posts on this blog are a good read.
<http://www.garfieldtech.com/>

------
roadnottaken
I think this is basically a re-statment of Larry Wall's _three virtues of good
programmers_ :

<http://c2.com/cgi/wiki?LazinessImpatienceHubris>

TFA says programming is for stupid people, but I'd argue he meant _lazy_.

------
gasull
FTA: _FP says that you don't have to have 20 thousand libraries. Or rather,
you're welcome to have as many libraries as you want, but you develop those
30-70 functions that you use most often in your job and re-use them Instead of
learning a new problem domain for each project and then working inside of it
little piece by little piece, you're creating you own minimal set of symbols
that work on all of your projects, thereby making each new project more and
more trivial._

Would anybody mind making a non-comprehensive list of these 30-70 functions?

I know the article says they're specific for each job, but I'm sure there's an
overlap among most of them.

~~~
alnayyir
The attitude of spinning your own mini environment to solve a variety of
problems using the exclusive set of idioms known best to you reeks of what has
plagued Forth and C++.

I love functional programming, but I don't think this animosity towards using
known, tested libraries is all that healthy.

------
kmak
I feel for you -- whenever I try to write about basic algorithms (sorting,
etc) I always get comments that you can do it in library. Yes, obviously, but
I'm teaching an algorithm, not how to use a library!

~~~
anthonyb
You still need to know what your library's performance is like under various
conditions - large or small numbers of items, whether comparisons are cheap or
expensive, how much extra memory it takes up, etc. If you don't understand the
library, how are you going to be able to use it, except in relatively trivial
cases?

~~~
kmak
I don't debate library usage (reuse!), but I teach mostly theory, with code
snippets to present algorithms concisely.

There are many tools to solve a problem, and I want to educate on a different
layer. For instance, in sorting alone there are many sorting algorithms, I
don't expect someone to interrupt me with "just use quicksort!" when I'm
teaching bubblesort. There are lessons to learn in both, but it's a bit
presumptuous (or at least, there are less smug ways) to assume ignorance, and
not intention.

~~~
anthonyb
Sorry - that was sort of my point, but I didn't put it very well. Your student
likely isn't taking any of that into account. One way to get your point across
is to ask them a few pointed questions about (eg.) the data set that they're
sorting. If it's relatively small, then the overhead of quicksort might not be
worth it. If it's already mostly sorted, then bubblesort is potentially
better, and so on.

------
jpschorr
Reminded of Tim Bray's 'Forget the defaults':
[http://www.tbray.org/ongoing/When/201x/2010/06/29/No-
Default...](http://www.tbray.org/ongoing/When/201x/2010/06/29/No-Defaults)

------
seanalltogether
If you ask an engineer if other engineers should work toward standards or make
up their own, they'll tell you every time that engineers should work against
standards.

In the programming world, libraries represent those standards and every time
you try to roll your own solution to a well explored problem, you're telling
the rest of the world to avoid your code.

------
blub
I don't see the connection between FP, OO and code reuse. Is there proof that
using FP automatically leads to higher code reuse? That OO code is not reused?

Anyway, the biggest benefit of OO is abstraction & encapsulation, not code
reuse.

------
photon_off
Presumptuous, controversial, relevant. What a beautiful HN link-bait title.

------
gintas
I'm not so sure that FP code is so much superior to OO code in terms of
reusability as the article implies.

