Live data from Hacker News

Racket – Lisp beyond Clojure

slides.com

161–170 of 179 posts

Re: Racket – Lisp beyond Clojure

#161
post #143

Earlier quoted context omitted.

I don't see why you can't make those out of the data structures provided - or even the Clojure conses?

Well, it's nice to have a uniform cell structure, and you can't make them out Clojure conses, because Clojure conses don't really have a cdr, not as such, as Clojure's cdr cannot contain arbitrary data.

Can't it? This seems to work just fine: (cons :a (cons '[x] (cons {:foo :bar} #{:x :y}))) and cljs.user=> (rest (cons :a (cons '[x] (cons {:foo :bar} #{:x :y})))) ;=> ([x] {:foo :bar} :x :y)

Maybe I don't understand what you mean. I also don't see why a uniform cell structure would be preferable?

Re: Racket – Lisp beyond Clojure

#162
post #140

Earlier quoted context omitted.

Straw man. When was the last time you had to check the documentation for the parameter evaluation strategy of a C function call? I don't think it is a controversial statement than a badly designed macro can do more damage than a badly designed function. I believe that this is true, even normalizing for bad macro systems. This is not a statement against macros, so much as it is a statement to consider when making trad…

It is controversial. The GETS function is probably responsible for a huge number of security breaches with a cost possibly ranging into the billions of dollars (there's no way to really know). What would you cite as a comparable example of a badly designed macro?

Part of the reason gets() has been such a disaster is that people use it.

Re: Racket – Lisp beyond Clojure

#163
post #161

Earlier quoted context omitted.

Well, it's nice to have a uniform cell structure, and you can't make them out Clojure conses, because Clojure conses don't really have a cdr, not as such, as Clojure's cdr cannot contain arbitrary data.

Can't it? This seems to work just fine: (cons :a (cons '[x] (cons {:foo :bar} #{:x :y}))) and cljs.user=> (rest (cons :a (cons '[x] (cons {:foo :bar} #{:x :y})))) ;=> ([x] {:foo :bar} :x :y) Maybe I don't understand what you mean. I also don't see why a uniform cell structure would be preferable?

The result you got isn't actually what you'd get with proper cons cells. With real conses, you wouldn't get a list, you'd get an improper list, or a pair: i.e:

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
If clojure doesn't behave like that, that it's not using real conses.

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.

Re: Racket – Lisp beyond Clojure

#164
post #159

Earlier quoted context omitted.

That was pretty interesting. Especially that the Mac CL survived so long in about the same form. The one thing that confused me was Apple acquiring "Allegro" Common LISP. That's name of Franz's product. History of Franz says nothing about Apple. I'm assuming they're different products with the same name just to trip us archaeologists up?

Coral Common Lisp was once renamed 'Macintosh Allegro Common Lisp', because Coral went into a marketing agreement with Franz Inc. Apple later bought Coral and its products, and published MACL then as Macintosh Common Lisp (MCL). MACL had technically nothing to do with Franz' Allegro CL.

Now that makes sense. I just couldnt see one not saying something about other with same name. Tks for the tip.

Re: Racket – Lisp beyond Clojure

#165
post #158

Earlier quoted context omitted.

> realizing McCarthy's ideals--rather Scheme's more academic approach has caused it to compromise less on McCarthy's vision. What were those 'ideals'? What was that vision? > even improving on McCarthy's original Lisp Common Lisp improved the original Lisp, too. It vastly expanded into the areas which were interesting for McCarthy: AI programming. Common Lisp was the base for thousands of research & development proje…

> What were those 'ideals'? What was that vision? I don't know that. > That was McCarthy's vision: a tool for AI research. You don't know that. > No, Scheme went away from the idealized Lisp. -> R6RS. Neat! I'm glad we cleared that up. EDIT: Okay, maybe "You don't know that" is a bit strongly-worded; there's no doubt that that was part of McCarthy's vision, but there's a great more to Lisp than that, and notably, Sch…

> You don't know that.

Sure we know what McCarthy developed Lisp for: as a tool for AI research. It's already mentioned in the very first paragraph of the 1960 paper on Lisp.

Sure there are several Lisp dialects and a bunch of derived languages, like Scheme.

> Or put more tersely, I don't car.

Yes, sure. car and cdr.

Re: Racket – Lisp beyond Clojure

#166

I need types. But Racket has the world's greatest macro system and everybody should imitate it, Period.

Have you tried Typed Racket? https://docs.racket-lang.org/ts-guide/

Somebody always asks :).

1) I want my libraries to be typed all the way down.

2) Improving the implementation of typed racket is harder/less likely than fixing the macro systems of Rust and Haskell.

3) Network effects of those two languages.

Re: Racket – Lisp beyond Clojure

#167
post #25
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 ?

No, sadly I have not. But I am very interested if I could afford such things and this was not a hobby.

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.

https://www.youtube.com/watch?v=S7nEZ3TuFpA

Re: Racket – Lisp beyond Clojure

#168
post #25
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 ?

What would be some of the things you consider powerful in the Allegro Lisp?

Re: Racket – Lisp beyond Clojure

#169
post #25

Earlier quoted context omitted.

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

We cant entirely blame them: those cost significant money while mainstream stuff usually has free IDE's that are good without limitations. Allegro even mentioned royalties last time I looked at them. Royalties!? 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.

Lispworks is really nice. But I find the Slime integration with emacs works fantastic when you need to support lispworks/allegro/ccl/sbcl with the same interface.

Re: Racket – Lisp beyond Clojure

#170
post #139

Earlier quoted context omitted.

An article that would title "Lisp beyond Clojure" would indeed talk about the Lisp family of languages. What is a very bad in that title is that it focuses on Racket, just as if the title was: "Racket - this is how Lisp looks like beyond Clojure" . And that is the main problem I have with the title. The ideal title would be IMO "What could Clojure learn from Racket" .

If you understand what the title means well enough to object to its usage, that's solid proof that the title has communicated effectively. > What is a very bad in that title is that it focuses on Racket, just as if the title was: "Racket - this is how Lisp looks like beyond Clojure". That's your own interpretation--you could easily have interpreted it as "Racket--an example of a Lisp beyond Clojure".

I can understand and consider the choice of words to be bad.
Post reply on HN