Learning Squeak (2019)
wiki.squeak.org
wiki.squeak.org
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.
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.
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.
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.
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.
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.
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 )
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.
Have a good one.
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!
./sentiment.st 'Fred Brookes is just one US academic.'
{
label: neg;
probability: {
neg: 0.5681116649451591;
neutral: 0.4912856963089782;
pos: 0.4318883350548409;
};
}
./sentiment.st 'Fred Brookes is one US academic.'
{
label: pos;
probability: {
neg: 0.4517101153187268;
neutral: 0.4880877595448765;
pos: 0.5482898846812732;
};
}
./sentiment.st 'Fred Brookes is a US academic.'
{
label: neutral;
probability: {
neg: 0.4032643317660632;
neutral: 0.7398809320488215;
pos: 0.5967356682339368;
};
}
The sentiment.st script:
#!env stsh
#-sentiment:text
(ref:http://text-processing.com/api/sentiment/ postForm: #{ #text: text })
[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.
Of course, some of the extra performance is lost when new layers of code get added, specially in the graphical user interface.
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.
Python is also “slow” and we still use it.
BTW, it’s nice to talk yo you again, Jecel.