Live data from Hacker News

Lisp's Influence on Ruby

blog.tacoda.dev

31–40 of 91 posts

Re: Lisp's Influence on Ruby

#31
post #11

> He’s described Ruby’s design as starting from a simple Lisp, stripping out macros and s-expressions Put the macros back! It would be so cool!

You kind of don't need them in Ruby, because everything is a method or an object or a closure and you can dynamically create and alter those at runtime. That's why Ruby is really good for ad-hoc DSLs in ways that Rust and Swift really are not.

> because everything is a method or an object or a closure

well, except for pattern matching. That is just syntax.

Re: Lisp's Influence on Ruby

#32
post #23

One way I find traditional Lisp style more painful for functional code than Ruby is that fully functional-style Lisp pushes me to read and write code the opposite way from how I think about it. In the author's example: orders .select { |o| o.placed_at > 1.week.ago } .group_by(&:customer_id) .transform_values { |group| group.sum(&:total) } the equivalent Lisp code would either be written in imperative style as multipl…

Threading macros are nice, though, right? https://docs.racket-lang.org/threading/introduction.html

They're nice, but they're not the same thing.

The threading macros are (as I understand it) pure sugar.

Turning (-> (gather my-list) uppercase-list sort) into (sort (uppercase-list (gather my-list))).

In contrast to, say, Java (I can't speak to the code above):

        List things = thingIds.stream()
                .map(model::findThing)
                .filter(Objects::nonNull)
                .toList();
These are streamed. This is pretty much a pipe structure, whereas the threading macros will create a lot of temporary copies of the data (I don't know if that's a universal truth). That is, if you're processing a 1000 items, say `gather` returns a 1000 items, that 1000 item list is passed to `uppercase-list` which return a new 1000 item list to feed to `sort` which returns another 1000 item list (assuming none of these are destructive).

I wish CL had something like the Java streams (maybe it does).

Re: Lisp's Influence on Ruby

#33
post #23

Earlier quoted context omitted.

Threading macros are nice, though, right? https://docs.racket-lang.org/threading/introduction.html

They're nice, but they're not the same thing. The threading macros are (as I understand it) pure sugar. Turning (-> (gather my-list) uppercase-list sort) into (sort (uppercase-list (gather my-list))). In contrast to, say, Java (I can't speak to the code above): List things = thingIds.stream() .map(model::findThing) .filter(Objects::nonNull) .toList(); These are streamed. This is pretty much a pipe structure, whereas…

I am pretty sure Racket's `stream` will handle this use case.

https://docs.racket-lang.org/reference/streams.html

Re: Lisp's Influence on Ruby

#34
post #21
post #20

Now that I'm out of the corporate tyranny and have my own company, I use lisp for everything. There's certain satisfaction in writing config files and persisting data directly in s-expressions. Any json requirements are triggered by exports to foreign systems.

Which Lisp, out of interest?

Does it really matter? There's a point in every Lisper's life, a threshold after which the question becomes immaterial - you'd stop thinking about intricacies of whatever Lisp and focus on the platform specifics instead. Any given day I might program in three-four different Lisp dialects, e.g. Clojure/Clourescript, Fennel, Elisp, Janet, etc. and it practically feels like I'm using the same PL. While switching between TS and JS (same family) never feels even close - there's always some mental burden.

Re: Lisp's Influence on Ruby

#36
post #21

Earlier quoted context omitted.

Which Lisp, out of interest?

Does it really matter? There's a point in every Lisper's life, a threshold after which the question becomes immaterial - you'd stop thinking about intricacies of whatever Lisp and focus on the platform specifics instead. Any given day I might program in three-four different Lisp dialects, e.g. Clojure/Clourescript, Fennel, Elisp, Janet, etc. and it practically feels like I'm using the same PL. While switching between…

Even the Lisps have Lisps. Like Clojure with ClojureScript, CLR, ClojureDart, Jank... etc.

Re: Lisp's Influence on Ruby

#37
post #20

Now that I'm out of the corporate tyranny and have my own company, I use lisp for everything. There's certain satisfaction in writing config files and persisting data directly in s-expressions. Any json requirements are triggered by exports to foreign systems.

That JSON prohibits trailing commata makes it an absolute pain to work with in practice. I also like how in Haskell: something = { element , element1 , element2 , element3 } Is an actually idiomatic way to deal with the lack of trailing commata.

Not really? A linter/formatter takes care of it.

Re: Lisp's Influence on Ruby

#38
post #23

Earlier quoted context omitted.

Threading macros are nice, though, right? https://docs.racket-lang.org/threading/introduction.html

They're nice, but they're not the same thing. The threading macros are (as I understand it) pure sugar. Turning (-> (gather my-list) uppercase-list sort) into (sort (uppercase-list (gather my-list))). In contrast to, say, Java (I can't speak to the code above): List things = thingIds.stream() .map(model::findThing) .filter(Objects::nonNull) .toList(); These are streamed. This is pretty much a pipe structure, whereas…

Apparently, the Series library offers that. It didn't make it into the ANSI standard, but it's still maintained and covered in CLtL2.

edit SICP has examples on how to implement streaming (in Scheme).

Re: Lisp's Influence on Ruby

#39
post #20

Now that I'm out of the corporate tyranny and have my own company, I use lisp for everything. There's certain satisfaction in writing config files and persisting data directly in s-expressions. Any json requirements are triggered by exports to foreign systems.

That JSON prohibits trailing commata makes it an absolute pain to work with in practice. I also like how in Haskell: something = { element , element1 , element2 , element3 } Is an actually idiomatic way to deal with the lack of trailing commata.

You see that style in SQL too.
Post reply on HN