Likewise, I encourage even those with some experience in other Smalltalk implementations to give Pharo 5 and this text a go. Starting with Squeak and evaluation copies of VisualWorks nearly 15 years ago, we now have over 1M LOC of Pharo in production.
A great example of the original design principles, that Dan Ingalls described, in action.
Am I reading this accurately?
Something does not add up well.
I upvoted this comment tree but I’ll still offer a semi-counter. The language has already established itself to have reasonable performance vs mainstream, Web-oriented languages plus more safety than many. The common gripes about it are a lack of one, good, standard library along with tooling. 2-4 fit the common gripes. These are even expected since it’s a language developed by academics that wrote compilers and do formal verification for use by those types extended for convenience by them and a thriving community. Yet, these main problems remain since… apathy, people not adopting Jane St’s stuff, or outside of original scope? Idk.
The starting point isn’t countered by the rest as it applies to just the foundation the language provides. That’s good. It just needs work on library and tooling side to make it more suitable for real-world applications that it wasn’t necessarily designed for. Whereas, high-assurance sector is getting a lot of mileage out of languages like Ocaml by using it where its attributes are strong. Esterel’s report is a nice example with Section 3 being enlightening:
When I read,
OCaml was initially introduced for its execution speed and ease of refactoring.
I wonder if those characterizations of OCaml were based on their own experience and measurements against a defined target or simply restatement of commonly held beliefs. I’ve certainly read both statements elsewhere, but I rarely read of people or companies running in-house experiments to make such decisions. Google and disk performance and lifespan, yes. Jane Street and OCaml, probably. Here?
I used OCaml for a proof-of-concept on a large networked application many years ago, but I found unpredictable performance under high load with difficulty resolving the source prohibitive. Concept proved, I rewrote it all in C and lived happily ever after.
So they gladly would trade 10x perf for debug
The article doesn’t say it would trace a 10x performance decrease in general, only a performance decrease when handling an exception. Here is the article quote:
We would happily accept an order-of-magnitude performance decrease in exception-handling performance if we could have better stack traces instead.
Stack overflows are relatively easy to debug even with a truncated stack trace.
(and as /u/ngrilly says, the 10x perf was specifically about exception throwing/catching, not in general)
Also the sad reality of the industry is that the bar for “safe” is ridiculously low.
But the standard library stack overflows
The compiler standard library does but it is trivial to write your own and in fact many people do. When you compile your code, it is fast. And I think the reason for the pervasives to be non-tail recursive has to do something with performance in the average case of inputs not overflowing if I remember it correctly.
If it’s “trivial” to write, why not include a decent version in the first place?
“Most people rewrite the standard library” is not a very great endorsement of a language.
Agreed - that’s exactly the kind of fragmentation of the community that Common Lisp is often criticized for. It means people can’t read each others' code, and integrating is much harder. It seemed perfectly fine for a while, but it’s a core reason that Clojure is far more talked-about today.
This came up again in the context of the recent Dyn DDoS and comes up regularly in discussion of the Internet of Things and its general total lack of software or security.
Link? I’m wondering why people think this. Do you mean people are arguing it would have made taking over the IoT devices impossible in the first place, or that a static type system would somehow make handling a DDoS possible? In any case, I think any reasonable person would see through these statements pretty quickly. You can find someone who has said just about anything.
As static typing becomes more elaborate the scope of the bugs it can prevent becomes wider, but it comes with an additional cost: Build times.
Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.
My general experience of the correctness software written in fancy statically typed languages is not overwhelmingly positive compared to that of software written in dynamic languages. If anything it trends slightly negative. This suggests that for the scale of many projects the costs and benefits are close enough that this actually matters.
Having written and inherited code in a dynamically typed language, I can say the big win, in my experience, is refactoring. IME, a lot of people (on both sides) talk about producing code the first time. IME, that is pretty easy no matter what language one is it. Coming back to code 6 months or 6 years later is a much different story.
Coming back to code 6 months or 6 years later is a much different story.
Oh gosh this so much.
I’ve inherited various chunks of under-documented under-tested code over time. Type-y assistance where present has made all the difference in these situations!
Maintaining nearly 80KLOC of OCaml over three years, I was able to use repeated edit-compile-error-scratch-head sessions as a means to re-acquaint myself with the system. But this is such a low bar; we need better. Maintaining more than 1MLOC of Smalltalk over the past twelve years, I found leaning on a type system–even OCaml’s–to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.
I’ve heard that refactoring smalltalk is a great experience. I don’t hear the same about erlang. Is this just a matter of the smalltalk folks focusing more on tooling? They’re such similar languages in a lot of ways, I would think you could achieve similar things, but I don’t hear people talking about refactoring erlang systems with such reverence.
I can’t do it justice in a few lines, and I don’t want to clutter the discussion here. I will say that’s not just about Smalltalk but the mindset that Smalltalk fostered and, in turn, fed back into the evolution of Smalltalk. Go back, at least, to the writings of Ward Cunningham, Kent Beck, Ralph Johnson, and Brian Foote. As for Smalltalk itself, tooling almost emerges spontaneously from it because–I think–of the attributes I noted in the last line of my previous reply.
to be quite impoverished compared to a live, self-navigating system of uniform, recursively designed objects and messages.
Do you mean that the code bases are uniform in this way or that any program written in Smalltalk will have this quality? One reason I like a good type system is because most code is not uniform and the type system let’s me take messes and make them clean, pretty safely. But a type system is no panacea, of course.
You can write bad code in Smalltalk, as in any other language. One thing that sets Smalltalk apart is that it’s as much a system as it is a language. Further, it’s a system represented solely in terms of objects sending messages to other objects. Further still, it’s a running, fully reflective, live system with that entire object graph readily introspected and manipulated. So, in Smalltalk–as Alan Kay said–architecture (uniform recursive object system) dominates materials (code). In Smalltalk, even bad code is easily navigated, understood, and refactored.
“Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.”
Build time is measured the same, no matter the language. One could say a longer build time is justified because of certain benefits, but it’s still a longer build time.
I’m not sure what I said you’re disagreeing or correcting me on. I am saying Ocaml builds fast, but slower than Go, but you get a lot of typing out of that extra time.
That seems reasonable. The original statement might be more clear to me if it said “close enough to Go given…”
Ocaml has pretty reasonable build times. IMO, I would say Ocaml build times are close to Go given how much moe expressive the type system is than Go’s.
That’s a good example, thanks. I’ll add it in.
I have not forgotten Xenix, nor cross-compiling C/C++ between it and 32-bit extended DOS. One does not simply walk into Mordor…
I’ve been using StumpWM for a while. I can get by with others (i3, xmonad, spectrwm), but Stump works the most like what I want on a dev system.
I finally settled on StumpWM as my window manager of choice as well. It also counts as my “desktop environment”, which means no notifications and such. It really helps to keep me focussed on things.
My only quibble (and a self-inflicted one) is that I got used to C-t as a prefix key and use in tmux as well, so I have “double tap” it when using tmux inside StumpWM. I can’t find another prefix key I like. This is such a first-world problem that I really shouldn’t be complaining about it…
I used Alt-Space and that seemed to work well. It’s reminicent of Mac’s Cmd-Space to bring up spotlight. Another option is Ctrl-o because it doesn’t interfere with any default emacs keys.
C-o is open-line which I use all the time, but Alt-Space is worth a try. Maybe my first-world problems are solved. ;-)
Fortunately I was able to keep C-t for stump, C-b for tmux (it’s easy to type on the ergodox), and C-x for emacs.
The one thing that gets me when I use !stumpwm is that C-t C-t now opens two tabs.
I was evaluating StumpWM at some point (I’m an emacs addict, so there’s the lisp connection) and stumbled across this old demo: https://youtu.be/tKt_rVO960Q – just listen to the guy’s voice! (it’s super suave)
I’ve had StumpWM running around the clock under FreeBSD/SBCL for the past 3 years. As stable as an old client’s VAX!
Like Common Lisp, Smalltalk isn’t dead. It just smells funny. Dead or alive matters little to me. This past month, our Pharo-based cash-room system processed 10,000 cash-outs, and our admission system validated, redeemed, and counted 1.3 million tickets.
Dead or alive matters little to me
I think it matters in the scope of the OP. The OP refers to Alive as still exploring new ideas or how to leverage their core ideas in new ways. This is important to me. And it is that sense that Smalltalk is very much alive (and Common Lisp, much to my disappointment, dead)
For example, Pharo is pushing forward the idea that Everything is an object in Smalltalk to make it easier to work with the AST for a number of use cases listed in the slides. Even in their vision they mention they don’t strive for ANSI Smalltalk comformance. They are not reveering Smalltalk like those Humans in the planet of the aps reveering the atomic bomb. They want to keep moving forwards the ideas of Smaltalk.
It is in that sense the Common Lisp is dead. In that the ideas behind the MOP, like leveraging reflective semantics for a more configurable/modifiable compilation strategies or for modifying the behavior of the same code base for different requirements is not being explored on to my knowledge, except by Robert Strandh. Of course, even ‘dead’ CL is one of the best languages I know of. It suffers from a marketing problem though, but that is another topic.
Of course, even ‘dead’ CL is one of the best languages I know of.
Yes, our zombie-powered ticketing system running on a t2.medium sold the 1.3 million tickets :-)
Smalltalk is dead in just about every practical sense in which a programming language, a theoretical construct, can die. Look for:
Smalltalk has none of these, though feeble attempts may be made to deny it. And that’s ok; Smalltalk died, but not before siring some very successful children. None of us can hope for much more.
I’m going to take you at face value and assume you’re making these comments out of ignorance instead of malice.
There are at least two highly active Smalltalk communities, Squeak and Pharo. Each has many commits per day and are undertaking long-term complicated projects, such as changing their entire image formats, moving to 64-bit architectures, and changing their FFI systems.
Smalltalk, for reasons I’ve discussed in another arena today, tends not to have libraries on GitHub, but that’s not to say the community is inactive. They have a rich and thriving community on their own GitHub equivalent, and they’re working on making their tools interface with GitHub.
I think I just answered that, but if you want to explain why you find Pharo or Squeak of insufficient quality or insufficient maintenance, I’m happy to respond.
I don’t actually agree this gets us anything. Haskell, OCaml, Rust, and Nim are all actively followed projects by the Lobsters community, yet I cannot tell you a single project that’s a killer app in any of them. For that matter, I can’t tell you a killer app written in Swift, C#, Dart, TypeScript, Flow, Elixir, or Erlang.
There are also very mature, stable, actively maintained, and industrial-strength commercial implementations–from GemTalk Systems, Cincom, and Instantiations, at least.
Exactly. I found those in what little research I did. Strange critics often miss or ignore commercial implementations with significant, paid adoption.
I won’t even mention the number and scale of the clients in their success stories (no doubt, you came across some of those).
Large enterprise applications in transaction processing, datamining, messaging, scheduling, and so on probably shouldnt count. Not complex IDE’s or associated toolchains either. No, they want something more to really prove its value.
“Show Lobsters: Say Hello to AlloTalk - A smarter messaging application from Google’s Smalltalk team.” (800 upvotes on last site)
Haskell has pandoc at least, and it’s used heavily within Facebook and the finance industry, if that counts. (Not trying to knock Smalltalk here.)
Erlang has WhatsApp.
Heh, though I’m not sure if that influences me. I’m certainly not required to learn erlang to use whatsapp. Even knowing erlang, there’s no way for me to use that knowledge to improve whatsapp. The practical impact is nil. And the parts I look at, the client, isn’t written in erlang.
When I think “killer app” I usually think of some program or library which I’ll learn a new language to use. (Or a game console I’ll buy to play one game.) Whatsapp could be a case study, but not a killer app.
I would argue that erlangs Killer App is OTP. An industry proven framework for writing highly fault tolerant services. OTP is likely to be a large part of the reason WhatsApp chose Erlang in the first place.
That’s possible. It’s the main reason for a lot of companies and people that use it.
Erlang also has, you know, huge deployment in general telecoms. Also the Heroku load-balancers.
Everybody knows about the desktop environment revolution powered by Haskell’s killer app, xmonad. I think maybe there’s also a text editor?
You’re being facetious but Haskell’s “killer app” was its prominent position in academia as a research platform
Is that what killed Haskell? (~:
As an occasional contributor Yi the haskell text editor it has a lot of promise but I wouldn’t call it a killer app yet. :-)
I offer Bluespec for hardware design as Haskell’s killer app. It’s basically Haskell with syntax extensions that makes hardware design easy. Used in CHERI project.
Alternatively, Galois’s Ivory or Tower languages are DSL’s in Haskell for safer, embedded programming that output C code. Used in their high-integrity drone project. C that’s immune to certain problems when thrown together sounds like a potential, killer app. :)
Rust has (parts of) Firefox
It’s just a few components in a massive apps that isn’t Rust. Doesn’t count. It might be different if the whole thing was coded in Rust. There’s also Redox OS project that might make some headway.
By your reasoning both COBOL and MUMPS are goners…and I assure you that they are very, very much alive.
I’m convinced this is one of those things you have to age a little to appreciate. When you’re young, you run around like some kind of religious zealot. When you encounter the latest new shiny you say “THIS IS ALL!” and declare everything else rubbish or dead or whatever.
While there are some usage problems, overall I thoroughly agree with most of the points raised in the article.
Small perspectives cause this, too.
The “everything must be JS” rhetoric sort of self-perpetuates. It has to, in order to stay alive, and fend off the small, existential doubts that crop up as one gets more experience with computing.
I disagree a bit on this. I use COBOL as a reply to the “…is dead” discussions plenty. Yet, I think we should differentiate between what’s alive in legacy mode and what’s alive because people want it over other options for the value it brings. Most on COBOL are stuck due to cost and risk of a rewrite.
It looks like tools to support maintenance or transition of legacy apps in COBOL. The one exception is the GNU one whose FAQ implies at one point they like the language over others. Aside from MicroFocus, that is the most lively one I’ve seen in terms of effort and continuing maintenance.
I’m not going to bother replying since you’ve pre-ordained any response as being “feeble”. Any bit of digging by someone with an open mind would show this list to be well satisfied.
The one I’d say is true is the “one killer app” as Smalltalk has so many killer apps that it would be impossible to pick one.
If you’ve actually researched any of these, I think it’d be easy to label such an attempt as “feeble”.
/ your head \
What do you mean? Clearly, I do not understand metaphor.
“the point went over your head”
If you won’t elaborate, I will. I find it disingenuous to promote a language as “alive” when the ecosystem is a tarpit, and a handful of tepid success stories is the best that can be scraped together in its support.
the ecosystem is a tarpit, and a handful of tepid success stories is the best that can be scraped together in its support.
I just figured you asked for the metaphor, my bad. The point of the article is that however much a “tar pit” you think the ecosystem of smalltalk is, it’s still being used to solve problems, and by the author’s concept of how “alive” a language is, that’d make smalltalk very alive. Arguing pedantics kind of just misses the whole point that the article is trying to get across, that the continued impact and progression of understanding of programming and computation is the important effective goal of a language, while imo those other things you listed are all ingredients that help contribute to that net effect.
Now, now, folks, language flamewars are great, but how can we tell our children to be nice in class, if we aren’t?