Live data from Hacker News

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

info.ucl.ac.be

81–90 of 167 posts

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

#81

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…

The problem with "choose the best paradigm/computational-model for the job" is that mastering each of the possibilities takes a lot of time for the average programmer. It may be better to master a few than spend so much extra time mastering them all.

I have accused some academics of "promoting ideas that require more education" so as to line their wallet. It didn't go over well and I got counter-accused of "promoting mediocrity" so that "my type" don't have to learn. (I don't believe such bias is intentional, just human nature. We are all biased in ways we don't know just by the fact we only live one life.)

Rather than delve back into that bitter debate, I ask that people consider the economics of it: is it better on a macro-economic scale to spend extra education to master many paradigms/techniques, or to settle on a few to get through school/training faster? (There's always going to be niches that need specialized training/skills.)

The average programming career is relatively short-lived: you either have to move into management, analysis, project planning, etc. or be subject to agism. For good or bad, the industry doesn't "like" old programmers. RSI (wrist problems) is also common with seasoned programmers. Thus, I believe the shorter-education approach is the economically logical one. You are welcome to disagree.

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

#82

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 supp…

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.

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

#83

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.

Re: "always enlightening moments [reading your] comments."

Not always: I'm a jerk 22.7% of the time.

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

#84
post #53

Earlier quoted context omitted.

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.

My guess would be Ada. "Billions of dollars" => Government/DoD is involved.

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.

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

#85
post #74
post #32

Earlier quoted context omitted.

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 J…

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

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

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

#87
post #39
post #33

Earlier quoted context omitted.

Even Java, after lambdas and immutable data structures introduction it is quite debatable.

Having lambda doesn’t mean to be FP. One of the core features missing in Java (JavaScript also) is TCO(tail call optimization)

Tail call optimization is more or less unimportant, because you can express any recursion with iteration and most of the time the explicitly iterative version is even safer and better. TCO only adds zero-cost for recursions based on tail calls, that's nice to have but recursion is a bit of a hobby-horse of CS professors anyway. It only makes sense in languages that have their own stack, i.e., have no hard stack limit except for your main memory, otherwise you will run out of stack space soon. Iterative versions of functions are often easier to understand, too.

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

#89
post #22

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…

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.

I thought that was funny, I'm bummed it got downvoted. I tried imagining what a base element of time is. This is like some kind of complex or imaginary unit time quaternion or something.

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

#90

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

You realize that the book it's excerpted from is considered one of the more important computer science texts? You're going to have to offer a great deal more useful critique than "utter rubbish" to gain any meaningful agreement here.

Actually, the chapter is based on CTM, but seems to be from a more recent work.

"This chapter is partly based on the book [50], familiarly known as CTM, which gives much more information on many of the paradigms and concepts presented here. But this chapter goes further and presents ideas and paradigms not covered in CTM."

I poked around a bit on Van Roy's website, but couldn't find the source. It would be interesting to know what it is.

Post reply on HN