Interesting! I believe that the statement about using Mathematics as ‘general programming language’ might have been the inspiration for the language Fortress which contains/contained some very cool ideas:
- You write your code in semi-pseudocode (the exact syntax of Fortress was based on a lot of research by Guy R. Steele about how pseudocode has been written in many papers over the years), which can use Unicode mathemathical symbols (or a LaTeX-y ASCII equivalent of them).
- This code can compile to machine code, but also to a beautifully rendered PDF for human consumption.
- Iterating over collections happens, by default at least, in no particular order and on as many CPU cores as your computer has.
Unfortunately, development on it ceased after a couple of years. Nevertheless, I believe that Fortress in turn was one of the inspirations for Rust (although I do not remember the source of that claim).
I find the writer of that article undervalues what Joe Armstrong said (more complete citation from Armstrong’s text: Nice read about oop (with historic citations from A.Kay f.e.) .
This is a nice presentation from mpj who proposes not to use inheritance at all: https://www.youtube.com/watch?v=wfMtDGfHWpA . Another problem (besides inheritance & dependent use of patterns) I saw in OO code is the (over)use of dependency injection, introducing needless instance variables that cause coupling between object members (methods etc.): https://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/
I found myself, following what Armstrong says, working towards a ports and adapters architecture https://blog.ploeh.dk/2016/03/18/functional-architecture-is-ports-and-adapters/ . I turned parent objects into helpers and send them to methods in parameter objects.
Alexander Stepanov: “inheritance is bad unless base class has no members”
I think the core article is Dependency Rejection.
I like how Mark Seemann’s posts often revolve around pushing the impure code to the edges of the system and how he uses Haskell for creating functional reference implementations to inform the design of production code.
However I would expect that lots people would be uncomfortable with how
// Reservation -> int option let tryAcceptComposition reservation = reservation.Date |> DB.readReservations connectionString |> flip (tryAccept 10) reservation |> Option.map (DB.createReservation connectionString)
tends to expose implementation details that they are used to burying (encapsulating/injecting) deep in an object somewhere.
At the time (1990s) OO felt like a step up from structured programming in terms of organizing a code base.
But as Rich Hickey outlines in Value of Values (2012 July):
OO had a head start because it worked within the given limitations of the computer hardware at the time - limitations that held other approaches back. However since then:
It’s largely advances in hardware that have made it possible to create increasingly complex systems - more complex than the complexity that needed to be tamed back in the 1990s.
FP may not be the saviour but class-based OO needs a lot more (continued) scrutiny and not be automatically grandfathered as the best way to move forward.
From an interview with Tony Hoare (2002)
There seem to be some fundamental issues with OO, outside advances in hardware. But we’re stuck with large OO codebases that need maintenance.