techadv

This is probably a cognitive bias obtained from reading the industry trade press.

There's a notable alternative -- you don't have a meteoric rise to giant status, but you also don't collapse. These sorts of "happy medium" companies are in the vast majority even in our industry, but they're less likely to end up on the front page of a news feed, esp. those biased toward the fast growth (startup) community.

Also, you forgot the last stage. After becoming super rich, the CEO gets inspired by something other than heading up a vilified corporation, then goes off and founds a foundation that does great humanitarian work. Now that the company is not on top and the founder is doing exclusively good stuff for humanity, no one hates either anymore :-)

edit: fixed pronouns and adjectives because it pointed ambiguously in the sentence.

Great, thanks! Your example makes a lot more sense now.

The easy way out is to say that these languages are OO in the same sense that Java is functional. Easy but maybe not unfair, particularly since all are dynamically typed.

The clojure examples make this look like OO. I would have to find a formal definition of the semantics to figure out if there's a more nuanced explanation than the easy one above.

And yes, I think I agree with the last bit. The author's observation that lines can become blurred is certainly valuable and true. It's the author's conclusion that the term OOP is therefore meaningless which is, imo, empirically false.

edit: stray punctuation

The author's case is based upon Harriman's account of induction in the natural sciences. I don't think that's appropriate here. Computer Science -- or at least PL/Software Engineering -- is not a physical science! In many cases it's not or historically wasn't even a mathematical science.

Furthermore, all programming paradigms suffer the same fate in popular/industry press (even if not within academic communities). For instance, productivity claims justified by the macros and dynamic typing of Schemes and Lisps are often implicitly cross-applied to MLs under the broad header of "FP". And vice-versa for safety claims about MLs germane to types.

Sure, some people are careful about this sort of thing. But some aren't, which can make the concept of FP a "grab-bag" in certain settings. That doesn't (or shouldn't) make FP a "non-concept".

(It appears you beat me to this punch, so I'm moving my comment here instead of fragmenting this point into 2 top-level comments.)

I have no idea how defining the type of a function's domain is supposed to be indicative to dynamic dispatch or associated methods with classes. I think I don't understand your example :-( Perhaps you can elaborate, since I don't know much about either of these languages.

Regarding existential types: yes, there's an intimate relationship between existential quantification and OOP. But you can distinguish the difference between OO languages and (non-OO languages with existential types) in the type theory. That's what's important. I think the raw empirical nature of my academic community consensus test is far preferable to the author's epistemological argument.

The question is whether OOP has meaning. I think if the PL community can be empirically demonstrated to have enough consensus that languages are reliably categorized as OO or non-OO, then we can safely say the term has meaning regardless of any armchair philosophy to the contrary.

Edit: And I think (hope) the author of the article would agree my test is sufficient. He states: When I say that there’s no such thing as OO, I mean, more precisely, that there exists some abstraction (or several) that is referred to as “object-oriented”, but that this abstraction has no actual referent in reality. It is an abstraction that is made in error. It is not necessary, and serves no cognitive purpose. It is “not even false”..

If OO has enough meaning to an important subgroup of people that they can use it with more-or-less consensus, then the claim that it has no referent in reality is clearly empirically denied, at least for that subgroup. And if that subgroup happens to be a large chunk of the PL community, then I think that's an important enough subgroup to settle the larger question.

The article author was referring to inductive reasoning in the sense of epistemology, which is not the same as mathematical induction. In fact, mathematical induction is a deductive reasoning technique.

Here's the relevant wiki article: http://en.wikipedia.org/wiki/Inductive_reasoning

The page you link seems to indicate that Kay didn't propose this as a definitive definition of OOP, but rather as a description of the defining features of Smalltalk. I'm not familiar with the document; do you have any insight?

The mainstream programming language community has a pretty strong consensus on what OOP means, in terms of language features.

Some people out there seem to have some confused notions of what OOP is. That doesn't mean there isn't a well-understood and more-or-less accepted definition, at least in academia.

Edit for downvotes: dynamic dispatch + associating methods with classes, often times but not necessarily accompanied by an inheritance hierarchy. Of course there's lot of room for design decisions (and prototype-based languages are only awkwardly encapsulated in that group), but these features are basically unique to OOP languages.

The point is that you could put a language with these features in front of any random sample of PL researchers and they would probably more-or-less agree on whether the language has OO features. That's more or less the definition of scientific consensus.

I think your post mostly re-enforces the OP's claim that FP won't save the day. To quote the OP, "it is obvious to me that doing FP right is (and will be) very hard."

In-so-far as your claims are true and germane to FP, they merely re-enforce this critique. After all, doing math right is very hard.

and we have no sound way of modeling imperative languages/programs in ways that makes them useful as mathematical concepts.

This simply isn't true. There exist sound logics of imperative programs, which can be used to explore mathematical concepts.

This also pre-supposes that imperative programs themselves (and machine models more generally) are not an interesting mathematical concept.

FP is math

It's entirely unclear what this means, if anything. You probably mean to say that certain functional languages correspond to certain logics. But that's not terribly meaningful; you can establish similar correspondences with imperative languages.

And even then, logic is math does not imply that math is (just) logic. So even if you're granted this point, the rest of your argument doesn't follow.

From a more empirical perspective, plenty of mathematicians do great math without knowing anything about FP, and plenty of FP programmers write a ton of code without ever doing interesting math.

Finally, the vast majority of very mathematically informed programming is still done in languages like C and Python and Java. So I'm highly suspicious of the claim that we need programming languages which are close to foundations in order to do mathematically informed programming.

Related is Dijkstra's "on the fact that the ocean has two sides": https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

I serve on a tech advisory committee for a local school district. I am unforgiving on a single point: students need access to a development environment -- or at least the ability to install software -- or else these computers are just consumables.

I've suggested numerous setups to get around all of the excuses tech people at the district give. Would you mind sharing personal contact info for either yourself or your IT staff so that I can go to administration with a "this works in practice, here, go see" argument?