31–40 of 179 posts
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!!!)
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.
Use the ? key for the help and other useful keybindings.
Earlier quoted context omitted.
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 "modu…
"The whatever subjective suckage they introduce is their own. If you want racket-style modules, hack them up." 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.
Earlier quoted context omitted.
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.
Can you be more specific? In particular, about stuff you'd consider to be lacking in Clojure?
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.
I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Making a DSL lets me construct a language to express my program that meshes with the way I think. Unfortunately, we all think differently, and what is intuitive and friendly for me is hostile and awkward for others. While reading someone else's program that…
While reading someone else's program that uses a DSL may be superficially easy, but the minute you try to get under the surface, you're left scrambling to understand what a given term or idea meant to the author. There is no language definition to rely on for common understanding. I have generally found that this is the same problem as with user-defined functions, and it has the same solution: programmers need to doc…
Earlier quoted context omitted.
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 "modu…
"The whatever subjective suckage they introduce is their own. If you want racket-style modules, hack them up." 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?
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.
Earlier quoted context omitted.
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 sho…
This is like saying that referring to dialects of English as "dialects" is doing them a disservice. If you are studying them, it is, if you are learning English as a second language, it is not.
If you look close enough, the differences are huge (after all, that's why someone created a specific lisp dialect in first place), but from a distance, they are all still pretty similar.
And finally, I rarely witnessed any discussion about those differences among lisp programmers, they were merely referred to when discussion how to implement something: "X-style Y", where Y is some CS-concept and X is some lisp dialect tailored to Y - and implementing anything in your preferred dialect is usually "trivial", though not necessarily performing as well as the implementation in some dialect tailored to the task.
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!!!)
I have been trying to get into the whole Lisp paradigm for 1-2 years now. I own Realm of Racket, amongst a collection of Lisp books. 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…
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.
Earlier quoted context omitted.
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 "modu…
> 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...
Earlier quoted context omitted.
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 sho…
Sadly, language is determined by usage, which only incidentally correlates to usefulness. And critically, there's a feedback loop here: a word is only useful as it's used, because otherwise people don't know what it means, and you've failed to communicate your intent. "Lisp" might hypothetically be more useful if it meant "Common Lisp", but it's not useful for meaning "Common Lisp" (at least not on Hacker News) because when you say "Lisp" people assume you're talking about all the languages with the parentheses, and you've failed to communicate.
> 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.
Right, the terminology commonly used for that is "C-family languages", not "C".
> Go is "a compiled, statically typed language in the tradition of Algol and C".
Note how they don't say "Go is a C".
> 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.
Yes, but in a context not centered around Common Lisp, people use "Lisp" to refer to all these languages. You can argue whether that's good or bad, but you're not able to change it.
> 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?
Parentheses, macros, some functional programming constructs.
Look, I'm not saying the terminology is ideal. I'm saying that, in this context, "Lisp" doesn't mean what you and I want it to mean, and trying to change that will a) fail to communicate and b) fail to change the meaning of the word in this context.
I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Making a DSL lets me construct a language to express my program that meshes with the way I think. Unfortunately, we all think differently, and what is intuitive and friendly for me is hostile and awkward for others. While reading someone else's program that…
While reading someone else's program that uses a DSL may be superficially easy, but the minute you try to get under the surface, you're left scrambling to understand what a given term or idea meant to the author. There is no language definition to rely on for common understanding. I have generally found that this is the same problem as with user-defined functions, and it has the same solution: programmers need to doc…
1. Badly designed functions can do less design damage per-function than badly designed languages per construct, but user-defined functions tend to have much higher volume than both language constructs and their usages.
2. Powerful techniques, including DSLs, lead to denser code. Denser code takes more time to read per unit of code. Total reading time may be either more or less, but the cold start ramp is always much steeper.
Combined, this means that people are less sensitive to suffering the complexity caused by user-defined functions vs DSLs/etc because that complexity has lower intensity spread out over a greater area. I'll refrain from any further value judgement on this state of affairs; just wanted to share some more insights in to the tradeoffs.