Comment by mpweiher | Hacker News Reader

Comment by mpweiher | Hacker News Reader

Parent Full thread

Same for OOP, example from 1988:

"Building a backtracking facility in smalltalk without kernel support"[1]

Languages like Snobol, Prolog, and Icon were designed with backtracking facilities from the outset and these facilities are deeply intertwined with the implementation. Retrofitting a backtracking facility in a language that wasn't designed for it has never been achieved. We report on an experiment to retrofit Smalltalk with a backtracking facility. The facility is provided through a small number of primitives written in the language (no modifications to the kernel were made). The ability to do this is a direct result of the power provided by the objectification of contexts.

There's tons of other examples, for example various distributed objects mechanisms, my own Higher Order Messaging [2] the way Gemstone creates queries from procedural selection code etc.

[1] https://dl.acm.org/citation.cfm?doid=62084.62094

[2] https://en.wikipedia.org/wiki/Higher_order_message

The trouble with OOP is that objects you can send messages to are already too complex to reason about. You can't send the same message twice and expect to get the same reply (or even, in some implementations, get a reply at all). So the fact that you can implement anything with objects isn't that surprising, because saying something is an object doesn't really constrain what it can do - you might as well say you can implement anything with a "thing", which is true but useless. Functions - or rather, constructive, well-typed functions - occupy a nice sweet spot where they're constrained enough to reason about, but powerful enough to do what you need.

https://tahoe-lafs.org/~davidsarah/noether-friam4.pdf has a more concrete set of tradeoffs: starting from a small, highly symmetric core, you add more capabilities to the language but you break a symmetry each time. One of the levels in the rainbow is an OOP language, but that requires breaking enough symmetries that I wouldn't want to work in it if I could avoid it.

Yep. Java’s strawman implementation of OOP lead most of the world to never learn OOP’s potential. In Smalltalk, if was a virtual method of Boolean! Sounds horrible for performance, eh? Despite that, the Strongtalk spin off of Smalltalk was used as the internals of Java’s Hotspot JIT.

From The Evolution of the Smalltalk Virtual Machine (Dan Ingalls, in Smalltalk-80, Bits of History, Words of Advice, Krasner):

"Smalltalk-76 had to provide a mechanism for passing unevaluated code. [Blocks/Closures] Since the Smalltalk-76 design had no experience to draw from, it was weak in several areas.[..]

One Problem which was discovered in the process of of supporting error recovery was that block contexts could not be restarted because they did not include their initial PC as part of their state. This was normally needed for looping , since all such code fragments ended with a branch back to the beginning. Happily, we were able to fix this by defining a new subclass."

So they were able to fix a bug in the language implementation by writing code in the language itself!

Java is fine

Totally agree. Most problems with Java are cultural.

It seems the more experince people get with large team efforts the more they value Java and other well supported type safe languages.

I'm a perfect example myself as a person who used to think that a number of other languages would be better but after having to maintain my own (yep, not only someone elses bad code, but also my own precious code) in a number of languages I've come to really prefer Java.

Can you point to some resources that teach Java "the right way"? Without the cultural baggage? I need to learn it for a new job and I'm inundated with resources that I can't determine the quality of.

JVM dev here... unfortunately there aren't any great holistic books for modern Java that I can think of. A lot of it is just community learned (e.g. put the XML away, stop making everything a damn GoF design pattern, stop trying to create mega class hierarchies, favor small libraries over mega frameworks).

I will say Joshua Bloch's Effective Java is something ever Java dev should have read at some point.

It's extremely frustrating that whenever anyone talks about even the slightest positive mention of FP, this site tends to immediately have 2-3 folks pop out of nowhere demanding that everyone recognize OO exists.

Yes. Yes. We know. You can write programs with OO. It's the dominant paradigm of the software industry. No one here saidthat OO is somehow ineffective, cannot abstract, or lacks cleverness.

Please for even comment section just put down the sword and let other folks with equally interesting approaches talk about their work.

I feel like the HN bias tends to go the other way, that FP is some kind of awesome magic sauce and OOP is the bane of good software. In reality, most of the techniques we discuss don’t really depend on a specific language orientation.

You can probably prove this one way or another.

A good number of the posters here are fans of Paul Graham who is a loud FP advocate.

Also I've been here for a number of years and I can never recall seeing anyone bashing FP. (Which is totally fine with me.)

Bashing Java and and general OO however is to be expected in any programming related thread here (a little tiring but understandable, I too have seen my share of bad OO code.)

Neither of this counts as proof but yes, this site comes off as extremely pro FP for me as well.

Paul Graham is not a fan of FP, he's a Lisp advocate. Every Lisper will be quick to tell you their approach is a superset of FP with its own unique meta-syntactic tools.

This is a great illustration of my point. If you place every differing viewpoint in one bucket and then take the sum, yeah it's gonna see overwhelming. In actuality, there are lots of factions with interesting viewpoints.

> I can never recall seeing anyone bashing FP

Well I'm guilty of that, even on this page ;-)

What's the problem? Nobody said anything bad about FP at all.

I'm not sure that's the case here.

How so?

mpweiher's post that you replied to only mentions Smalltalk, Snobol, Prolog, and Icon, neither of which are FP languages AFAIK.

Furthermore IIRC the post only defends OO languages. I cannot read it in any way as an attack on FP languages and I've tried multiple times now.

"Defends" it from what, exactly?

There is no sense in which OO of the add-backtracking-to-smalltalk variety is the dominant paradigm.

That's like saying functional programming is the dominant paradigm, because Javascript has functions.

Pointing to prior art is a good and useful thing for a comment to do.

Literally every OO programmer is on the hook for knowing a huge array of smalltalk-derived patterns. MANY programmers use languages with significant inheritance from Smalltalk.

Common Lisp also isn't coming back despite having some amazing features. Let's both dry our tears and move on.

This is a weird argument.

Mentioning something great that smalltalk is capable of isn't the same as saying everyone should use smalltalk. It's more saying - let's not forget some of the great stuff that existed in the past that the current crop of popular languages don't have.

But no one's going to forget. Every time I mention FP, I have to be on guard for some OO stan showing up demanding that I acknowledge and "not forget" that OO has in fact "done things".

Even this example where someone says something totally unrealted to OO, someone felt compelled to leap in and say something as unrelated as, "OO too! Here's a barely related OO project I found to be clever! Please don't forget about us."

Let me just remind you how this went:

Person A:

> The essence of FP is that if you apply a bit of cleverness and engineering, you can replace things that look like they would need custom language features

Person B: > Same for OOP, example from 1988:

No one even implied that this was exclusive! But certainly other folks have used the word "defense" for that post, perhaps not even realizing it. As if the existence of other paradigms somehow threatens the importance of OO.

Maybe it's because every time people talk about FP, someone has to dredge up an OO (read: enterprise Java) strawman showing all of its alleged deficiencies?

No one did that here. There was no mention of OO. There was an allusion to how typed FP relies on extremely generic programming, which is a notable difference from many other programming approaches.

> which is a notable difference from many other programming approaches

Except that it isn't "a notable difference", more precisely (quoting the original):

"replace things that look like they would need custom language features, like multiple return or async, with libraries"

Replacing "things that look like they would need custom language features" with libraries is exactly the essence of Smalltalk.

"Talk small and carry a big class library"

It's even in the Design Principles Behind Smalltalk:

"A language must provide a means for classifying similar objects, and for adding new classes of objects on equal footing with the kernel classes of the system."

So either there is a claim that "hey this is a cool way of doing things", in which case "yeah, I agree, this other thing does that as well" is completely benign.

Or there is the claim "here is uniquely FP way of doing things", in which case the example of OO is a refutation.

Either way the response is appropriate.

Reply on news.ycombinator.com