Let's try with other languages: Rust - C beyond Go See any problem?
Lisp is a language family. It'd be more like "F#: ML beyond SML" or something.
Racket – Lisp beyond Clojure
11–20 of 179 posts
Re: Racket – Lisp beyond Clojure
#12I'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!!!)
UI is weird. Left/right goes between main topics, up/down goes through the slides on that topic. So if you just go right, right, right, you're only seeing the headings.
Re: Racket – Lisp beyond Clojure
#13Earlier quoted context omitted.
I'm not so sure anymore. Scheme is at least taught in schools and isn't uncommon as a scripting language. Where are you likely to run into Common Lisp?
For me it was the Practical Common Lisp book.
So the main use case of the language is the handbook of that language? :)
Re: Racket – Lisp beyond Clojure
#14I'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!!!)
I tried to get more into CL because of implementations like SBCL and because it's standardized, but modularization/package management turned out to be too verbose and archaic for my taste.
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.
Re: Racket – Lisp beyond Clojure
#15Let's try with other languages: Rust - C beyond Go See any problem?
Lisp is a family of languages that includes Racket and Clojure.
C is a language, not a family of languages that includes Rust and Go.
The Lisp family of languages also contains Common Lisp. In some contexts, it's reasonable to assume "Lisp" means "Common Lisp". This is not one of those contexts.
Re: Racket – Lisp beyond Clojure
#16I'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!!!)
TBH, almost any Lisp is beyond Clojure.
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.
Re: Racket – Lisp beyond Clojure
#17I'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!!!)
I tried to get more into CL because of implementations like SBCL and because it's standardized, but modularization/package management turned out to be too verbose and archaic for my taste. 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 olde…
That's not very Lisp-like.
Personally I really don't like it when files are modules. For me that's orthogonal.
Re: Racket – Lisp beyond Clojure
#18Earlier quoted context omitted.
I tried to get more into CL because of implementations like SBCL and because it's standardized, but modularization/package management turned out to be too verbose and archaic for my taste. 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 olde…
That's not very Lisp-like. Personally I really don't like it when files are modules. For me that's orthogonal.
In Common Lisp, files are in fact "modules" (or "compilation units") also. To treat multiple files as one unit, you have to use the with-compilation-unit macro:
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.
Re: Racket – Lisp beyond Clojure
#19Let's try with other languages: Rust - C beyond Go See any problem?
C isn't a big family of languages, it is very narrow family. Rust and Go are not in that family. A proper analogy requires some close dialectal ties, for instance:
ObjC - C beyond C++
Rust - "Von Neumann Model Algol-Like Blub Programming" beyond Go
Re: Racket – Lisp beyond Clojure
#20Let's try with other languages: Rust - C beyond Go See any problem?
Lisp is a family of languages that includes Racket and Clojure. C is a language, not a family of languages that includes Rust and Go. The Lisp family of languages also contains Common Lisp. In some contexts, it's reasonable to assume "Lisp" means "Common Lisp". This is not one of those contexts.
Newcomers are always confused by the distinction, this doesn't help at all to put them in the same big bag. This classification is not wrong, but mostly useless when you see how the different "dialects" evolved (they are grown-up languages, nowadays).
> C is a language, not a family of languages that includes Rust and Go.
But Rust and Go are constantly compared to C. We always talk about C-like languages. Maybe I should have said "Algol" instead, but there is a family of languages rooted at "C", and we don't call it the C family.
Go is "a compiled, statically typed language in the tradition of Algol and C". "The syntax of Rust is similar to C and C++", but "Rust is semantically very different from C and C++.[citation needed]" (wikipedia).
Likewise, Scheme is semantically very different from Common Lisp. And Racket is not considered as a Scheme, even though it is related to it. You can't copy-paste any Typed-Racket expression and run it with ChezScheme.
So, yes, they all belong to the same proto-language family, but constantly referring to them as a unique family is doing a disservice to each of them.
Take Clojure for example: the wikipedia page says that it is inspired by C++, C#, Common Lisp, Erlang, Haskell, Mathematica, ML, Prolog, Scheme, Java, Racket and Ruby. There are plenty of influences that goes into a language, why not talk about the other ones? parentheses?