Programming is for Stupid People
whattofix.com
whattofix.com
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.
I've read that memory is an integral strength of high performers in fields such as chess and music.
And btw, you can extend this casual dismissal of expertise to knowledge of algorithms and data structures too. Would this author be equally dismissive if somebody pointed out that, what he was solving was an application of so-and-so algorithm.
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?
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.
These don't strike me as conflicting traits. I can love succinct solutions and still like knowing minute details about what I'm using. (It seems like a requirement for the best solution).
(You need these traits if you want to 'hack/kludge' in changes to an existing (ugly) system without breaking it; so you can be a terrible hack too!)
You would have to provide a proper definitions of simplicity, beauty, etc.
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.
Sure, that is my perspective because it is the code I tend find compelling but yes they are matters of subjective opinion.
The article was somewhat interesting, but I didn't feel that the title flowed naturally from the content.
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).
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.
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.
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.
'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...
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.
Alternatively, one could say that knowing your tools is quite important. I mean, I'd consider someone who learns, forgets, and relearns what a screwdriver does not to be the definition of 'bright'.
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.
Not for long. Mobile Google has turned Trivial Pursuit into a typing competition.
I'd also question the use of the phrase modern culture here. In nonliterate cultures memorizing facts didn't just pass for smart, it was smart: An unmemorized fact was an unrecorded fact. In pre-Gutenberg literary culture paper, ink, and literacy itself were still sufficiently rare and expensive -- and entire books so much more expensive -- that it was still an important skill to be able to memorize lots of things.
(Those were the days when books were so costly that universities owned one copy of each book, and "education" consisted largely of copying out books that were read out to you by the lecturer. If you didn't copy down every word of Galen correctly as it was read out, you might be doomed to cite Galen wrong for the rest of your life, because it's not as if you were likely to be able to afford a copy written out by someone else.)
Now that paper is mass-produced by the ream, mass literacy exists, and even visual and auditory memory is heavily augmented by portable digicams and audio recording tech, we can afford to memorize less than ever before in history.
I hope you're right.
"I'd also question the use of the phrase modern culture here."
You make a good point.
It reminds me of the Aborgine's navigation technique referred to as "Songlines" or "Dreaming Tracks" -- they didn't have maps and instruments to navigate with, so instead they told stories. With those stories, they could convey not only a route, but also the locations of water holes and foraging grounds, and by using the story as a mnemonic, it was easy to learn and remember as well as to pass on to another.
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.
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.
That said, we're saying the same thing -- rote memorization without applied knowledge isn't worth anything. Learning by doing is the way to go.
Or it might be that functional programming was reaching a level of abstraction that didn't make it especially useful for the problem at hand.
One could argue that bringing in a functional language first thing is somewhat akin to "big, upfront design" in the sense that it assumes a level of abstraction before you have complete knowledge of the domain.
The thing is that neither is bad, you do need some abstraction to start with. But both can be taken too far.
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.
.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...
I once shocked a Windows "Platform Evangelist" when I told him the only thing I needed Windows for was Visual Studio.
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.
OOP is not a philosophy. It is a way to glue data together. OOP is not separate from "procedural, functional, or declarative" programming, so it cannot possibly be "superior". I object to this becoming a religion or a we vs them.
Here is an example for clarity:
x = new(Complex);
set_real_part(x, 4);
set_imag_part(x, 10);
imag_part = get_imag_part(x);
x = new(Complex);
x->set_real_part(4);
x->set_imag_part(10);
imag_part = x->get_imag_part();
x = new(Complex);
x = x->set_real_part(4);
x = x->set_imag_part(10);
imag_part = x->get_imag_part();
philosophy: any personal belief about how to live or how to deal with a situation; "self-indulgence was his only philosophy"; "my father's philosophy of child-rearing was to let mother do it"
It's not a science, it is a philosophical view point on how code should be arranged. So for me philosophy best fits the definition of the abstract concept that is a though process enshrined in code in particular adherence to a philosophically composed structure. I think philosophy fits the bill quite well.
I think you miss the point, functions and data existing outside of the class do not encapsulate the code base, so for you example, what if I write a widget for the UI and I want to give that widget to my friend, but not my project. In you example, I have to package up the functions, which may or may not reside with other functions, then you have to package up the data and again many or may not. Further the API does not float with the widget, so my friend has to design non conflicting entry points in his system to ensure that those functions are now available to the data for manipulation.
You are introducing external dependancies to a concept that by all intents and purposes can stand alone. OO promote reusability, because it boxes everything you need into a class and that is why when specifically applied to the UI where there is a lot of inherent reusability of items that deviate slightly it provides great application.
External dependancies are the nemesis of isolated components and your example shows why. You are looking outside the object at how it is used by the system. You are looking at how you call and use that class not how it relates to the overall system and keeps itself from becoming intertwined with it, all of the is dealt with inside the class not outside because it is inherent to OO.
Inheritance is a whole other aspect of why it is superior in this context and again it has to do with limiting external dependancies. Being able to extend a code base and suppress existing functionality while adding new novel functionality allow one to build on an existing item while still allowing the existing items to stand independent of that relationship. This allows my friend the ability to build upon my code base while leaving my code base intact. Therefore when I update my code base so long as I do not modify the existing contracts he can take upgrade in whole with no issue and no modification to his existing system. Now I know all this can be done with functional languages, the point is that it is simpler with OO and that is the crux of the issue.
I was thinking about this assertion on a walk, and I realized that this is just a matter of opinion. I can see it apply if you were programming with Tk. The same goes for Gtk, but when you add glide, the UI construction becomes declarative, and to be honest with you, I have preferred that style of UI construction over having to figure out my arrangements by pencil and paper. I would say that for 90% of your cases, you are not writing a truly dynamic UI that requires OOP to construct things.
When we talk about responding to events, we respond with functions. Presumably, we bury those functions in random placeholders, like a class dedicated to the callbacks, but they are still just functions that describe how to behave.
When I do web programming, I find myself with a mixed approach: HTML and CSS (declarative), javascript with jQuery (OOP and functional).
jQuery is an interesting use case of the blending of OOP and FP. Consider that when you make changes to objects in jQuery, a jQuery object is returned. Thus, you can chain things like this:
jQuery(element).action().action().action();
In you example I have to package up the functions
Packaging issues really have little to do with OOP.
Yes. One way to do that is with a class. Another might be a package or namespace. Organization is a social issue. What you described is not a strength of OOP. In fact, the way most people I have seen do OOP is bulky because they are trying to mitigate this packaging issue: they try to put everything into one single class that is easy to share, as opposed to breaking it down to its logical parts with multiple classes.
Take a simple textarea widget, for example. Let's say you want to extend it to have a spell-checking feature. You extend the class to be TextAreaWithSpellChecking. The typical poorly designed resulting class will include the spell-checking code as opposed to implementing spell-checking in a separate module. It is easier to send the single class than multiple classes, right? Where should the spell-checking live? The answer is not about OOP or FP or other approaches/tools. It is about how you choose to abstract and break things apart.
The reason, everything is implemented on the jQuery tree and you have to chain stuff together. So long as you don't have to extend jQuery, it works well, but as soon as you have to provide a large code base with custom plugins to manage the code it becomes untenable quickly. I know I have done quite a few of them. Please don't take this as me knocking jQuery, I love it and use it extensively for quick solutions in which I am going to use existing functionality, but if you have a problem set that grows beyond whats in the box or that you can't find in a box. It becomes a massive time sink.
One of the major reasons is it does not have the concept of jQuery code existing outside of the jQuery tree you build on jQuery and not with jQuery while subtle it is a huge distinction. It is a monolithic philosophy, you have a hard dependency on jQuery while Dojo does require a dojo API to declare and construct objects they exist independent of the dojo tree.
It is not my intention of devolving this into a toolkit war, but I wanted to highlight that jQuery exemplifies my assertions, it is great for quick a dirty, there is nothing faster, but it does not provide the depth of a more OO centric framework for those of us that produce the building blocks that other people use.
I think this post sums up what I am trying to say better than I am communicating it: http://news.ycombinator.com/item?id=1805143
As well for sake of clarity, when I say UI development, I am not talking about putting text boxes on a page, grabbing the values and submitting them to a service. OO provides no advantage over functional in controller or work-flow logic. When I am talking about OO's advantage it is specific to new and novel UI components that are packaged for others to use off the shelf in controllers and work-flows, in fact I think OO is inferior for work-flow. Just wanted to ensure that I provided clarity on where I believe OO provides superior advantages over functional.
In fact, the way most people I have seen do OOP
sure people do bad OO they also do bad functional the reality is there are more hacks than there are good programmers. It is not an exclusive trademark of OO programmers. I will give you though bad OO is much harder to fix than bad functional. It's the nature of the beast. To quote uncle Ben "With great power comes great responsibility".
I realized that this is just a matter of opinion
You are correct it is my opinion, that is why when I posted my first comment I called it a philosophy. It is all opinion, some of it relies completely on how an individual developers mind works. But for me, and most of the developers that I know that have been doing UI for a long time the opinion is that OO provides a superior philosophy. If you find that something suits you better by all means use what works for you.
In python, for example, there are a number of useful and reusable objects. The 'function' object, the 'module' object, the 'str' object, etc..
I think object-oriented code is slightly more prone to being portable-but-not-useful because it tends to be designed around real-world models for a particular problem, while functional programming tends to prefer generic abstract models like lists, hashes, graphs, and sets.
Also, code can be useful but not obviously so. A method like org_chart.peruse, for example, might be a solidly generic and portable tree-traversing method that you'd never think to use elsewhere.
Beware the No True Scotsman fallacy:
let Write f buffer start len = f.Write(buffer,start,len)
so that you can pass functions independently of the object.
The last couple of posts on this blog are a good read. http://www.garfieldtech.com/
http://c2.com/cgi/wiki?LazinessImpatienceHubris
TFA says programming is for stupid people, but I'd argue he meant lazy.
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.
I love functional programming, but I don't think this animosity towards using known, tested libraries is all that healthy.
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.
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.
Anyway, the biggest benefit of OO is abstraction & encapsulation, not code reuse.