[willtim]

> one of the places where computer science has gone backward, preferring more clunky systems and less elegant paradigms

I respectfully disagree. Smalltalk has had its time. OOP has had plenty of investment and exploration, but it's fundamentally non-compositional and is a poor fit for modern hardware. Other paradigms, for example statically typed functional languages, are just as expressive (the expressive parts of Smalltalk were functional features anyway) and have much more to offer in terms of building reliable software that does not crash and is secure.

Programming is hard, there is no silver bullet, but computer science is moving forward.

[abecedarius]

As long as we're trading opinions: the OO vogue of 1990-2010ish and the anti-OO reaction since then were both too much a matter of fashion. OO and FP are both powerful ideas, neither dominates the other, sometimes you can combine them, and you don't have to declare allegiance to either.

[willtim]

The attraction of "functional programming" to academics and many others, is that the paradigm is underpinned by established and well studied mathematical logics. For example, the lambda calculus or more recently linear logic. You can view this as "fashion" if you like, but by making programming more formalized and less adhoc, it's probably better recognised as progress.

[bmitc]

I’m not sure that stronger type systems always means an improvement to writing programs. They simply move the needle on the scale of where the difficulty lies in writing programs.

Untyped languages make it very easy to write programs while the stronger the type system, the harder it gets to write the program in the first place.

I think balance is in order and this is one reason why we haven’t seen fancy type systems become mainstream except for niche domains. If I’m writing a program in F#, I have a balance between a type system constraining me but a language that allows me, the programmer, to do what I want to do for the most part. The stronger and fancier type systems means I now have to somehow teach the type system things that I already now how to do and are safe.

Fancy type systems simply try to say that you should write down a specification of your program. But in the real world, this is an enormously difficult if not impossible task. It makes the programming process and program rigid and brittle and not robust, which is not necessarily properties of software you want.

There’s a reason why certain language ecosystems like Erlang/Elixir say errors, unexpected input, and more pathological events will happen (i.e., they can’t be reasoned out of the system) and so you need a way to explicitly deal with them. This is also a big theme in the recent book Software Design for Flexibility in terms of expanding programs, getting them to handle things they couldn’t before.

While fancy type systems are neat, like those in Idris, I think the most useful idea is to have mixed type systems and programming paradigms in a program, which seems to be relatively unexplored right now.

[willtim]

Any statically typed language allows one to use dynamic types when it is necessary. I don't see the problem. If you need a map of string keys to variants, this can be done. At least one can still put some static constraints on the types when necessary.

[pyuser583]

Those advantages aren’t merely theoretical … implicitly gained knowledge is extremely powerful in FP.

[sicromoft]

Why are we downvoting someone who is respectfully disagreeing?

[mpweiher]

1. If OO is a poor fit for modern hardware, FP is much, much worse.

2. Actually OO is highly compositional.

3. The few actual studies that have been done disagree on static FP being more expressive (or safer). In fact, if you look at something like Mozart/Oz, they make the case that FP is less expressive.

4. Agree there is no silver bullet. On the other hand, the gentleman who wrote "No Silver Bullet" actually also wrote that he viewed OO as one of the closest shots we have at a silver bullet. And 10 years later wrote that this turned out to be correct.

[grumpyprole]

1. FP is easier to optimise and is data-centric, which is much more useful for parallel processing. For example, game engines like Unity have been forced to move away from OOP and towards more data-centric architectures.

2. OO often features pervasive mutable state, which is hidden but not encapsulated. Side-effecting computations fundamentally do not compose. In the worst case, one ends up with a combinatorial explosion of the state space, good for simulations, but no so good for building systems one can easily reason about. This is what functional programming sets out to solve. OO does encourage modules, which is a good thing and can help with composition. But modules are not unique to OO.

3. Static typing is (obviously) safer than dynamic types. Smalltalk got most of its expressiveness from closures.

4. OO is clearly not a silver bullet. US academics need to invest more time in exploring functional programming (and actually teach it to their undergrads!).

[mpweiher]

You are making a lot of unsubstantiated claims.

1. Unity did not move to FP. FP might be "easier" to optimise, but it starts off from such a disadvantage that the relative ease usually can't make up for it. (The same is true for Swift, by the way: they also make great claims for how much it optimises, and those claims are largely true, but its base performance is so horrible that those heroic optimisations leave it slower than the language it replaces)

The claimed advantages of FP for parallel processing are still vastly outweighed by the imposed overhead. I remember a talk by SPJ where he also made vast claims for the advantages of FP for parallel processing. At the end of the talk, he had to admit that the FP version needed 6 cores to become equivalent to a single core with C. He also claimed that some technique was "only possible with FP", but an audience member informed him that this very technique had been standard in HPC FORTRAN for quite some time.

So these unsubstantiated claims have to be taken with a HUGE grain of salt. For high-performance, you still turn to tuned, mechanically sympathetic low-level code, not to FP. FP is about as mechanically antipathetic as possible.

2. Hand-waving. Have you heard of "object composition"? While you might believe that OO doesn't compose, for theoretical reasons, the fact is that it does, in practice. If your theory predicts something that turns out to be wrong, it is time to update the theory, rather than complain about the world.

Also this "reason about" canard gets bandied abound a lot, but it is mostly just that: a canard. It refers to a very specific type of mechanical reasoning that is rarely done when actually trying to understand real code. FP code tends to be very hard for humans to understand.

3. It might be "obvious" to you, but: "It ain't the things that you don't know that kill you. It's the things you know that just ain't so". Every study purporting to show increased safety for statically typed languages compared to dynamic languages has been shown to be incorrect, sometimes comically so.

What has been shown is a documentation effect.

The idea that Smalltalk got most of its expressiveness from closures is laughable. What is true is that you absolutely do not need FP to reap the benefits of higher order code such as blocks.

4. Straw man. Nobody claimed that OO is a silver bullet. But once again, the very person who coined the phrase and wrote the paper "No Silver Bullets" said that he viewed OO as the closest thing to such a silver bullet. And 10 years later, he said that his belief had been shown to be correct.

[grumpyprole]

> You are making a lot of unsubstantiated claims.

As are you!

1. I did not claim unity moved to FP, I said they dropped OOP and went to a data-centric processing. Even C (with Clang) now gets transformed into SSA form (static single assignment) in order to make optimising easier. The compiler is literally undoing the imperative programming! You claimed FP was a worse fit for modern hardware than OOP. That is an unsubstantiated claim.

2. I've done OOP for a decade professionally before another decade of FP. The OOP systems were by far the hardest to reason about and maintain. I can therefore argue this both theoretically and anecdotally. Industry is also (slowly) moving away from OOP. More recent languages like Rust and Go are no longer OO.

3. I guarantee that you will not see any future systems programming language that does not use static types. Dynamic languages will occupy niches were reliability and security are less important.

4. Fred Brookes is just one US academic. I'm sure Alan Kay likes OOP too. My point was that the US is very heavily invested in OOP, it's what the universities exclusively teach. Outside the US, OOP has always been much less popular.

[mpweiher]

> As are you!

Nope, I actually have empirical (and other) evidence.

> I did not claim unity moved to FP

EXACTLY. But you cited unity as evidence for FP being superior for performance than OO. As it doesn't use FP, it's actually not evidence for that.

> I've done OOP for a decade professionally before another decade of FP.

I did FP 30+ years ago and have been doing OO for around 40. So what? ¯\_(ツ)_/¯

Anyway, my evidence is not anecdotal, but empirical. There haven't been many studies on productivity, but those few have shown OO languages to be vastly more productive.

https://blog.metaobject.com/2019/02/why-architecture-oriente...

On re-reading John Hughes influential Why Functional Programming Matters, two things stood out for me.

The first was the claim that, "...a functional programmer is an order of magnitude more productive than his or her conventional counterpart, because functional programs are an order of magnitude shorter." That's a bold claim, though he cleverly attributes this claim not to himself but to unspecified others: "Functional programmers argue that...".

If there is evidence for this 10x claim, I'd like to see it. The only somewhat systematic assessment of "language productivity" is the Caper Jones language-level evaluation, which is computed on the lines of code needed to achieve a function point worth of software. In this evaluation, Haskell achieved a level of 7.5, whereas Smalltalk was rated 15, so twice as productive. While I don't see this is conclusive, it certainly doesn't support a claim of vastly superior productivity.

> Industry is moving...

Industry has lots of fads that come and go. Remember SOAP? Or CASE? Now that FP is starting to be used more in the real world, a lot of the shine has come off. This is always the case: things tend to work much better before you actually have to use them in the real world? "Runs best on a slide projector"

He was asked about scala, and said that if he would have to choose again today, he's not sure he would go with scala.

https://www.quora.com/Is-Twitter-getting-rid-of-Scala?share=...

> 3. ...does not use static types... reliability and security.

Once again, there is no empirical evidence that static types improve reliability and security, and it's not for lack of trying to make that claim. The claim has been made multiple times, but always fails to actually be true.

The most recent study to make that claim was demolished at SPLASH '19.

https://2019.splashcon.org/details/splash-2019-oopsla/75/On-...

So very strict static types do not actually improve safety, that has been proven over and over again. What they actually do provide is safyness, the feeling that your code is safer:

https://blog.metaobject.com/2014/06/the-safyness-of-static-t...

Also, "does not use static types" is a straw man these days. The approach that appears to be gaining traction is hybrid typing, with some parts statically typed, some parts dynamically typed.

> Fred Brookes is just one US academic.

Fred Brooks is not an academic.

https://en.wikipedia.org/wiki/Fred_Brooks

He and Alan Kay both received Turing awards and pretty much every other prestigious prize in the industry you care to name. You are obviously free to dismiss them, but that mostly reflects on you and not on them, and it's kind of weird to do that when you refer to their work, particularly Fred Brook's seminal No Silver Bullet – Essence and Accident in Software Engineering, to make your point.

It really helps to actually know something about people or approaches before dismissing out of hand.

> My point was that the US is very heavily invested in OOP,

Because it works. They are a very pragmatic bunch.

> it's what the universities exclusively teach.

Not true, or at least causally inverted. For example, MIT taught Scheme for a long time. And switched away from it, because the people teaching it no longer saw it as a benefit. Did I mention "pragmatic bunch"?

Me, I went to University in Germany back in the late 80s early 90s, and was tortured with FP by the zealots from the very start (though I did take it all the way to "Advanced FP" and did my exam for the course on Backus's FP calculus, which I actually liked a lot, and yes, I aced that exam). Of course, being exposed to FP from so early on made me realise very quickly that the emperor had no clothes.

> Outside the US, OOP has always been much less popular.

On the fact that most software is written on one side of the Atlantic Ocean -- Alan Kay (in response to Dijsktra's On the fact that the Atlantic Ocean has two sides, http://lambda-the-ultimate.org/node/2087 )

[grumpyprole]

> Nope, I actually have empirical (and other) evidence.

You haven't provided any concrete evidence. Certainly no more than I have.

> But you cited unity as evidence for FP being superior for performance than OO

No, I provided it as evidence of OO being poor for performance and suggested that its new approach is closer to FP (i.e data centric). Perhaps a better example is Apache Spark or Google MapReduce for large scale data processing. Those frameworks are essentially FP, it's why lambdas were added to Java. So there's plenty of evidence that FP works for high performance.

> I did FP 30+ years ago and have been doing OO for around 40.

FP has matured a lot in 30 years. My point was that I have equal amounts of both and I have no reason to be biased. If you've done 40 years of mostly OOP, I'm not sure you can make the same claim.

> He was asked about scala, and said that if he would have to choose again today, he's not sure he would go with scala.

Scala is absolutely not a functional programming language and Odersky never claimed it was. It's primarily an object-oriented language with some functional features bolted on. Functions are not first-class and pervasive mutable state still exists. It would be just as unfair for me to judge OOP based on the shortcomings of C++.

> Because it works.

What do you mean "works"? Yes I can get the job done in OOP, but it has all the problems I have tried to articulate previously.

> Fred Brooks is not an academic.

From the article you linked: "In 1964, Brooks accepted an invitation to come to the University of North Carolina at Chapel Hill and founded the University's computer science department. He chaired it for 20 years. As of 2013 he was still engaged in active research there"

So you are really splitting hairs here. Does it matter?

> It really helps to actually know something about people or approaches before dismissing out of hand.

Can we please refrain from personal insults and keep the debate civil. I have spent a decade reading the books and teachings of these people; and trying to apply their ideas in industry. I am not dismissing them out of hand - that's why I cite them sometimes. I could accuse you of doing the same for FP and its community, but I won't as it would be unfair.

[lalalandland]

OP said IDE, not object oriented programming. Most Smalltalk dialects have very nice programming environments that makes it much easier to be productive.

[rbanffy]

And even Smalltalk/80 was light years ahead of pretty much any IDE that came much later. It is a whole OS with integrated development and debugging tools.