In which we plot an escape from the quagmire of equality (Clojure and Emacs)
technomancy.us
technomancy.us
> As it comes from a Scheme background, Guile provides
> the immutable data types we need.
Scheme does not provide any immutable data types beyond numbers or symbols, either. Procedures like `set-car!`, `vector-set!`, and `string-set!` all modify their operands. In fact, in R5RS, there's no real way to introduce truly disjoint types (you can, however, simulate them as in SRFI-9 which is being incorporated in R7RS), so it'll be a little difficult to even introduce new types let alone interoperable new types. > One of the Summer of Code projects for this year is
> to allow for pluggable backends in the ClojureScript
> compiler, with Lua as a proof of concept.
Compound data types in Lua are similarly mutable (perhaps even more so because mutation of tables is acceptable practice in Lua). There will be difficulties targeting ClojureScript to Lua, too. > Of course, with a compiler that targets Emacs Lisp,
> you can work around this by implementing your own
> immutable types. But this makes any form of interop
> much more cumbersome... you have to choose between
> getting equality right and seamless interop.
It's just a fact of life that when introducing a radically different paradigm to any language platform, interop is going to have seams.[EDIT - formatting]
I'll keep a close eye on the Lua ClojureScript backend as well; this should be interesting.
Given how much better Smalltalk was than Java and how much of a head start it had, it should have won. That it didn't is either a tragedy or a comedy.
Edit: Part of the issue was generational. Smalltalk predates open-source. So do APL and Lisp. The way people thought about commercial software before open-source was totally different. For example, it wasn't uncommon for vendors to demand a percentage of their users' revenue, something that seems absurd today. So these technologically advanced – still in many ways superior – languages were trapped for historical reasons in an obsolete economics.
(The only reason I can think of is that the IP is still being controlled by those who remain to this day, blind.)
--------- Smalltalk ---------
Squeak: http://www.squeak.org/
Pharo: http://www.pharo-project.org/
Amber: http://amber-lang.net/
---- Lisp ----
Racket: http://racket-lang.org/
Clisp: http://www.clisp.org/
SBCL: http://www.sbcl.org/
Clojure: http://clojure.org/
I have to say, as someone who primarily does C++ in Linux/Windows, Smalltalk and Lisp may not "fit in" enough for people to get over their hurdles. Just as an example, I've dabbled in Smalltalk and Lisp, but it always seemed kind of awkward how (at least Smalltalk) was in its own little cocoon (the images you mentioned) that you couldn't version control and didn't integrate well with pre-existing editors (eg, emacs). OTOH, the other day I was tasked with getting a Java program working; I've also dabbled in Java, but getting the program working and sorting things out (classpath, etc) wasn't that hard. Thankfully I had the source, and I could grep it, open it in vi, see that some paths were partially hardcoded and that whoever wrote it was using eclipse and didn't understand portable path separators, etc. In the end, it took me a couple hours, whereas I'm sure the same thing in Smalltalk or Lisp probably would have taken all day.
It's good to try radical new directions, but there is something to be said for at least having some hooks to fit into pre-existing environments; in particular being able to use libs from other languages (eg C => Python, Java => Scala, Clojure, etc) and working with entrenched DE's (including VCS's).
To be sure, familiarity plays a large part; but I think there are other significant factors beyond this. Like I mentioned, having an FFI (ironically, I first learned of that term from Lisp) to leverage pre-existing codebases is huge; being able to grep/diff/git is huge. I got back into Smalltalk through "Refactoring" and admired its elegance, liked how it was different - except for the images. In the meantime, persistence has been implemented in other languages, OS's and even IDE's, some implementations being more flexible while keeping the "everything is a file" concept.
I'll tell you one thing that keeps me hopeful and not completely giving up on Smalltalk is that with GNU Smalltalk, I can treat Smalltalk programs as scripts. For someone who does rapid iterative development by scripting in C/C++ (http://www.netfort.gr.jp/~dancer/software/binfmtc.html.en) being able to just type some code in and run it appeals to me. No images, no virtual machines, no (explicit) compilation, just type, save and run.
(See my other comment in the thread for a lengthier attempt at explaining.)
I actually disagree strongly with you there. Hackers are eager to find things that work better, regardless of their source. One example that springs to mind is the use, in 3D graphics programs, of an archaic math construct called the 'quaternion'. The quaternion was the loser in a long-ago war with 'vectors', but this did not stop hackers from using the idea with the most value.
Another more ready example (as evinced by the frequent posts on HN about it) is Emacs. It's an old editor. And yet it still has it's adherents, and new converts.
But I hear nothing about people making anything in smalltalk environments. Nothing. Not even toys. One would think that if the language/environment was so powerful and the software freely available, that we would have seen something built on it. Heck, erlang is pretty esoteric (especially to those who don't hang out around here) but someone built CouchDB on erlang (and then abandoned it, but that's another story :).
In summary, I think there might be something wrong with Smalltalk that has nothing to do with economics.
The web is where it currently excels. Hence the prominence of Seaside, and similar frameworks.
Well there you have it: a non-economic reason it failed.
Compared with CouchDB (which is not even that famous itself) all those are marginal at best, with the possible exception of Seaside, and then again that's a framework. Where's the famous site built with it, like, say, Facebook was built in PHP and Twitter in Ruby/Rails(Scala), etc?
A programming language has a window of opportunity to gain mindshare while it's new. Once that window passes, the odds are hugely against it. It's true there are a few technical factors, for example that older implementations lack the infrastructure to work with newer technologies, but such things can be improved. The dominant factor, the real barrier, is social psychology. This is obscured by our tendency to retrofit plausible-sounding reasons to our choices ("X is slow" or "it doesn't have libraries" or whatever).
This does suggest a strategy for reviving an old language: rebranding.
First, you need a new implementation. Trying to convince people to use the old one is like trying to get them to watch an old movie. George Lucas didn't promote Kurosawa, he made Star Wars. Second, there has to be a hook, something to convince us that this really is a new language, modern and with the times. So, light sabers. That's critical for opening a fresh window of opportunity instead of getting pegged to the old, long-closed one. It needn't be the most important thing, but it can't be fake either; it must be real enough or no one will take the new brand seriously. Without a convincing reason for why we weren't using X before, the new window will never open. Once it opens, then and only then do the beauty and power of X get their chance to bond with the user. In the Star Wars analogy, that would be the characters and the story – the deeper things that came from Kurosawa and ultimately from ancient archetypes. They'd never have gotten the chance to kick in if Star Wars hadn't got the audience in the theater. Once they did, though, then you had Star Wars fans for life.
With Clojure, the hook was Java libraries. Actually, there were three hooks. The others were concurrency and sequences. But Java libraries is the one that worked. And now there's a modern Lisp again!
If you're pursuing a programming language/environment because it's fashionable, you're doing it wrong.
Yes, if we ignore all the other explanations, like, say, network effects. You don't get to chose a programming language for it's merits as a language alone. Tools, implementations, contributors, availability of programmers to hire, available documentation, available projects and libs to build upon, rate of innovations (depended on people working on compilers for the language), core library, etc are far more important.
>If you're pursuing a programming language/environment because it's fashionable, you're doing it wrong.
And if you're pursuing a programming language/environment because the language is the best (in itself), you're also doing it wrong. You have to take the whole ecosystem and community in mind.
The niche popularity of Smalltalk (and other key languages) reveals more about the mentality of people comprising the computing ecosystem than it does the languages.
I disagree. If it reveals anything is that the language itself is small part of the equation. People avoid Smalltalk for historical reasons, not because of their mentality. What historical reasons?
1) Smalltalk was slow at the time it had to catch on, and cpus/memories weren't up to par. C++ gave far better results with the same equipment.
2) Smalltalk vendors charged an arm and a leg.
3) Smalltalk image environment wasn't easily integrated with other workflows.
4) Smalltalk vendors were in competition for the market, instead of trying to grow it and have a smaller slice of a much larger pie.
5) The UIs were horrible.
1) I can't easily find many other code written with it. 2) I can't easily find answers when I get stuck with it. 3) I can't easily find other programmers that use it. 4) I can't easily find quality tools for it. 5) I can't easily find books for it. 6) Projects made with it have few contributors and are mostly in a limbo state.
2) http://lists.squeakfoundation.org/mailman/listinfo/beginners
3) http://www.pharo-project.org/community
4) the 'quality tools' are generally acknowledged to comprise the finest IDE in existence. Just fire up a Smalltalk image and see for yourself.
5) http://stephane.ducasse.free.fr/FreeBooks.html
Finally, while many projects are buzzing with activity, there's certainly a need for an influx of new users.
And you very much missed the whole point. I know all of those resources, I've programmed in Smalltalk in the past, as I have on many other languages (4-5 of them professionally). I also follow Kays projects of late.
All of those you list are MARGINAL at best (--ten+ year old books and projects that limbo around). I mean, "Many projects buzzing with activity"? There are probably more HAM radio enthusiasts that people involved in those projects.
Compare Smalltalk "activity" with the activity behind C, C++ Objective-C, Javascript, Python, Ruby, .NET, Java, heck, even Scala.
It's not even close.
Some elementary investigation would reveal: 1) http://squeaksource.com/ 2) http://lists.squeakfoundation.org/mailman/listinfo/beginners 3) http://www.pharo-project.org/community 4) the 'quality tools' are generally acknowledged to comprise the finest IDE in existence. Just fire up a Smalltalk image and see for yourself. 5) http://stephane.ducasse.free.fr/FreeBooks.html Finally, while many projects are buzzing with activity, there's certainly a need for an influx of new users.