This is really interesting as HotSpot (OpenJDK, Oracle Java) has its origin in a Smalltalk VM (Strong Talk), while Eclipse started its life as a Smalltalk IDE. Glad to see this come full circle.
Hi There,
I'm the creator and maintainer of Redline.st
This project has stalled right now because of other commitments.
However, should there be renewed interested I would continue its development.
- James.
Smalltalk and Racket are two languages I recomend to anyone wanting to learn a new language just for self-education sake. Now running Smalltalk on JVM I can't think why I would go down that road.
I'm not the parent, but "lisps" covers a very large part of the language design space, including languages which have almost nothing in common with each other (e.g. Dylan doesn't use s-expressions, Carp uses static types and manual memory management, etc.).
I would narrow this down to the "major" Lisp languages/standards, which pretty much means Common Lisp, Clojure, Scheme and Racket.
Out of these Scheme has a history of use for teaching (e.g. SICP) and Racket has a history of use in research (Racket used to be called Programming Language Theory Scheme, AKA PLT Scheme). Personally I'd recommend those wanting to learn "a lisp" to try a Scheme implementation, and Racket is a particularly good Scheme implementation (with lots of other good stuff built on top too, like support for creating custom languages).
1) It was designed to teach and the "How to Design Programs 2md Edition" is the best book I have ever gone through for programming. (Also the most dense).
2) Racket is usable. I am now using Racket as a first choice. It is a joy to use. I can make my program and make it an executable in one line of code. So simple and its strongest reason to use the language.
3) The mind trust. It has the who's who of the academic Scheme and Lisp world. It is also the most practical. Racket is special because it is so well thought out.
4) It is plain old fun. It reminded me of when I first learned Python but with so much easier ways to share your program.
Lots of people who hack on and hack with Racket (including me) use Greg Hendershott's racket-mode [0] in Emacs. It's good. Greg also wrote a blog post about it recently [1] which might be of interest.
Weren't you talking about the IDE? I feel like this is shifting the goal posts. Which IDE one uses is at most weakly connected to the toolkit one uses for GUI work.
The Racket IDE uses Racket's UI toolkit. As such the IDE an example how bad the UI toolkit is. Given that I'd write UI code on a Mac using a Mac-based IDE - both suck. The IDE look&feel is directly influenced by the UI toolkit.
I'd be delighted to discover new (as in new-to-me), high-quality IDEs and GUI toolkits, especially those drawing on Smalltalk or CLIM heritage, if you have any recommendations. Which Lisp IDEs do you enjoy using?
I've started many years ago with programming on the Mac using MacScheme - that was cool. Then Macintosh Common Lisp, which was really really great and later developed and sold by Apple for a few years - that was used for a lot of UI stuff. The later kind-of successor Clozure CL is more limited - it gets some basics right, but the IDE is limited. Nowadays I'm using LispWorks - which is commercial&expensive - but which has useful IDE and it gets many things right. It has also some CLIM influence in its CAPI UI toolkit.
For example this in Racket 7 in the listener:
(define (foo i) (if (zero? i) i (begin (write i) (foo (- i 1)))))
(foo 10000)
Takes around 20 seconds on my Macbook.
This in the LispWorks 7.1.1 listener on the same Macbook:
(compile (defun foo (i) (if (zerop i) i (progn (write i) (foo (- i 1))))))
(foo 10000)
Thanks for the pointers. Is LispWorks the only currently-available IDE you'd recommend?
The example you've given runs very quickly in Racket; it completes in some vanishingly small fraction of a second. Perhaps you were running it in DrRacket? If you're interested in any kind of performance in Racket, use the console REPL rather than DrRacket. The IDE instruments the code quite heavily, slowing it down rather a lot.
[ETA: For me, on a Linux machine, it takes 13ms in a terminal, and 227ms in DrRacket. I wonder why you were seeing the code run 100x slower than that? Perhaps it's a DrRacket-on-OSX thing.]
[ETA 2: There's clearly some buffering going on. Display of the text is the slowest part in DrRacket, and 227ms isn't enough time to plausibly include the text-rendering, so measuring this stuff is basically just hard. The terminal, unsurprisingly, is better at printing text quickly :-) ]
Well, I once worked at a games company that used Java. One of my colleagues coded up a small application that could run 'live' and provide detailed information about running code. The kind of stuff that I, as a Smalltalker new to the Java ecosystem, assumed was normal.
This is when I realized that a proper Smalltalk running on the JVM would have revolutionized development in this company. Imagine developing your games in a 'live' environment, without all the lengthy recompiles and elusive errors. In other words, game development within the game itself. Much smoother, less stress, and a 'finger on the pulse' of running code.
24 comments
[ 2.0 ms ] story [ 55.6 ms ] threadI would narrow this down to the "major" Lisp languages/standards, which pretty much means Common Lisp, Clojure, Scheme and Racket.
Out of these Scheme has a history of use for teaching (e.g. SICP) and Racket has a history of use in research (Racket used to be called Programming Language Theory Scheme, AKA PLT Scheme). Personally I'd recommend those wanting to learn "a lisp" to try a Scheme implementation, and Racket is a particularly good Scheme implementation (with lots of other good stuff built on top too, like support for creating custom languages).
1) It was designed to teach and the "How to Design Programs 2md Edition" is the best book I have ever gone through for programming. (Also the most dense).
2) Racket is usable. I am now using Racket as a first choice. It is a joy to use. I can make my program and make it an executable in one line of code. So simple and its strongest reason to use the language.
3) The mind trust. It has the who's who of the academic Scheme and Lisp world. It is also the most practical. Racket is special because it is so well thought out.
4) It is plain old fun. It reminded me of when I first learned Python but with so much easier ways to share your program.
Many Lisp implementations do that - even native.
Personally I think the Racket IDE sucks. Big. It's slow and buggy. On my Mac it is barely usable. The interactive response is extremely poor.
[0] https://github.com/greghendershott/racket-mode
[1] https://www.greghendershott.com/2018/10/racket-mode.html
Neither is attractive, especially since both UIs suck.
For example this in Racket 7 in the listener:
Takes around 20 seconds on my Macbook.This in the LispWorks 7.1.1 listener on the same Macbook:
it runs in less than 1 second.The example you've given runs very quickly in Racket; it completes in some vanishingly small fraction of a second. Perhaps you were running it in DrRacket? If you're interested in any kind of performance in Racket, use the console REPL rather than DrRacket. The IDE instruments the code quite heavily, slowing it down rather a lot.
[ETA: For me, on a Linux machine, it takes 13ms in a terminal, and 227ms in DrRacket. I wonder why you were seeing the code run 100x slower than that? Perhaps it's a DrRacket-on-OSX thing.]
[ETA 2: There's clearly some buffering going on. Display of the text is the slowest part in DrRacket, and 227ms isn't enough time to plausibly include the text-rendering, so measuring this stuff is basically just hard. The terminal, unsurprisingly, is better at printing text quickly :-) ]
For some stuff Clozure CL is useful enough. An interesting Lisp IDE for music composition was developed with it:
https://opusmodus.com
Allegro CL would be a good option on Windows/Linux - on Mac it is not native. But it's also commercial and expensive.
> Perhaps you were running it in DrRacket
yes, and when you resize the window the program stops while resizing...
I use VS Code.
This is when I realized that a proper Smalltalk running on the JVM would have revolutionized development in this company. Imagine developing your games in a 'live' environment, without all the lengthy recompiles and elusive errors. In other words, game development within the game itself. Much smoother, less stress, and a 'finger on the pulse' of running code.