Squeak gave me the greatest pleasure I had while programming. I was not a fan of IDEs till then, preferring vi at that point, with ctags.
Sadly it is one of the places where computer science has gone backward, preferring more clunky systems and less elegant paradigms. Except when it comes to the higher reaches of the meta object hierarchy, Smalltalk itself is a great pleasure - Squeak was the icing on the cake for me.
> 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.
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.
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.
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.
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.
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.
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!).
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.
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.
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.
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.
> 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.
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:
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.
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 )
> 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.
Actually, I did. Snipping it from the replies and ignoring doesn't, in fact, make that evidence go away.
Whereas you have provided exactly zero evidence for your claims, except for repeating your opinion.
>What do you mean "works"?
It gets the job done effectively and efficiently. Caper Jones found half the effort to implement the same function points in Smalltalk vs. Haskell.
> FP has matured a lot in 30 years.
Not really. Still the same hyperbolic claims, and still the same meagre results.
> [OO] has all the problems I have tried to articulate previously.
No it doesn't, and just repeating an opinion over and over doesn't turn that opinion into fact.
> [Frederick Brooks an academic] Does it matter?
If it doesn't matter, then why did you bring it up? Oh right, to dismiss his widely cited article that you yourself referenced as "just one academic's opinion". Well, he is not, in fact "just" an academic, but has more practical experience with software than most people on the planet, including you and me. He is also an academic. So someone with vast amounts of industrial and academic experience and expertise.
> keep the debate civil.
It would have been nice had you done that.
Anyway, it is clear that you aren't interested in evidence or reasoned debate, so I think we can call it a day.
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.
What you wrote is "Fred Brookes is just one US academic." That is not a positive statement or an acknowledgement that he has made big contributions, that is a dismissal of what he wrote.
./sentiment.st 'Fred Brookes is just one US academic.'
{
label: neg;
probability: {
neg: 0.5681116649451591;
neutral: 0.4912856963089782;
pos: 0.4318883350548409;
};
}
The key is the "just one":
./sentiment.st 'Fred Brookes is one US academic.'
{
label: pos;
probability: {
neg: 0.4517101153187268;
neutral: 0.4880877595448765;
pos: 0.5482898846812732;
};
}
And replacing the "one" with "a":
./sentiment.st 'Fred Brookes is a US academic.'
{
label: neutral;
probability: {
neg: 0.4032643317660632;
neutral: 0.7398809320488215;
pos: 0.5967356682339368;
};
}
So we go from -0.57/+0.43 for your formulation to +0.6/-0.4 for a neutral formulation, a swing from negative to positive of 34%. Pretty substantive, if you ask me.
The sentiment.st script:
#!env stsh
#-sentiment:text
(ref:http://text-processing.com/api/sentiment/ postForm: #{ #text: text })
Anyway, glad to hear that this statement of yours was not a reflection of your actual views.
[Caper Jones: Smalltalk twice as productive as Haskell]
> I never made any claims about Haskell
You made claims about FP and OO in general, and in particular questioned my statement that "OO gets the job done" and also claimed I provided no evidence for my claims. Haskell is an FP language and Smalltalk is an OO language, and both are considered premier exemplars of their respective genres. Being twice as productive sure sounds like "getting the job done" to me and there is empirical evidence for this being true.
> I'm sure many static type systems are bad, but it doesn't prove all are bad.
Nobody claimed that all static type systems are bad. However, the evidence is in that any claims of "obvious" superiority of static typing over dynamic typing for safety are plain wrong. Such as your original claim:
> Static typing is (obviously) safer than dynamic types.
Glad to see that you're now walking that earlier categorical statement back to "not all static type systems are bad", something I can agree with. I am actually pretty sure some are fairly good, particularly the non-bondage-and-discipline ones (gradual/hybrid) have a decent chance.
As a matter of fact, I am currently in the process of improving the fairly minimal type support in my own programming language. And I even have some ideas in the back of my mind of how to do non-horrible generics, but that isn't the primary focus.
OP said IDE, not object oriented programming. Most Smalltalk dialects have very nice programming environments that makes it much easier to be productive.
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.
dabble db went tragically obscure. they were arguably the first to have a server driven ui with state tracking done in the server. It was a brilliant solution to complex state at a time when spas were just crawling out of the ocean. The biggest challenge was scaling the management of all those individual user's states. Meteor and elixir liveview both are doing this now to varying degrees of success.
I had a whole semester worth of Squeak at Georgia Tech. Can't really remember much at this point except that everything was an object and the environment we worked in was super slow.
Smalltalk has always been decades ahead of its time and it being slow on, say, the Alto or the Star, was kind of expected. That said, Squeak is very nimble compared to pretty much anything else currently in use. I’ll assume your memory is from the late 90’s and the computers were not particularly fast.
Squeak's virtual machine was an interpreted one until the company Qwaq hired Eliot Miranda in 2008 or so to develop a JIT compiler virtual machine. His "Cog" VM is what is used for Squeak, Pharo, Cuis and NewSpeak on x86, x86-64 and various versions of ARM. This, combined with faster hardware, makes for a much nicer experience than in 2002, for example.
Of course, some of the extra performance is lost when new layers of code get added, specially in the graphical user interface.
Im not sure performance was ever the problem for Smalltalk after GUIs became mainstream. At first, it was license cost and, after free (as both speech and beer) versions became available, the main issue was the alien feel at a time apps were following desktop UI guidelines closely and the “doesn’t play well with others” feature.
The UI conformity requirement has loosened up a lot with the web and web apps, but I guess that the time is still not right.
It is objectively slow, but not slower than full featured IDEs like Visual Studio or IntelliJ, which offer a much more constrained environment and toolset.
Sadly it is one of the places where computer science has gone backward, preferring more clunky systems and less elegant paradigms. Except when it comes to the higher reaches of the meta object hierarchy, Smalltalk itself is a great pleasure - Squeak was the icing on the cake for me.