Live data from Hacker News

Racket – Lisp beyond Clojure

slides.com

21–30 of 179 posts

Re: Racket – Lisp beyond Clojure

#21

I've recently started porting some bash scripts over to Racket, using https://docs.racket-lang.org/shell-pipeline and it's been pretty straightforward and painless so far!

Are there (m)any advantages to doing this? I've seen a number of shell-interop modules for various languages but they all appear to add an extra layer that reduces portability or ease of maintenance.

> Are there (m)any advantages to doing this?

[trigger warning: cynicism distilled from 15+ years of bitter tears]

More fun and better job security for the current maintainer. The former because one hacks away in the preferred language, the latter because one cannot be replaced easily by some unix geek unless s/he happens to speak the same language fluently.

One can chose from various implementations in various languages (eg: psh and scsh) but hacking your own is easy:

* Just re-implement the basic unix tools and shell semantics and invent some nifty convenience syntax and features along the way.

* Either don't document at all or document everything with at least 2 pages aimed at people who have never used a computer before. Both ways will prevent the only ones who could replace you from even looking at your "shell in X".

* Never ever do this in a typed language, write a ton of unit-, functional- and integration tests to make up for that - of course all of them completely undocumented.

* On top of your creation, invent a fragile "shell syntax like" layer to make adoption easier.

* Under no circumstances create some new abstraction layer that goes beyond shell semantics that brings something substantial to the table and is well documented.

* Enjoy the time saved because you don't have to "man $tool" anymore, it's all your code anway.

* Under no circumstances ever write in pure posix sh again - the realization that with all the stuff you've learned along the way posix sh covers 99% of the use-cases in a more expressive way will be crushing.

Re: Racket – Lisp beyond Clojure

#22

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 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.

Re: Racket – Lisp beyond Clojure

#23

I've recently started porting some bash scripts over to Racket, using https://docs.racket-lang.org/shell-pipeline and it's been pretty straightforward and painless so far!

Link to your code? I would be very interested to see this thus far.

I have looked at avesh (CL) and xonsh (Python) because I think the future of fun *nix tooling is like libraries that implement a bash layer to like gradually move code away from shell languages. This is the sweet spot I would want in my life.

Re: Racket – Lisp beyond Clojure

#24
post #17

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 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?

Re: Racket – Lisp beyond Clojure

#25
post #22

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…

> Racket is all the promise of developer-centric power tooling that puts Common Lisp to shame.

Have you ever used a commercial Common Lisp like Allegro ?

Re: Racket – Lisp beyond Clojure

#26
post #16

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!!!)

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?

Re: Racket – Lisp beyond Clojure

#27
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 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.

There are exceptions naturally.

I know a lot of people will disagree, and that's fine of course. It's opinions all the way down.

Re: Racket – Lisp beyond Clojure

#28

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 document their code.

Re: Racket – Lisp beyond Clojure

#29
This is addressing a question I'm interested in, but on first read I'm struggling to see the value that's being presented here.

- "parameterize" is great, but seems exactly the same as Clojure's "binding" on a dynamic variable. [Edit: modulo being "sticky" with regard to continuations... but Clojure doesn't have continuations, so it's a pretty subtle difference.]

- Reader macros are an interesting feature, but do move away from the syntactic regularity of LISP -- and were, AFAIK, explicitly rejected in Clojure

- Custodians are kind-of interesting -- but I ended up having to do some Googling [1] to find out exactly what they do...

Is there anywhere else I should be looking for a more systematic Racket/Clojure comparison?

[1] - https://docs.racket-lang.org/reference/eval-model.html#%28pa...

Re: Racket – Lisp beyond Clojure

#30
post #22

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…

Racket isn't anywhere near close to what CL offers.

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.

Post reply on HN