Hacker News Reader

Comment by clusterhacks | Hacker News Reader

A fun essay that really tries to nail down the "Why" in a real-world way.

It mentions that functional programming removes the tripwire of state mutation as one of the "whys", but my experience slightly differs here.

I found, after years of struggling with the "why" of object-oriented programming and its early obsessions with design patterns, that functional programming simply resonated with me personally. To this day, I have a bit of inner cringe when reading (for example) Java code.

Early in my career, I thought my lack of "getting OOP" was due to some profound missing piece of understanding. But then Lisp (and Clojure) just made sense. Thinking functionally just works for me. It's not so much that I couldn't use OOP but just that each time I worked in deeper OOP projects, I felt some internal friction or vague uneasiness with the code.

I did find that functional programming made me significantly more comfortable with OOP languages. YMMV.

View on HN

Which is funny, because OOP should be[1] about the in-between of the objects: the messages[2]. Not about the objects themselves or the classes and GOF design patterns.

With Common Lisp you get generic functions and design your classes around those.

[1] “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.” - Alan Kay (http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...)

[2] “The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.” - Alan Kay (https://wiki.c2.com/?AlanKayOnMessaging)

We should stop invoking Alan Kay's ancient opinion in OOP discussions. I suggest we rebrand his flavour of programming as "message oriented programming" (MOP), thank it for its continuing contributions to the field, and recognize that contemporary OOP is a valid but different solution space.

Clarity is certainly important, in which case I could have said “OOP should have been...”

Except: Smalltalk still lives (Squeak) and Erlang takes messaging to the extreme.

I've not used Erlang much, really, but it seems like a really nice fusion of messaging across agents and immutable state within agents. Elixir has long been on my list of languages to properly pick up...

Rather, we should insist on calling object oriented programming what it is, and come up with an acronym for the poor imitations.

How about Class-Reified Abstract Programming? If the shoe fits...

In this era, DeepClass is a kool name.

Too much mutation leads to deep state.

Modern OOP isn't a poor imitation of anything, it's a distinct approach with its own merits. The No True OOP meme is old and tired, and frankly pointless.

Agreed. Smalltalk is Smalltalk and corporate OOP(Java/C#) is what it is. Neither is superior or more pure.

It’s imperative programming with dots/infix sigils and either a little or a lot of ceremony.

Smalltalk came after Simula, which created the "poor imitation" you refer to. The reason you remember Kay instead of Simula is because Simula's ideas actually worked and so instantly got adopted by too many languages to care where it came from.

Also since Simula proceeded Smalltalk, and C++ is inspired by Simula, and Java by C++.

I always take a point to address the "Java coding in C++", as what actually happened was Java adopting what was the C++ approach to library development before Oak turned into Java.

That's funny but for me Erlang is much more MOP than Smalltalk

Sure. Reading the qualifications that Kay makes at the end of his quote (above), he leaves room for Erlang to be MOP. I suspect that he just wasn't familiar with the language.

The lecture about GOF design patterns were the first OOP lecture in university where I actually felt I learned something useful.

That's somewhat tragic.

It's probably even more humorous if you understand that Scheme was created because Gerald Jay Sussman and Guy Steele wanted a way to experiment with Carl Hewitt's actor model, which is based on message passing. Which, itself, was based on Simula, Smalltalk, etc.

Sussman and Steele came up with a way to do lexical scoping in a LISP, thus closures in LISP were born. They then acknowledged that actors and closures are essentially the same concept (I'm assuming with mutation, i.e. Scheme's "set!" and friends because otherwise message passing to update independent actors would be meaningless).

And to put the cherry on the top, what do Java, Common Lisp, and Scheme all have in common? Guy L. Steele worked on the language specs of all of those. Which makes the dig against Java a bit hilarious, though understandable.

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

> [...] And by such examples one may be led into the functional style of programming, which is possible within Lisp/Scheme, though not required.

Wasn't it specifically garbage collection that he contributed?

nope. GC is thanks to John McCarthy, himself, when he invented LISP around 1959.

"actors and closure are the same concept":

Do you have a good article explaining this ? To me actors is mainly a pattern for dealing with concurrency, and closures seem completely unrelated. But i assume i'm missing something...

The Actor model is interesting because it wasn't originally a model for concurrency. It expresses concurrency semantics naturally, which is why it's been used that way. But, believe it or not, originally it was a mathematical theory of computing comparable to the Lambda Calculus.

If you'd like to explore this space look up the original papers by Carl Hewitt. He's also written some more recent papers on the subject. Also the "Lambda Papers" by Sussman and Steele are instructive. They deal with implementing various control structures and computational patterns with lambdas. Unfortunately there isn't a "Lambda the Ultimate Object" which could be written. I'm guessing they didn't go there because at the time OOP hadn't taken off and may have seemed obvious to the people who where involved in Lisp/OOP at the time.

In his essay "Objects Have not Failed" Guy Steele addresses the history that deckard1 mentions.

[1] "Viewing Control Structures as Patterns of Passing Messages" - Carl Hewitt

[2] "Actor Model of Computation: Scalable Robust Information Systems" - Carl Hewitt

[3] The Lambda Papers - https://research.scheme.org/lambda-papers/

[4] "Objects Have Not Failed" - Guy Steele, https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html

Common Lisp also gets you the Common Lisp Object System.

I'm pretty similar.

People like to ask "why should I use <insert language>?" I never really think about it too much - I don't pull out my weights and measures, and say "well, language X is 83.72% optimal for the problem, but language Y is 91.22% optimal, obviously using language X is a huge mistake!"

If something is obviously better for a problem, I'll pick that language. But if you have to dig too deeply into what language to use, the language probably doesn't actually matter that much.

I was "raised" on OOP, and I "got" it, but I've always preferred more standard procedural programming. I prefer Go over Java, and C over C++.

I like FP more than procedural programming. I prefer Elixir and Haskell over Go.

I like Lispy languages more than other languages. I prefer Clojure over Elixir and Haskell.

Don't stop there.

I thought racket was the holy grail due to the macro system but my real metamorphosis came after learning Haskell. I realize now that my previous preference for Clojure was because I was stuck in prototyping mode.

Once you truly understand your problem domain then types trump macros.

So while I owe a huge debt to Clojure/Racket for rescuing me from my java nightmare, and introducing me to other approaches like Erlang, it was Haskell/Purescript that matured me the most as a programmer.

It was so worth the (considerable) effort, because it has generalized the very nature of computation in a way that just never happened for me in all my years with lisp.

“Types trump macros” is a nice way to put it. Macros are amazing for creating new languages, but a good type system with strong case matching and sum types is just incredible to work with.

I was in the process of creating my own language in racket. It was going to codify everything I had learned over the years into powerful abstractions and target JavaScript.

Halfway though I realized I was inventing a shittier Purescript.

Dsls are mostly masturbation. Custom syntax? Custom evaluation semantics? I always regret it after like cocaine.

The only thing macros are reasonable for is custom bindings.

Most people are not qualified to invent dsls. Myself included. And the people who are qualified don't need "language oriented programming" ala racket. They can spin up a lexer which is the least complicated part of the task anyway.

As for types, they have a HUGE power to weight ratio. All of my efficiency gains in Clojure due to macros were forfeited 10x over hunting down null pointer exceptions at runtime.

I still love Racket. And I still prototype in Clojure. But Haskell brings you closer to math. Closer to category theory.

Most programmers don't need new symbols and semantics. They need a deeper understanding of combinatorial logic.

Racket DSLs aren't the same as 'spinning up a new lexer' at all. Making DSLs is hard, and being a PLT expert does not make one an expert at language implementation. Those are completely different skills (see Brady's reimplementation of Idris on Chez Scheme and the reason for it).

Racket allows people with new ideas to prototype them efficiently by easily implementing a compiler that would've been an interpreter otherwise.

In my experience most dsls are not of the quality of Typed Racket or Scribble. And many of the good languages designed in Racket could be just as well designed if they targeted LLVM. And for 99% of the programmers I've hired they'd be better spending their time further understanding the existing abstractions and research in the many great languages that already exist rather than halfbaking their own because it's so easy and tempting.

As I said, I like Racket. And I agree with you it's a nice environment for playing with new language ideas. But most of those ideas are bad and are just incidental complexity. And the 1 of 100 languages that are great ideas and needed by the world are better off spun out with their own parser and toolchain without being so tied to Dr Racket and Chez Scheme.

> hunting down null pointer exceptions at runtime

That seems mostly a fault of the JVM, no?

Well both. Also in Clojurescript.

Clojure's nil punning and Java's Null Pointers are an unholy alliance here.

But a type system like Elm solves the problem before it ever gets to JavaScript for example.

Types also complect, as Rich Hickey points out. Data is just data. When you constrain it with types you lose something. Witness the pain of making JSON fit the type system in a lot of statically typed languages.

In my experience it's the exact opposite. Good design is precisely about constraints.

A good type system like Haskell's gains you much more than it costs. Sure Json and Clojure are open and flexible, but this is not what you want when you understand your problem and can specify the types are Ohms -> Volts -> Amps etc, instead of just Number Number Number.

Specifying them after in spec or typed racket was just not the same and always rang similiar to unit tests after the fact.

Haskell types is like having a pair programmer sitting beside me. For systems that I have in production that have been ported from Clojure to Purescript the reduction in bugs, refactorability and overall confidence is something I didn't know I was missing until I did.

I understand Hickey's point in his Maybe Not talk, either you have the data or you don't. But at the end of the day, Clojurescript apps subject my users to blank screens and subtle "undefined is not a function" bugs, whereas the Purescript compiler forces ME to diligently deal with those unexpected possible scenarios before I ever ship.

> Witness the pain of making JSON fit the type system in a lot of statically typed languages.

In something like Java, sure. But Java is to static types as BASIC is to structured programming: the execution is so primitive that reasonable people can be misled into rejecting the concept if that's all they know.

Here's a completely painless encoding of JSON in Haskell:

That friction and vague uneasiness for me is as the nagging thought that it's simply not correct code. In my case I prefer to write as much SQL as reasonably possible to prevent having to write any code in an imperative language.

I’m very much in this camp as well. A significant number of applications can be expressed with sql and a thin layer around it

Interesting. You mean make all the queries as detailed and specific as possible, processing things as much as possible in SQL so you don't have to mess around with the data you get from/put in the DB in an imperative langauge?

Do you have any good examples of this? Code bases that can be read?

Messing with data significantly outside of SQL is often asking for trouble.

SQL queries are compiled into very efficient operations which would take a lot longer to get right imperatively. Not only that, but database engines are improving all the time, so the same code you wrote which declares your desired transformations tends to get faster over time and there is nothing to update or refactor. The transformations you write are sort of timeless because they are strongly decoupled from the implementation and hardware.

Lots of data transformation steps in imperative languages require the persistence of an intermediate calculation (e.g., np.ndarray). SQL database only do this when the query planner deems it absolutely necessary. It will show up in your query plan as a "materialize" step.

The EXPLAIN feature of SQL is the most useful performance debugging tool. It also alerts me to a potential logic flaw quickly when the proposed plan looks insane. I have personally replaced several analytical programs a very large bank used to monitor loan originations and performance.

I don't use any special SQL language features to this day. The most sophisticated it typically gets is involving lots of subqueries, joins, and window functions. The real skill is distilling the convoluted imperative mess into its essence. I got really good at this.

Half the work effort is usually spent on socializing the changes I have to make to their logic to get it working right in SQL when it changes the behavior of their existing application's logic. Often times I find the client's imperative code attempting to perform a logical operation such as a join but it is implemented incorrectly.

Their existing imperative code operations actually produced the wrong results (subtly) frequently or their imperative code depended on the order of the data returned from the database (undefined behavior). Yikes.

What they actually wanted was provably implemented incorrectly or relied on undefined behavior and their mistakes and the proper resolution in SQL could be easily verified with paper and pen on a sample set of loans if necessary to drive the point home.

Very cool. So you write it with solid, declaritive SQL and you can trust that it will be rock solid and optimizied. Need to learn SQL instead of just doing NoSQL all the time. Thanks for the explanations.

I load JSON into Postgres all the time these days for analyzing data for a government client and use Postgres JSONB operators to untangle and index it. JSONB because I don't care about preserving the original string representation of the record (strings in fields are still completely intact).

Although I heavily lean on psql with \COPY and stdin or stdout pipes to a compressor like zstd (psql can natively pipe CSV to and from any program reliably even in Windows) I found loading JSON records to be extremely frustrating this way.

Whatever you do NEVER use pipes in Powershell. They don't stream. They buffer in RAM fully into your computer crashes. Microsoft is insane.

Since you use NoSQL you can write a very short Python program that uses psycopg2 directly to load a list of dict as JSONB rows into a single Postgres table with one column (I call mine "record")

At that point you can basically use Postgres as a NoSQL database and structure the records if you want using a VIEW.

We're in the process of documenting their use of JSON for financial records keeping as a design defect.

That just sounds like very sloppy programming.

> Not only that, but database engines are improving all the time, so the same code you wrote which declares your desired transformations tends to get faster over time and there is nothing to update or refactor. The transformations you write are sort of timeless because they are strongly decoupled from the implementation and hardware.

Only true up to a certain extent. Counterexample: performance regressions due to changes in the query planner / its input statistics. Changes aren't always positive and logically equivalent plans can have very different perf characteristics.

Fully agree. I am mostly on the analytical side. When my client uses Snowflake it's usually smooth sailing because it's so automated and performant. When I have my own analytical Postgres instance on my local machine I tune costs and memory consumption parameters in postgres.conf but I only rarely run into major gotchas. If my client uses IBM... I go for a walk on the beach or go out to lunch when I launch my query.

Your point about equivalent plans can have very different perf characteristics is very true. I always try to review the query plan with EXPLAIN if my query takes more than a minute and rewrite the logic if necessary.

I'm in agreement with GP; I work daily on code that does it the traditional way, and I use the "do as much as possible in SQL" in my own side projects, and it always seems more maintainable to push off all the data logic into SQL.

> Do you have any good examples of this? Code bases that can be read?

I don't know of any projects that do this, but I do this for many of my side projects.

Keeping the business logic in-database was a major move in my career and a huge source of « well done sentiment ». My perfect combo today rely on golang as the (thin) API layer, querying data and making CRUD using plsql procedures, enforced by triggers and constaints.

+1. And the subset of those applications concerned with simply converting result sets <-> JSON over HTTP may well even tolerate use of an API generator (eg PostgREST, PostGraphile, Hasura), reducing that thin layer to merely a membrane.

> Early in my career, I thought my lack of "getting OOP" was due to some profound missing piece of understanding

It simply does not have formal definitions and examples. Almost everything in OOP books and content is defined like "imagine you have this situation and you want to do this thing..." and then it starts with ships, containers, ports, cranes or animals and lions.

The thing I like about fp is that there's surprisingly little things to know, and they all have formal definitions. The definitions are also quite simple and build on previous definitions. If you know what a data type and a `map` operation is, you can easily understand a functor. You add to it another ingredient and you have an applicative functor. Another one, and you get a monad.

You make small steps towards knowledge that are solid.

syntax, imperative statements and classical object verbosity and inappropriate structure always hurt me

whenever I read a lisp / ml book, I sweat a bit and then I gain superpowers and insights, whenever I read mainstream OO books I just get a neverending stream of "please stop.. why ??"

and it's not only lisp to be frank but a mindset that lisp embodies a lot.. even using an hp48 felt better than basic+algebraic programming calcs .. (at the time I had no idea what was RPL)

Me too. I've also been trying to learn more about OOP and reading "Smalltalk, Objects and Design" bc I heard a lot about how Smalltalk is the real, good OOP. But there were points I just felt squeamish, like when they were talking about the danger of the difference of effect vs. output on methods where I felt anxiety and thinking "ooo, why would I wanna do that??" I can just feel my code getting messier...

Some ideas like using polymorhism to avoid branching conditionals was interesting though and I'm sure there's times it can be helpful.

For me, it's the opposite, I like Lisp and Scheme because they don't force me into one programming paradigm. I'm not very fond of FP but used OOP almost in every project when I was programming in Racket (for a decade or so). I often wrote more functional code first and then wrapped it into classes to "assemble" it under one roof.

Lisp and Scheme are great languages for object-oriented programming.

My comments where not at all to make a statement about FP vs OOP, for me they both have their place, and I agree that Lisps are great OOP languages. It just turned out for me that FP came more naturally as a new programmer, and learning about the subtleties of lambda the ultimate, lexical scope and state from an FP perspective helped me to finally feel like I grok OOP. I was pleasantly surprised to see someone else express a similar sentiment.

I am not against / for any reasonable paradigm. I use multiple however I see fit depending on particular situation. Never wanted to be a "purist".

Indeed. Sometimes it's more obvious to say "here are the steps to make this thing, now go" and sometimes it's more obvious to say "here's a description of the things I want."

My experience has been exactly the same.

Show me a GUI framework that follows FP patterns not OOP.

https://elm-lang.org/

https://phoenixframework.org/

Off the top of my head:

  * React
  * Elm
  * Halogen
  * Phoenix
  * Phoenix LiveView
  * Re-frame
  * Reagent

Swiftui

Jetpack Compose (Android)

Plenty of Kotlin classes and method dispatch going on there.

Plenty of Swift classes and method dispatch going on there.

React is using JavaScript OOP, with the instances of JavaScript objects for data types and DOM manipulation, it doesn't exist.

React moved away from OOP quite a while ago. It's mostly pure functions and closures that return what are functionally records.

When the JS tuple/record proposal is finally implemented, I suspect they go even farther in that direction.

Of course, you could argue that closures are simply objects with one method (or that objects are a poor man's closures), but that's a rather pedantic line of discussion.

React is written in JavaScript, a OOP language with prototype inheritance similar to SELF, it doesn't get more OOP than that.

Take anything that has object semantics on the JavaScript VM out of React source code, and it will be reduced to almost nothing.

The fact that JS has OOP doesn't mean your code relies on those OOP features in any meaningful way and MOST modern code does not.

JavaScript functions and basic data types have member functions and object prototypes, so...

It is like writing React in Smalltalk and arguing that because the code uses code blocks it isn't OOP.

I wonder if dearimgui would count or if it's just imperative

I would put it more on the declarative side of things than functional or imperative. It does feel like a better fit to imperative programs though where execution is moving through the code as opposed to functional programming where expressions evaluate to results.

This is of course a silly but valid criticism of a post claiming FP is better than OOP in every situation. As others have pointed out, there are functional GUI frameworks, though of course something state-heavy is going to be more naturally modeled with OOP in some cases.

But that is all beside the point- OP specifically did not claim FP was always better, just that they found it more natural. That personal and subjective experience (which I share) is utterly orthogonal to the relative maturity of GUI libraries! The fact is, most GUI frameworks are OO, and the ones I learned were all OO. And I hated them! I am not a person who enjoys making GUIs, and that's in large part because I am not a person who enjoys OOP. When I learned my first functional language, it felt like a breath of fresh air. While I was a perfectly serviceable Java and Python programmer, Haskell just made sense immediately. That doesn't make Haskell a better language in absolute terms, but it was much better for me.

Now that I've worked with functional languages, I find I actually don't mind imperative languages at all. I don't really need 100% of the bells and whistles to write composition focused code that meshes with my brain, especially since just a hint of state here or there can free you up to do the rest of it statelessly. And now I find that as I build interfaces with LiveView or Vue that I actually do enjoy making GUIs- even if there is a little state here or there.

People, and this might come as a shock, are sometimes different from each other. And sometimes their talents don't match up perfectly with whatever task you feel is important in the moment. There's lots of programming which isn't as state-heavy as a GUI, just as there's lots of programming more state heavy than a data processing pipeline.

Aside from the all the FP-style GUI frameworks others have listed, it's also worth noting video game development adopting "data oriented design" [0], rather than OOP (usually in C++).

[0] https://www.youtube.com/watch?v=rX0ItVEVjHc

In this case FP is even worse (you need to copie information to use it), I don't feel this is a case of which is about paradigms but more of make paradigm that push the limits of the hardware

A smart enough compiler will eliminate 90% of unnecessary copying and things like linear/affine types will eliminate the rest

Reply on news.ycombinator.com