37 ms·

Programming is for Stupid People

118 points by DanielBMarkham 16y ago

blub 16y ago
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.
argv_empty 16y ago
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.
- mfukar 16y ago
  I won't refer to subjective views of intellect, but one of the WAIS IQ tests' component is the Verbal Comprehension Index. Among other things, it aims to measure the degree of general information acquired from culture by the person and her ability to deal with abstract social conventions, rules and expressions, as well as her vocabulary. To me, each of those three subtextually imply a certain degree of memorization, or accumulation of knowledge if you will. 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'.
- Xurinos 16y ago
  In several circles I have heard "smart" defined as knowing facts and "intelligent" defined as a measure of being able to learn. Hence, you can be intelligent but not smart and smart but not intelligent. I think we want a balance of the two with a lean towards intelligence. It is all semantics anyway, but you seemed to take issue with the specific term "smart", and this is probably what he meant.
  - kls 16y ago
    I have always delineated knowledge and wisdom. Knowledge is knowing something, while wisdom is the application of self constructed ideas to an event, some times drawing upon knowledge (learned information, past experiences) to construct those ideas. knowledge != wisdom. The problem wit ha word like smart is it is contextual so smart can me knowledge. I mean a guy like rain man could be consider smart in a certain regard even though he cannot apply his ability. But also smart can mean wise I would look at a guy that does not know a lot of facts but can built a rocket in his back yard as smart. So smart tends to represent a spectrum of intelligence and is a hard word to apply because people have different measures of what they consider smart.
- Tamerlin 16y ago
  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.
  - mechanical_fish 16y ago
    In modern culture, that rote memorization is what passes for "smart" now. 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.
    - Tamerlin 16y ago
      "Not for long. Mobile Google has turned Trivial Pursuit into a typing competition." 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.
- joe_the_user 16y ago
  That might be why people rejected his F# argument. 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.
kls 16y ago
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.
- ohyes 16y ago
  "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." 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.
Xurinos 16y ago
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.
- kls 16y ago
  I have yet to be convinced that any other development philosophy other than OO is superior when it comes to the UI. I will concede that OO offers little advantage when writing services, accessing databases, and integrating systems. But for the UI having self encapsulated widgets that can be extended to add distinct functionality is far superior to procedural, functional or declarative. Having a select box that can be extended to create a filtering select box with only the functionality for filtering needed is a no brainer. As well having the UI elements functionality represented by a distinct object helps isolate that code and functionality away from the larger system, with a defined interface so that it can be reused as needed without external dependencies. OO manages the hierarchy of code and its bisection in a manner that is far more comprehensible when it comes to UI, AI and game development. The rest is just preference.
  - Xurinos 16y ago
    What exactly are people talking about when they are discussing these differences? You mentioned "procedural" and "declarative"; how is that something wherein OO can be in opposition? In other words, how are you programming your class methods, and how are you programming the things that call those methods in a way that is not "procedural, functional, or declarative"? 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); Did I program that with OOP? How can you tell? Is it just syntax (because we can rearrange syntax)? x = new(Complex); x->set_real_part(4); x->set_imag_part(10); imag_part = x->get_imag_part(); And back to my hint: x = new(Complex); x = x->set_real_part(4); x = x->set_imag_part(10); imag_part = x->get_imag_part(); x could be a function.
Timmy_C 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.
- gaius 16y ago
  Haha, yeah, that would be typical Slashdot - sneer at VB.NET then go right back to PHP...
  - Retric 16y ago
    .Net get's more respect on HN than you might think. IMO it goes something like Python > .Net > Java.
dasil003 16y ago
The article is decent, but the HN-bait title is a work of art.
- rjett 16y ago
  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.
- hvs 16y ago
  I was going to post something about that as well, but then I saw that you have already taken care of that. The article was somewhat interesting, but I didn't feel that the title flowed naturally from the content.
jpschorr 16y ago
Reminded of Tim Bray's 'Forget the defaults': http://www.tbray.org/ongoing/When/201x/2010/06/29/No-Defaults http://www.tbray.org/ongoing/When/201x/2010/06/29/No-Default...
mikeytown2 16y ago
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/ http://www.garfieldtech.com/
keyist 16y ago
"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.
- anonymous245 16y ago
  Well said. 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.
- alextgordon 16y ago
  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".
roadnottaken 16y ago
I think this is basically a re-statment of Larry Wall's three virtues of good programmers: http://c2.com/cgi/wiki?LazinessImpatienceHubris http://c2.com/cgi/wiki?LazinessImpatienceHubris TFA says programming is for stupid people, but I'd argue he meant lazy.
gasull 16y ago
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 16y ago
  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.
gintas 16y ago
I'm not so sure that FP code is so much superior to OO code in terms of reusability as the article implies.
8ren 16y ago
> 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 16y ago
  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.
seanalltogether 16y ago
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.
kmak 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.
photon_off 16y ago
Presumptuous, controversial, relevant. What a beautiful HN link-bait title.
singular 16y ago
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 16y ago
  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 16y ago
    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-smart.html http://steve-yegge.blogspot.com/2008/06/done-and-gets-things...

118 points by DanielBMarkham 16y ago

blub 16y ago

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.

argv_empty 16y ago

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.

mfukar 16y ago
I won't refer to subjective views of intellect, but one of the WAIS IQ tests' component is the Verbal Comprehension Index. Among other things, it aims to measure the degree of general information acquired from culture by the person and her ability to deal with abstract social conventions, rules and expressions, as well as her vocabulary. To me, each of those three subtextually imply a certain degree of memorization, or accumulation of knowledge if you will. 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'.
Xurinos 16y ago
In several circles I have heard "smart" defined as knowing facts and "intelligent" defined as a measure of being able to learn. Hence, you can be intelligent but not smart and smart but not intelligent. I think we want a balance of the two with a lean towards intelligence. It is all semantics anyway, but you seemed to take issue with the specific term "smart", and this is probably what he meant.
- kls 16y ago
  I have always delineated knowledge and wisdom. Knowledge is knowing something, while wisdom is the application of self constructed ideas to an event, some times drawing upon knowledge (learned information, past experiences) to construct those ideas. knowledge != wisdom. The problem wit ha word like smart is it is contextual so smart can me knowledge. I mean a guy like rain man could be consider smart in a certain regard even though he cannot apply his ability. But also smart can mean wise I would look at a guy that does not know a lot of facts but can built a rocket in his back yard as smart. So smart tends to represent a spectrum of intelligence and is a hard word to apply because people have different measures of what they consider smart.
Tamerlin 16y ago
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.
- mechanical_fish 16y ago
  In modern culture, that rote memorization is what passes for "smart" now. 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.
  - Tamerlin 16y ago
    "Not for long. Mobile Google has turned Trivial Pursuit into a typing competition." 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.
joe_the_user 16y ago
That might be why people rejected his F# argument. 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.

kls 16y ago

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.

ohyes 16y ago
"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." 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.

Xurinos 16y ago

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.

kls 16y ago
I have yet to be convinced that any other development philosophy other than OO is superior when it comes to the UI. I will concede that OO offers little advantage when writing services, accessing databases, and integrating systems. But for the UI having self encapsulated widgets that can be extended to add distinct functionality is far superior to procedural, functional or declarative. Having a select box that can be extended to create a filtering select box with only the functionality for filtering needed is a no brainer. As well having the UI elements functionality represented by a distinct object helps isolate that code and functionality away from the larger system, with a defined interface so that it can be reused as needed without external dependencies. OO manages the hierarchy of code and its bisection in a manner that is far more comprehensible when it comes to UI, AI and game development. The rest is just preference.
- Xurinos 16y ago
  What exactly are people talking about when they are discussing these differences? You mentioned "procedural" and "declarative"; how is that something wherein OO can be in opposition? In other words, how are you programming your class methods, and how are you programming the things that call those methods in a way that is not "procedural, functional, or declarative"? 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); Did I program that with OOP? How can you tell? Is it just syntax (because we can rearrange syntax)? x = new(Complex); x->set_real_part(4); x->set_imag_part(10); imag_part = x->get_imag_part(); And back to my hint: x = new(Complex); x = x->set_real_part(4); x = x->set_imag_part(10); imag_part = x->get_imag_part(); x could be a function.

Timmy_C 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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.
gaius 16y ago
Haha, yeah, that would be typical Slashdot - sneer at VB.NET then go right back to PHP...
- Retric 16y ago
  .Net get's more respect on HN than you might think. IMO it goes something like Python > .Net > Java.

dasil003 16y ago

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

rjett 16y ago
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.
hvs 16y ago
I was going to post something about that as well, but then I saw that you have already taken care of that. The article was somewhat interesting, but I didn't feel that the title flowed naturally from the content.

jpschorr 16y ago

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

mikeytown2 16y ago

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/ http://www.garfieldtech.com/

keyist 16y ago

"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.

anonymous245 16y ago
Well said. 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.
alextgordon 16y ago
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".

roadnottaken 16y ago

I think this is basically a re-statment of Larry Wall's three virtues of good programmers: http://c2.com/cgi/wiki?LazinessImpatienceHubris http://c2.com/cgi/wiki?LazinessImpatienceHubris TFA says programming is for stupid people, but I'd argue he meant lazy.

gasull 16y ago

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 16y ago
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.

gintas 16y ago

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

8ren 16y ago

> 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 16y ago
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.

seanalltogether 16y ago

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.

kmak 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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.

photon_off 16y ago

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

singular 16y ago

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 16y ago
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 16y ago
  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-smart.html http://steve-yegge.blogspot.com/2008/06/done-and-gets-things...