willtim

Given your rather patronising replies, I suspect the original joke was lost on you. The issue is not Agile per se, it is organisations assuming that "Agile" will solve all their problems, where "Agile" usually means vendor products, forced rituals and tick boxes. Yet more Agile evangelism does not address this problem.

What organisations need more than anything is open minded individuals that are not slaves to established dogma. The Agile manifesto actually says that all methods should be constantly re-evaluated to see if they fit the particular organisation/team. Your empirical "evidence" likely comes with a lot of context and is unlikely to be applicable to all organisations and/or domains.

It was joke. Your position looks rather like the true Scottmans fallacy to me.

The evidence you provided was for strawman arguments, something you accused me of. I'm sure Smalltalk can be easier / more "productive" than Haskell, but I never made any claims about Haskell. I'm sure many static type systems are bad, but it doesn't prove all are bad. You didn't provide evidence to address any of my specific issues with OOP, e.g. pervasive mutable and hidden state is an impediment to composition.

For the record, I happen to really respect Fred Brooks, Alan Kay and a lot of what OOP has achieved (for example first-class modules). I called Brooks an "academic" as an acknowledgement that he has made big contributions, not as a putdown as you seem to imply. You are trying to paint me as an FP zealot, but I use both and appreciate the best parts of both. It is you that are coming across as heavily biased. Even your domain name has "object" in it.

Enjoy your objects!

> 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.

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.

> 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.

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!).

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.

> 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.

Is there any operating system left now that isn't riddled with bugs? I blame Agile.

I could not find any add-on (that still works) to give me back my tray icons. Not even Apple would take this feature away.

It's worse than that. The desktop efforts are heavily fragmented and arguably the leader, RedHat's "Gnome", while quite polished, is actually quite user hostile (e.g. works very differently to anything else, perhaps to dodge patents; and constantly changes/removes popular features). Linux needs to have a standardised "platform" with stable APIs.

Good point, but IIRC Dijkstra didn't like Fortran either. ALGOL (1958) used ":=" for assignment, as did Pascal some years later.

When BASIC e.g. redefined what "variables" are and what the equals operator means, it did cause a generation of programmers to drift away from the long established mathematical definitions. This persists to this day in languages like Python. I have had to explain to my daughter that Python variables and equals are not like those in her maths lessons. Dijkstra was right to call out the bad decisions that were made, although I do concede his methods of doing so were not ideal.

> the phrase "avoid success at all cost" in a certain context which may have had some role in making Haskell seem Ivory Towerish.

This phrase is often misunderstood, it's "avoid, success at all costs", not "avoid success, at all costs". In other words, don't optimise for mass market adoption at the expense of everything else. Languages that have arguably done so, have ended up as extremely complex and ridden with corner cases.