I'd think Common Lisp is the Lisp beyond Clojure.
Also, I just see slides that have (googleable) terms, is there a recording of this presentation?
EDIT: see mkozlows' comment (THANKS!!!)
Also, I just see slides that have (googleable) terms, is there a recording of this presentation?
EDIT: see mkozlows' comment (THANKS!!!)
Racket is all the promise of developer-centric power tooling that puts Common Lisp to shame.
I recommend you watch one of the core devs, Matt Flath, build a a hygenic macro expander.
https://www.youtube.com/watch?v=Or_yKiI3Ha4
Notice how his talk, likely written in its own documentation language Scribble, shows demos of DrRacket. I am more of an emacs guy, but do you see the interactive colorized debugger pointing out variable binding and flow control? That is the only thing that I have seen in the Lisp world that takes SLIME and laughs at its dogged simplicity.
Also, as you watch this talk, observe how he takes the complexity of something I am still certain I cannot do, build a macro system (let alone understand macros others write), and boils it down to the essence with the color-coded schematic to match his environment and visualize his thought process. I dare say Rich Hickey et al would be impressed, tipping the hat to the Simple or Easy talk he is famous for.
If I have bored you at this point, you will probably not check out Rackjure. Someone basically implemented a language subset in Racket of Clojure. So it is safe to say you can subsume Clojure with Racket.
I know we are all smug Lisp weenies, but the whole Brown/NEU PLT group who works on Racket deserve serious praise. I listen to all the core devs and watch their talks, because they push the boundaries of what a good computer scientist is.
They just happened to choose Scheme/Lisp to make me feel dumb. Watch them ditch it and go for Haskell. We will all be sorry then.
Have you ever used a commercial Common Lisp like Allegro ?
Only natural hobbyists overlook this. But, yes, LispWorks and Allegro are very powerful environments. Comparing AllegroCache to Hibernate might be fun for newcomers too. Haha.
Even Macintosh Common Lisp would already have been a good experience.
http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...
MACL had technically nothing to do with Franz' Allegro CL.
Ahmon Dancy talked about his experience doing DB programming for Allegro and they sound, as a group and a generalization, super competent from this talk, so much so I would love to have a reason as a cheap wannabe to use their graph DB.
Your comments make me think that you've never used CL/SLIME extensively.
CL and SLIME are geared for __interactive image-based development__. The DrRacket IDE makes you jump through hoops to get but a tiny subset of that interactivity [last I remember, the Racket devs themselves said publicly that interactive development is not a priority to them].
I see Racket as an interesting experiment with lots of applications in academia but compared to CL, it's not anywhere near as pragmatic or capable. To believe otherwise you're simply deluding yourself.
Likewise, Geiser is a sort-of capable mode for most of the other more prominent Schemes; though it is not quite as elegant or polished as Cider.
Don't get me wrong, Clojure is an amazing tool. While it addresses a very specific use case (functional programming on the JVM) that use case is common enough that it's a very useful tool. But when compared to other Lisps in a context where non-JVM toolsets are acceptable, Clojure leaves a lot to be desired.
Clojure is ok if all you're doing is based on the JVM. If that's not the case, then it simply doesn't exist.
[0] https://nakkaya.com/2009/11/16/java-native-access-from-cloju...
Once upon a time, there was a serious continuations-on-the-JVM proposal, but it fizzled. Rather sad.
Fixnums would also help Clojure.
http://okmij.org/ftp/continuations/undelimited.html#delim-vs...
Maybe I don't understand what you mean. I also don't see why a uniform cell structure would be preferable?
Scheme:
(define x (cons 'a (cons 'b '())))
;> (a b)
(define y (cons 'a 'b))
;> (a . b)
(cdr x)
;> (b)
(cdr y)
;> b
(eq x y)
;> #f
As for why a uniform cell structure is preferable, it's a preference thing, but I feel it makes dealing with lists and other cons-based structure (mostly lists, but you get the occaisional alist or plist or tree in there too) much nicer.
Use the ? key for the help and other useful keybindings.
In Racket, by default a file creates a module, I import things, export stuff and done. That's really very handy, because I hate fiddling around with package declarations and paths -- these are a pain in the ass in almost every older language.
Personally I really don't like it when files are modules. For me that's orthogonal.
http://clhs.lisp.se/Body/m_w_comp.htm
The packaging systems people use nowadays over CL are not a part of CL. The whatever subjective suckage they introduce is their own. If you want racket-style modules, hack them up.
The grandparent's observation that "modularization/package management turned out to be too verbose and archaic for my taste" is very ironic --- in particular, the "archaic" part. ASDF is from around the turn of the century (the 21st that is).
The big hurdle in CL modularization is something very trivial: the fact that a file cannot refer to neighboring files easily by a short path. There is no
(load "foo")
This steers package management toward the external mode, whereby some definition exists outside of all the files and handles their inter-dependencies and the manner of actually locating the groups of files.
I fixed this in TXR Lisp, and so simple modularization is a cinch! You load some main file, and that just does (load "foo") (load "bar") ... to load its related files, no matter where they have been located.
I made load a macro, and that macro accesses the source file location at macro-expansion time, imbuing it into the resulting form that actually does the loading when evaluated. If the load path is relative, then the caller's path is used to resolve it, rather than the current working directory.
I don't think it really makes sense to try to roll your own module system? I mean, the whole point is to be able to easily share code with the community, right?
If you want racket-style modules you can also have them by implementing them.
> To be fair this seems like a pretty common mindset in CL-land.
My Lisp Machine has around 60000 functions, and I have only written a tiny fraction of them... Strange. If nobody else has written them, where are they coming from?
Obviously Fare Rideau thought it was a good idea when he started hacking on ASDF. He could just have used Defsystem or whatever. It's very popular now, but its name stands for "another system definition facility" for Lisp!
If you don't like anything, roll your own.
Sharing with the community isn't the entire point of a module system; it's also to internally organize the software you're working on, whether you're just one hacker or a team of one hundred. Niklaus Wirth's Modula-2 language has a module system, and so does Ada. The concept of sharing modules with the community didn't even exist.
A module system as a hub for sharing is a relatively new thing: it's a fusion of the ideas from open source OS distro package management and language modules.
> The packaging systems people use nowadays over CL are not a part of CL
Packaging systems were never a part of CL.
> The big hurdle in CL modularization is something very trivial: the fact that a file cannot refer to neighboring files easily by a short path. There is no
(load (merge-pathnames "test1" *load-pathname*))
> This steers package management toward the external mode, whereby some definition exists outside of all the files and handles their inter-dependencies and the manner of actually locating the groups of files.
This is the way how to do it.
> I fixed this in TXR Lisp
Oh no..., well there have been zillions of similar attempts...
`#lang foo ....` in name.rkt is (in part) a shorthand for `(module name foo ....)`.
A single Racket file can have 1 or more modules.
Each module can also have sub-modules.
Modules generalize runtime vs. compile-time to many kinds of time, including but not limited to "test time", "doc time", etc. Also they enable reproducible compiles by clarifying what "compile-time" actually means relative to other modules. It's more than "paste these s-expressions at the top-level prompt and auto-prefix some names."
Racket has a wonderful module system and sometimes I miss that in Clojure, although I enjoy Clojure very much in other respects.