17 ms·

Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

504 points by tiniuclx 8y ago

tiniuclx 8y ago
An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program. Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patterns redundant? Looking at Rust through this lens makes it clear that it aims to eliminate C-style manual memory management. However, it does make me wonder: How do languages such as JavaScript and Python stand out from their predecessors, and what problems do they uniquely solve?
- jstimpfle 8y ago
  > exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does only one thing at a time, and does any one thing only in one place (ideally).
  - beaconstudios 8y ago
    compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
    - jstimpfle 8y ago
      Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?
      - beaconstudios 8y ago
        > Look up the definition of "simple". There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. I would say exceptional is a situation that is rare and unexpected. When saving a record to a table with a unique constraint, I would expect the constraint to prevent saving but I would not usually attempt to handle/recover the app running out of memory. So it's situational and I'd say the distinction is between whether you will be explicitly handling the event as part of normal behaviour. The more stable the app needs to be, the more situations need to be handled.
        jstimpfle 8y ago
        I agree and I think the conclusion is that it's up to the caller to decide what is exceptional. But unfortunately it's the callee who decides how the result is returned. And it's not only the caller, but also the caller of the caller, and so on, who needs to be prepared for exceptions. This all has severe ramifications on the code structure. > There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. Sorry. I need to control myself. It's not about you. As another commenter stated there is an agreed upon distinction between simple and easy. The distinction is important especially among programmers, and what you described might be easy but it's not simple.
        beaconstudios 8y ago
        agreed, there are better ways to handle such circumstances (such as an Either/Validation monad). But I still think exceptions are better than error codes. If you don't handle an error code, you can proceed through your application in an invalid state. If you don't handle an exception, the application crashes out. I think the latter is preferable in most circumstances.
        jstimpfle 8y ago
        Yes, and this is the reason why I'm happy with exceptions for short scripts, e.g. Python. It's a different story for larger projects where I make all the primitives by myself. There I start by explicitly aborting on cases that are not handled yet (no exceptions needed to do that), and then I gradually change the structure of the code to handle more and more "exceptional" cases.
    - kungtotte 8y ago
      Don't mix up simple and easy, they are orthogonal concepts. Exceptions are in no way simpler than C-style error codes, but in many cases they might be easier to work with.
      - beaconstudios 8y ago
        simple to use versus simple to understand. I was referring to the former.
    - woadwarrior01 8y ago
      Case in point: Python’s StopIteration exception, which is raised to indicate iterator exhaustion. A lot of efficiency can be gained by not invoking Python’s heavy exception handling machinery for this.
  - tiniuclx 8y ago
    You do have a point, adding exceptions to C++ does impact the language in many ways. They must be used responsibly: being able to jump to a completely different point of the program at any time is dangerous. However, exceptions do simplify some situations, such as when an unrecoverable error happens at the bottom of a deep call stack. Exceptions make it simple to inform the user/system that an error has occurred without adding error checks to every function in the call stack. I believe this use-case justifies the feature, especially if you can tolerate the performance loss which might not even be that bad [0]. Having the compiler check error codes is one of the reasons I enjoy Haskell so much: the type system makes you handle failure (amongst other things). [0] http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf - Section 5.4.1.2 - the table approach to exception handling has no run-time cost during normal (non-exceptional) program flow.
    - jstimpfle 8y ago
      The efficiency problem need not be the exception handling in itself (I can't say a lot about that. There are various claims and it probably depends on the tradeoffs of the language implementation). The actual problem is the ramifications on the code structure. A deep call stack with a lot of implicit context is a problem in itself. Exceptions imply a temporal coupling from error occurrence to error handling. This is a subtle but severe problem. It might start out as a noticeable maintainability problem but it's likely to quickly become a performance problem as well...
      - uryga 8y ago
        > Exceptions imply a temporal coupling from error occurrence to error handling. Could you expand on this? I understood your statement as "Exceptions sort-of force you to handle an error the moment it occurs", but I'm having trouble seeing why this would be specific to exceptions and not the case with other error handling solutions. (I don't mean to sound like a big exception-defender – I prefer ML/Rust-style Result types)
        gbear605 8y ago
- AnimalMuppet 8y ago
  I think it's also how you should pick languages for a project. What is the worst yak-shaving aspect of the code you're going to have to write for this particular project? What language will go the furthest toward making that yak shaving go away? Pick that language.
  - pjmlp 8y ago
    I pick the languages based on the platform stack I have to use and not the other way around. Basically the first class languages on a given platform, or having official bindings for a specific set of libraries that must be used. My experience has proven it is the best path for lowest attrition. Every time I decided to do otherwise I repented later on.
- pjc50 8y ago
  The wikipedia summary of the JavaScript design rational is decent; it also kind of explains why it's so odd: > In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.[11] Before he could get started, Netscape Communications collaborated with Sun Microsystems to include in Netscape Navigator Sun's more static programming language Java, in order to compete with Microsoft for user adoption of Web technologies and platforms.[12] Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax, which excluded adopting other languages such as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against competing proposals, the company needed a prototype. Eich wrote one in 10 days, in May 1995. It had to look vaguely like Java (hence ALGOL-derived brace delimited blocks rather than Scheme-derived prefix S-expressions, and the confusing name), and it had to be implemented quickly (hence the lack of typechecker and other advanced features), and it was intended to be beginner-friendly (hence all the truthiness/falsiness stuff). Javascript only succeeds because it's the only scripting language supported by web browsers, and the brief attempt at getting VBScript into browsers was even worse.
  - pier25 8y ago
    > and it had to be implemented quickly (hence the lack of typechecker and other advanced features) Since then there has been more than enough time to implement optional static types. In fact, the EcmaScript 4 proposal had those, before it was trashed in 2007 or so and the TC39 started EcmaScript 5 from scratch.
    - tabtab 8y ago
      JavaScript is fine for the job of hooking light-duty events to HTML, but people try to write entire GUI/graphics engines in it. It's the wrong tool for that job, just as you don't write an OS in TCL. The whole Web UI "standards" issue needs a big overhaul in my opinion, but Web UI's is probably off topic. (I've ranted about it in other topics.)
  - quineoa 8y ago
    This seems like an extreme case of “assume your hack will be used in production for years to come.”
randcraw 8y ago
Relevant references... A 2004 textbook by the OP: Concepts, Techniques, and Models of Computer Programming https://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695 https://www.amazon.com/Concepts-Techniques-Models-Computer-P... And his 6 week edX course: Paradigms of Computer Programming – Fundamentals https://www.edx.org/course/paradigms-of-computer-programming-fundamentals https://www.edx.org/course/paradigms-of-computer-programming...
dahart 8y ago
The footnote in section 2.1 caught my eye: > Similar reasoning explains why Baskin-Robbins has exactly 31 flavors of ice cream. We postulate that they have only 5 flavors, which gives 25 − 1 = 31 combinations with at least one flavor. The 32nd combination is the empty flavor. The taste of the empty flavor is an open research question. I honestly can’t tell if this is a good joke or serious & bad logic. The 31 flavors are obviously not a mix of 5 base flavors. If that were the case, each base flavor would be in 16 of the mixed flavors, and you wouldn’t have any unique flavors at all, like mint or cookie dough. It’s just a coincidence that the longest months in the year are 2^5-1 days.
- de_Selby 8y ago
  >I honestly can’t tell if this is a good joke... I'll help out: It's a joke.
  - dahart 8y ago
    For sure? I skimmed the whole thing and couldn’t immediately find any other jokes. Seems an odd choice to throw in one random deadpan comment about the coincidence of 31 being near a power of two.
    - mturmon 8y ago
      Definitely a joke. The "open research question" kicker makes that clear. There's a similar jokey footnote on page 33.
    - wellpast 8y ago
      > Seems an odd choice to throw in one random deadpan comment... But then again it gives the joke a special nonplussing hilarity that it wouldn’t acquire otherwise.
- fjsolwmv 8y ago
  Months are 31 days because each day is made up of 5 base elements that can present pr absent. The empty day is theorized to exist but impossible for humans to experience and report.
atilaneves 8y ago
"Popular mainstream languages such as Java or C++ support just one or two separate paradigms" Java, ok. But C++??? That language has everything and the kitchen sink, including pure functional programming (templates).
- pjmlp 8y ago
  Even Java, after lambdas and immutable data structures introduction it is quite debatable.
  - rydel 8y ago
    Having lambda doesn’t mean to be FP. One of the core features missing in Java (JavaScript also) is TCO(tail call optimization)
    - dnautics 8y ago
      Julia is missing TCO and it is for sure functional.
    - pjmlp 8y ago
      First of all not all FP languages have TCO, Scheme is probably the only one that actually requires it on its language specification. Secondly stuff like LINQ was already available in Smalltalk. So all those map/filter/fold/.... constructs from lambda calculus, which Java now enjoys. Then if we apply the modern concept of only Haskell is FP, then there are a couple of FP languages that won't meet the classification. Ah, and Haskell does not require TCO on their language specification, so it isn't an FP language according to your arbitrary definition.
      - rydel 8y ago
        It depends. As we know, FP is all about not having side effects. Having “for” loop requires to mutate the pointer of given iteration.
        8y ago
iofiiiiiiiii 8y ago
What utter rubbish. This type of paper has no place in a professional environment.
- AnimalMuppet 8y ago
  Could you give some reasons for your statement? Why do you think it's rubbish?
  - mcguire 8y ago
    He's got a point. 99.999% of programmers are never going to need to know this, and the time wasted reading it would better be spent inventioning a new JavaScript UI framework. /s.
  - lbriner 8y ago
    Like many discussions, this seems to demonstrate that a Programmer != a Developer != an Engineer != an Architect. Of course, many programmers would never need this stuff and many have no formal qualifications but they still produce what they need to without problems. They certainly do not need to know about paradigms vs concepts vs models etc. even if it is interesting. Of course, there ARE people who need to know this stuff to do their job well but they are quite up the food chain compared to most of us. They might also be corporate, who of us sits down and thinks, shall I do this in OO or functional? Which paradigm fits? Most of us know few languages and use what we know.
    - macintux 8y ago
      You're saying uneducated programmers are more useful than educated ones? I don't understand your point.
      - AnimalMuppet 8y ago
        I believe that lbriner is saying that uneducated programmers are still useful - not more useful, just useful.
- 8y ago
sevensor 8y ago
> We end our discussion of inheritance with a cautionary tale. In the 1980s, a very large multinational company initiated an ambitious project based on object-oriented programming. Despite a budget of several billion dollars, the project failed miserably. One of the principal reasons for this failure was a wrong use of inheritance. Who did that, exactly?
- ummonk 8y ago
  I would have guessed Plan 9 just from the timing, but I'm not sure the failure there was due to the wrong use of inheritance.
  - angersock 8y ago
    That most certainly wasn't the case. The source for Plan9 is pretty plainly not hierarchical OOP. Plus, the failure of Plan 9 was more an early 90s thing.
    - mcguire 8y ago
      And I suspect the budget never got near billions of dollars. Plan 9 was a research project.
  - 1024core 8y ago
    My guess would be Ada. "Billions of dollars" => Government/DoD is involved.
    - jonathanstrange 8y ago
      Highly unlikely. Ada has objected-oriented programming only since 1995 (in the form of tagged types). It's also extremely well-suited for very large teams and much harder to mess up projects in Ada than in many other languages.
    - sevensor 8y ago
      If ever a forum that could draw a comment from somebody involved, it's this one. I was hoping this was a well known catastrophe somebody could fill me in on, but it sounds like the failure wasn't widely reported. I did enjoy this article on Wikipedia: https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_... Unless a survivor of the project can chime in, I'm going indulge in a little idle speculation and agree that defense sounds like a good candidate for losing a billion dollars. Maybe not DoD itself, but a big contractor?
charlysl 8y ago
I have read CTM, the author's book. He did in fact dislike the word "paradigm" and prefered "computation model" instead. A model is a set of concepts. A concept is an orthogonal language feature, like closures, concurrency, explicit state (which he now calls named state), exceptions, etc. His approach is not so much that you should select one language that supports a paradigm that seems the most suitable for a given project. Rather, what he advocates is that you should use a language that supports multiple cleanly separated concepts (close to what is called multiparadigm), and then you select the simplest set of concepts for each program component. This is the principle of least expresiveness, you should choose the simplest model (simple meaning that it is easy to reason about and to get right) that keeps the code natural (meaning there is little code unrelated to the problem at hand, little plumbing). Each model has an associated set of programming techniques, like accumulators for FP or transactions for stateful concurrency. It is possible to mix and match components that are written in different models by using impedance matching, which consists of creating an abstraction in the more expressive model that wraps the other component. An example would be a serializer, which allows you to plug a non concurrent component in concurrent program. Basically, you should use FP as much as you can, but you can't if your program needs, say, visible non-determinism, like a server in a client-server application. But then you can add just one concept, ports, to the declarative concurrent model, and you have a new model that allows a whole constellation of new programming techniques, the concurrent message passing model, Erlang-like. The non-determinism in this model is restricted to the ports, the only place where it's required, the rest of the program can still be functional. Other situations where FP might get stretched are when modularity or performance are a priority. This book helped me realize the whole FP vs OO debate is sterile, the ideal is to have a language that allows you to use FP in a natural way, and switch to, say, OO, in a natural way in some cases.
- billfruit 8y ago
  CTM has a wonderful premise; and unlike SICP, it does not aim to be freshman text book, and hence can jump headlong into the depth of the matter. Though I could'nt progress after a while, when they started to use a difference-list method, to achieve a semblance of stateful behaviour while using a declarative model. I couldn't understand that till until I later studied some Prolog.
doanguyen 8y ago
With this kind of articles, I just want to thank HN and all of these useful discussions. It's always enlightening moments while reading you guys comments.
- tabtab 8y ago
  Re: "always enlightening moments [reading your] comments." Not always: I'm a jerk 22.7% of the time.
  - jplayer01 8y ago
    It's possible to be a jerk and enlightening at the same time. As easy as it is to forget in today's culture of "everybody's a victim" and "feelings over every other concern", a good argument doesn't suddenly become invalid just because the author is rude.
    - tabtab 8y ago
      I'd be interested in specific examples to learn from. I'm always striving to make myself a more useful and enlightened jerk. I've already upgraded from a__hole.
  - doanguyen 8y ago
    I'm curious where's 22.7% comes from?
    - tabtab 8y ago
      I'm not telling you because today I happen to be a jerk.
Const-me 8y ago
Didn't like it much. > object-oriented programming is best for problems with a large number of related data abstractions organized in a hierarchy In OO books, maybe. In practice, OO is the way to compose very large systems out of big components. For hierarchies of data abstractions, very often OO is far from best. > Popular mainstream languages such as Java or C++ support just one or two separate paradigms. They support most of them, esp. modern C++, and C#. E.g. quite recently I was programming C++ in monotonic data flow paradigm, because MS media foundation.
- tabtab 8y ago
  I generally agree about OO. It's good for small-to-medium-sized abstractions, but scales poorly compared to say an RDBMS. When your OO diagrams start to look like ER diagrams, you are probably outside of OO's comfort zone. For large domain models, an RDBMS is superior to OOP in my opinion. OO is lousy at many-to-many relationships, for one, and lacks a visible identifier (primary key) to trouble-shoot data/state easily. OO may be helpful for modeling sub-sets of a domain model, but if you try to do the whole thing in an OO model, you'll either reinvent a database the hard way, turn grey, or do both.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
revskill 8y ago
If you can't do FP properly, most of your OOP codes are smell. Why ? At its root, OOP is born from FP.
mozareli 8y ago
I have been using programs from here.. for many years https://www.filehorse.com/software-developer-tools/ https://www.filehorse.com/software-developer-tools/ all the best!
dang 8y ago
Discussed in 2010: https://news.ycombinator.com/item?id=1118597 https://news.ycombinator.com/item?id=1118597.
pvanroy 8y ago
As the author, I must say I really enjoyed your detailed comments and Biblical exegesis on my paper. FYI, your guess on the big OOP failure is correct. Also, the Baskin Robbins footnote is a joke between myself and a physicist friend. The paper is a chapter in a book on computer music published by IRCAM that is worth reading too. Keep up the good work!

504 points by tiniuclx 8y ago

An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program. Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patterns redundant? Looking at Rust through this lens makes it clear that it aims to eliminate C-style manual memory management. However, it does make me wonder: How do languages such as JavaScript and Python stand out from their predecessors, and what problems do they uniquely solve?

jstimpfle 8y ago
> exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does only one thing at a time, and does any one thing only in one place (ideally).
- beaconstudios 8y ago
  compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.
  - jstimpfle 8y ago
    Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?
    - beaconstudios 8y ago
      > Look up the definition of "simple". There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. I would say exceptional is a situation that is rare and unexpected. When saving a record to a table with a unique constraint, I would expect the constraint to prevent saving but I would not usually attempt to handle/recover the app running out of memory. So it's situational and I'd say the distinction is between whether you will be explicitly handling the event as part of normal behaviour. The more stable the app needs to be, the more situations need to be handled.
      - jstimpfle 8y ago
        I agree and I think the conclusion is that it's up to the caller to decide what is exceptional. But unfortunately it's the callee who decides how the result is returned. And it's not only the caller, but also the caller of the caller, and so on, who needs to be prepared for exceptions. This all has severe ramifications on the code structure. > There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise. Sorry. I need to control myself. It's not about you. As another commenter stated there is an agreed upon distinction between simple and easy. The distinction is important especially among programmers, and what you described might be easy but it's not simple.
        beaconstudios 8y ago
        agreed, there are better ways to handle such circumstances (such as an Either/Validation monad). But I still think exceptions are better than error codes. If you don't handle an error code, you can proceed through your application in an invalid state. If you don't handle an exception, the application crashes out. I think the latter is preferable in most circumstances.
        jstimpfle 8y ago
        Yes, and this is the reason why I'm happy with exceptions for short scripts, e.g. Python. It's a different story for larger projects where I make all the primitives by myself. There I start by explicitly aborting on cases that are not handled yet (no exceptions needed to do that), and then I gradually change the structure of the code to handle more and more "exceptional" cases.
  - kungtotte 8y ago
    Don't mix up simple and easy, they are orthogonal concepts. Exceptions are in no way simpler than C-style error codes, but in many cases they might be easier to work with.
    - beaconstudios 8y ago
      simple to use versus simple to understand. I was referring to the former.
  - woadwarrior01 8y ago
    Case in point: Python’s StopIteration exception, which is raised to indicate iterator exhaustion. A lot of efficiency can be gained by not invoking Python’s heavy exception handling machinery for this.
- tiniuclx 8y ago
  You do have a point, adding exceptions to C++ does impact the language in many ways. They must be used responsibly: being able to jump to a completely different point of the program at any time is dangerous. However, exceptions do simplify some situations, such as when an unrecoverable error happens at the bottom of a deep call stack. Exceptions make it simple to inform the user/system that an error has occurred without adding error checks to every function in the call stack. I believe this use-case justifies the feature, especially if you can tolerate the performance loss which might not even be that bad [0]. Having the compiler check error codes is one of the reasons I enjoy Haskell so much: the type system makes you handle failure (amongst other things). [0] http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf - Section 5.4.1.2 - the table approach to exception handling has no run-time cost during normal (non-exceptional) program flow.
  - jstimpfle 8y ago
    The efficiency problem need not be the exception handling in itself (I can't say a lot about that. There are various claims and it probably depends on the tradeoffs of the language implementation). The actual problem is the ramifications on the code structure. A deep call stack with a lot of implicit context is a problem in itself. Exceptions imply a temporal coupling from error occurrence to error handling. This is a subtle but severe problem. It might start out as a noticeable maintainability problem but it's likely to quickly become a performance problem as well...
    - uryga 8y ago
      > Exceptions imply a temporal coupling from error occurrence to error handling. Could you expand on this? I understood your statement as "Exceptions sort-of force you to handle an error the moment it occurs", but I'm having trouble seeing why this would be specific to exceptions and not the case with other error handling solutions. (I don't mean to sound like a big exception-defender – I prefer ML/Rust-style Result types)
      - gbear605 8y ago
AnimalMuppet 8y ago
I think it's also how you should pick languages for a project. What is the worst yak-shaving aspect of the code you're going to have to write for this particular project? What language will go the furthest toward making that yak shaving go away? Pick that language.
- pjmlp 8y ago
  I pick the languages based on the platform stack I have to use and not the other way around. Basically the first class languages on a given platform, or having official bindings for a specific set of libraries that must be used. My experience has proven it is the best path for lowest attrition. Every time I decided to do otherwise I repented later on.
pjc50 8y ago
The wikipedia summary of the JavaScript design rational is decent; it also kind of explains why it's so odd: > In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.[11] Before he could get started, Netscape Communications collaborated with Sun Microsystems to include in Netscape Navigator Sun's more static programming language Java, in order to compete with Microsoft for user adoption of Web technologies and platforms.[12] Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax, which excluded adopting other languages such as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against competing proposals, the company needed a prototype. Eich wrote one in 10 days, in May 1995. It had to look vaguely like Java (hence ALGOL-derived brace delimited blocks rather than Scheme-derived prefix S-expressions, and the confusing name), and it had to be implemented quickly (hence the lack of typechecker and other advanced features), and it was intended to be beginner-friendly (hence all the truthiness/falsiness stuff). Javascript only succeeds because it's the only scripting language supported by web browsers, and the brief attempt at getting VBScript into browsers was even worse.
- pier25 8y ago
  > and it had to be implemented quickly (hence the lack of typechecker and other advanced features) Since then there has been more than enough time to implement optional static types. In fact, the EcmaScript 4 proposal had those, before it was trashed in 2007 or so and the TC39 started EcmaScript 5 from scratch.
  - tabtab 8y ago
    JavaScript is fine for the job of hooking light-duty events to HTML, but people try to write entire GUI/graphics engines in it. It's the wrong tool for that job, just as you don't write an OS in TCL. The whole Web UI "standards" issue needs a big overhaul in my opinion, but Web UI's is probably off topic. (I've ranted about it in other topics.)
- quineoa 8y ago
  This seems like an extreme case of “assume your hack will be used in production for years to come.”

randcraw 8y ago

Relevant references... A 2004 textbook by the OP: Concepts, Techniques, and Models of Computer Programming https://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695 https://www.amazon.com/Concepts-Techniques-Models-Computer-P... And his 6 week edX course: Paradigms of Computer Programming – Fundamentals https://www.edx.org/course/paradigms-of-computer-programming-fundamentals https://www.edx.org/course/paradigms-of-computer-programming...

dahart 8y ago

The footnote in section 2.1 caught my eye: > Similar reasoning explains why Baskin-Robbins has exactly 31 flavors of ice cream. We postulate that they have only 5 flavors, which gives 25 − 1 = 31 combinations with at least one flavor. The 32nd combination is the empty flavor. The taste of the empty flavor is an open research question. I honestly can’t tell if this is a good joke or serious & bad logic. The 31 flavors are obviously not a mix of 5 base flavors. If that were the case, each base flavor would be in 16 of the mixed flavors, and you wouldn’t have any unique flavors at all, like mint or cookie dough. It’s just a coincidence that the longest months in the year are 2^5-1 days.

de_Selby 8y ago
>I honestly can’t tell if this is a good joke... I'll help out: It's a joke.
- dahart 8y ago
  For sure? I skimmed the whole thing and couldn’t immediately find any other jokes. Seems an odd choice to throw in one random deadpan comment about the coincidence of 31 being near a power of two.
  - mturmon 8y ago
    Definitely a joke. The "open research question" kicker makes that clear. There's a similar jokey footnote on page 33.
  - wellpast 8y ago
    > Seems an odd choice to throw in one random deadpan comment... But then again it gives the joke a special nonplussing hilarity that it wouldn’t acquire otherwise.
fjsolwmv 8y ago
Months are 31 days because each day is made up of 5 base elements that can present pr absent. The empty day is theorized to exist but impossible for humans to experience and report.

atilaneves 8y ago

"Popular mainstream languages such as Java or C++ support just one or two separate paradigms" Java, ok. But C++??? That language has everything and the kitchen sink, including pure functional programming (templates).

pjmlp 8y ago
Even Java, after lambdas and immutable data structures introduction it is quite debatable.
- rydel 8y ago
  Having lambda doesn’t mean to be FP. One of the core features missing in Java (JavaScript also) is TCO(tail call optimization)
  - dnautics 8y ago
    Julia is missing TCO and it is for sure functional.
  - pjmlp 8y ago
    First of all not all FP languages have TCO, Scheme is probably the only one that actually requires it on its language specification. Secondly stuff like LINQ was already available in Smalltalk. So all those map/filter/fold/.... constructs from lambda calculus, which Java now enjoys. Then if we apply the modern concept of only Haskell is FP, then there are a couple of FP languages that won't meet the classification. Ah, and Haskell does not require TCO on their language specification, so it isn't an FP language according to your arbitrary definition.
    - rydel 8y ago
      It depends. As we know, FP is all about not having side effects. Having “for” loop requires to mutate the pointer of given iteration.
      - 8y ago

iofiiiiiiiii 8y ago

What utter rubbish. This type of paper has no place in a professional environment.

AnimalMuppet 8y ago
Could you give some reasons for your statement? Why do you think it's rubbish?
- mcguire 8y ago
  He's got a point. 99.999% of programmers are never going to need to know this, and the time wasted reading it would better be spent inventioning a new JavaScript UI framework. /s.
- lbriner 8y ago
  Like many discussions, this seems to demonstrate that a Programmer != a Developer != an Engineer != an Architect. Of course, many programmers would never need this stuff and many have no formal qualifications but they still produce what they need to without problems. They certainly do not need to know about paradigms vs concepts vs models etc. even if it is interesting. Of course, there ARE people who need to know this stuff to do their job well but they are quite up the food chain compared to most of us. They might also be corporate, who of us sits down and thinks, shall I do this in OO or functional? Which paradigm fits? Most of us know few languages and use what we know.
  - macintux 8y ago
    You're saying uneducated programmers are more useful than educated ones? I don't understand your point.
    - AnimalMuppet 8y ago
      I believe that lbriner is saying that uneducated programmers are still useful - not more useful, just useful.
8y ago

sevensor 8y ago

> We end our discussion of inheritance with a cautionary tale. In the 1980s, a very large multinational company initiated an ambitious project based on object-oriented programming. Despite a budget of several billion dollars, the project failed miserably. One of the principal reasons for this failure was a wrong use of inheritance. Who did that, exactly?

ummonk 8y ago
I would have guessed Plan 9 just from the timing, but I'm not sure the failure there was due to the wrong use of inheritance.
- angersock 8y ago
  That most certainly wasn't the case. The source for Plan9 is pretty plainly not hierarchical OOP. Plus, the failure of Plan 9 was more an early 90s thing.
  - mcguire 8y ago
    And I suspect the budget never got near billions of dollars. Plan 9 was a research project.
- 1024core 8y ago
  My guess would be Ada. "Billions of dollars" => Government/DoD is involved.
  - jonathanstrange 8y ago
    Highly unlikely. Ada has objected-oriented programming only since 1995 (in the form of tagged types). It's also extremely well-suited for very large teams and much harder to mess up projects in Ada than in many other languages.
  - sevensor 8y ago
    If ever a forum that could draw a comment from somebody involved, it's this one. I was hoping this was a well known catastrophe somebody could fill me in on, but it sounds like the failure wasn't widely reported. I did enjoy this article on Wikipedia: https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_... Unless a survivor of the project can chime in, I'm going indulge in a little idle speculation and agree that defense sounds like a good candidate for losing a billion dollars. Maybe not DoD itself, but a big contractor?

charlysl 8y ago

I have read CTM, the author's book. He did in fact dislike the word "paradigm" and prefered "computation model" instead. A model is a set of concepts. A concept is an orthogonal language feature, like closures, concurrency, explicit state (which he now calls named state), exceptions, etc. His approach is not so much that you should select one language that supports a paradigm that seems the most suitable for a given project. Rather, what he advocates is that you should use a language that supports multiple cleanly separated concepts (close to what is called multiparadigm), and then you select the simplest set of concepts for each program component. This is the principle of least expresiveness, you should choose the simplest model (simple meaning that it is easy to reason about and to get right) that keeps the code natural (meaning there is little code unrelated to the problem at hand, little plumbing). Each model has an associated set of programming techniques, like accumulators for FP or transactions for stateful concurrency. It is possible to mix and match components that are written in different models by using impedance matching, which consists of creating an abstraction in the more expressive model that wraps the other component. An example would be a serializer, which allows you to plug a non concurrent component in concurrent program. Basically, you should use FP as much as you can, but you can't if your program needs, say, visible non-determinism, like a server in a client-server application. But then you can add just one concept, ports, to the declarative concurrent model, and you have a new model that allows a whole constellation of new programming techniques, the concurrent message passing model, Erlang-like. The non-determinism in this model is restricted to the ports, the only place where it's required, the rest of the program can still be functional. Other situations where FP might get stretched are when modularity or performance are a priority. This book helped me realize the whole FP vs OO debate is sterile, the ideal is to have a language that allows you to use FP in a natural way, and switch to, say, OO, in a natural way in some cases.

billfruit 8y ago
CTM has a wonderful premise; and unlike SICP, it does not aim to be freshman text book, and hence can jump headlong into the depth of the matter. Though I could'nt progress after a while, when they started to use a difference-list method, to achieve a semblance of stateful behaviour while using a declarative model. I couldn't understand that till until I later studied some Prolog.

doanguyen 8y ago

With this kind of articles, I just want to thank HN and all of these useful discussions. It's always enlightening moments while reading you guys comments.

tabtab 8y ago
Re: "always enlightening moments [reading your] comments." Not always: I'm a jerk 22.7% of the time.
- jplayer01 8y ago
  It's possible to be a jerk and enlightening at the same time. As easy as it is to forget in today's culture of "everybody's a victim" and "feelings over every other concern", a good argument doesn't suddenly become invalid just because the author is rude.
  - tabtab 8y ago
    I'd be interested in specific examples to learn from. I'm always striving to make myself a more useful and enlightened jerk. I've already upgraded from a__hole.
- doanguyen 8y ago
  I'm curious where's 22.7% comes from?
  - tabtab 8y ago
    I'm not telling you because today I happen to be a jerk.

Const-me 8y ago

Didn't like it much. > object-oriented programming is best for problems with a large number of related data abstractions organized in a hierarchy In OO books, maybe. In practice, OO is the way to compose very large systems out of big components. For hierarchies of data abstractions, very often OO is far from best. > Popular mainstream languages such as Java or C++ support just one or two separate paradigms. They support most of them, esp. modern C++, and C#. E.g. quite recently I was programming C++ in monotonic data flow paradigm, because MS media foundation.

tabtab 8y ago
I generally agree about OO. It's good for small-to-medium-sized abstractions, but scales poorly compared to say an RDBMS. When your OO diagrams start to look like ER diagrams, you are probably outside of OO's comfort zone. For large domain models, an RDBMS is superior to OOP in my opinion. OO is lousy at many-to-many relationships, for one, and lacks a visible identifier (primary key) to trouble-shoot data/state easily. OO may be helpful for modeling sub-sets of a domain model, but if you try to do the whole thing in an OO model, you'll either reinvent a database the hard way, turn grey, or do both.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

revskill 8y ago

If you can't do FP properly, most of your OOP codes are smell. Why ? At its root, OOP is born from FP.

mozareli 8y ago

I have been using programs from here.. for many years https://www.filehorse.com/software-developer-tools/ https://www.filehorse.com/software-developer-tools/ all the best!

dang 8y ago

Discussed in 2010: https://news.ycombinator.com/item?id=1118597 https://news.ycombinator.com/item?id=1118597.

pvanroy 8y ago

As the author, I must say I really enjoyed your detailed comments and Biblical exegesis on my paper. FYI, your guess on the big OOP failure is correct. Also, the Baskin Robbins footnote is a joke between myself and a physicist friend. The paper is a chapter in a book on computer music published by IRCAM that is worth reading too. Keep up the good work!