Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Racket – Lisp beyond Clojure

slides.com

Post reply on HN
Print view View original

71–80 of 179 posts

Re: Racket – Lisp beyond Clojure

#71

Post by qwertyuiop924 »

lispm wrote: post #17
JohnStrange wrote: post #14

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

I came from python and take the opposite view: it's nice to be able to look at a call to a function, and at least have a reasonable clue at where it's going.

Re: Racket – Lisp beyond Clojure

#72

Post by greghendershott »

lispm wrote: post #17
JohnStrange wrote: post #14

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

It's not necessarily 1:1 file:module.

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

Re: Racket – Lisp beyond Clojure

#73

Post by qwertyuiop924 »

I'm not a fan of Racket, as I've made clear elsewhere. Its insistance on using as many paradigms as possible frustrates me, and while I like "batteries included" in general, I wish some things like contracts, custodians, OO system, etc. had been moved out to other libraries to make core easier to wrap your head around. I am also not a fan of syntax-case: it violates the macro abstraction, and is overly complex for what it does, IMHO.

In essence, I wished that core had picked a paradigm and stuck with it, instead of like 10 of them.

Practical or no, I'd take a simpler Scheme over Racket any day. Usually Chicken, which is quite practical, and has a lighting fast call/cc implementation (non-delimited, with delimited implemented in terms of call/cc by an external library, if you want it).

But just because I don't like it doesn't mean you won't: objectively, it's powerful, technically competent, and fairly well designed. It's just not to my tastes, any more than CL is, and so it looks like I'll have to wait until R7RS Large before I get a large lisp I like.

And yes, I said lisp, not scheme, because Scheme is a lisp, and also to annoy the people who say otherwise.

Re: Racket – Lisp beyond Clojure

#75

Post by mobystrip »

pjmlp wrote: post #25
616c wrote: post #22

Earlier quoted context omitted.

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 ?

Have you used Allegro? If you had you would notice their gui is single threaded. Segfaults often, and has no color syntax highlighting of any sort. Perhaps Lispworks would have been a better example.

Re: Racket – Lisp beyond Clojure

#76

Post by foldr »

greghendershott wrote: post #67
foldr wrote: post #51

Earlier quoted context omitted.

I thought the general consensus on call/cc now is that although it's very powerful in principle it's not such a great abstraction in practice. It's difficult to implement efficiently and abstractions created using it tend to be very brittle. See e.g.: http://okmij.org/ftp/continuations/against-callcc.html

Racket provides delimited continuations. The page you linked to is criticizing undelimited continuations -- including quoting Matthias Felleisen -- and contains a link to the following: http://okmij.org/ftp/continuations/undelimited.html#delim-vs...

Yes I know, but call/cc without any context generally refers to undelimited continuations. Delimited continuations use differently named primitives.

Re: Racket – Lisp beyond Clojure

#77

Post by shiro »

A kind of nitpick, but the use of dynamic-wind with custodian in the slides bothers me. Dynamic-wind shouldn't directly be used to ensure cleanup, since a continuation captured in the body may be invoked outside from dynamic-wind and the body restarts, even if resources are gone.

In the R5RS age, light users looked for try-catch construct in Scheme and could only find dynamic-wind and used it; but they're not the same. Dynamic-wind is a low-level construct that can be used to implement try-catch idiom and other stuff.

Now Scheme has guard, so it's better to use them to write cleanup stuff. It's a bit verbose, though (you have to write cleanup both in the handler and the end of body), so I personally wrote unwind-protect macro on top of it and am using it.

Re: Racket – Lisp beyond Clojure

#78

Post by DigitalJack »

jnordwick wrote: post #66

Unhappy with the current state of functional programming. I know I should't be. I have a lot of options. I went to school at UC Berkeley. My first language was Scheme. Then Elisp. CLOS was in the first few too. I really didn't learn C or C++ until second semester. A few months ago I had to pick up enough Scala to figure out what some code did in a project and I wasn't really happy with the language. I realize it is m…

I guess I don't understand what the big deal is with tail call optimization. Could someone give an example where it really shines and clojure's loop/recur just doesn't?

If you are looking to put time into a programming language that is interesting in and of itself, I'd suggest Haskell.

Re: Racket – Lisp beyond Clojure

#79

Post by sanderjd »

DigitalJack wrote: post #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…

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

Maybe this isn't the case for you, but for me, "myself in a year" fits nicely in the "other people" category, so I'm always asking myself: will I be happy or sad about this if I stumble upon it again while doing something totally different a year from now?

Re: Racket – Lisp beyond Clojure

#80

Post by Jach »

imagist wrote: post #39
junke wrote: post #20

Earlier quoted context omitted.

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…

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

I'll just leave two of my old comments here... https://news.ycombinator.com/item?id=10207199 and https://news.ycombinator.com/item?id=3423646

Short summary: I do think on HN it's reasonable to assume "Lisp" without further qualification to refer to the lisp family. The usefulness of the lisp family idea (which afaict is having sexps and maybe something like defmacro) is questionable. Among Lisp and lisp-family practitioners outside of HN and maybe even on HN itself (it'd be interesting to see a poll result) Lisp means Common Lisp, as it has basically since Common Lisp was created, and the distinction with other lisps usually made by saying things like "Clojure is a Lisp", that article "a" being important here to say x is a member of the y family and would be nice to have in the slide title.

I agree with your argument about common usage but I'm not sure what the common usage on HN really is and what's a vocal minority using it incorrectly until it becomes common. But we've already lost several wars like that, in the wider culture ('literally' for one..) and in tech (a recent one that bugs me being 'isomorphic' JavaScript) so it's probably best to sigh in resignation and maybe think/complain about the lisp/lisp family stuff once every few years at most. ;)

Post reply on HN