Live data from Hacker News

Lisp's Influence on Ruby

blog.tacoda.dev

51–60 of 91 posts

Re: Lisp's Influence on Ruby

#51

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…

It could just be written like:

  (~> orders
    (filter (lambda (order)
              (timestamp> (order-date order)
                          (timestamp- (now) 7 :days))))
    (group-by #'order-customer-id)
    (mapcar (lambda (group)
              (reduce #'+ group :key #'order-total)))
But I prefer the typical Lisp code where I get the sums of the totals of the orders with the same customer ID which were placed in the past week, instead of the orders made the past week grouped by customer ID their totals summed together.

Re: Lisp's Influence on Ruby

#52
post #12

Earlier quoted context omitted.

... or just use Common Lisp.

Which is what I do. One can dream though right? Of a world where Ruby stayed just a tad more Lisp-y and less Perl/C/Smalltalk/Unix-y. Also I'm working on a DSL/Macros that give me more Ruby-esque quality of life things in Lisp.

Have you checked out dieggsy's Whisper (https://sr.ht/~dieggsy/whisper/>) yet? It's based on Arne Bab's Wisp (SRFI 119).

Re: Lisp's Influence on Ruby

#53
I've never been more thoroughly convinced that I would like ruby more than from this article. I'm currently stuck reaching for python a lot of the time (absolutely love it tbc), but maybe it's worth changing things up and trying to give ruby a shot.

It was one of the first programming languages I was introduced to at 16 or so, but an older person that I looked up to told me it would get me stuck in "hobby coder land". He was wrong in so many ways, but even if he was right, I wanna have fun in my hobby code :)

Re: Lisp's Influence on Ruby

#54

Earlier quoted context omitted.

Macros depend on homoiconicity which Ruby sacrificed in order to have familiar syntax.

Homoiconicity makes macros slightly more syntactically elegant, but is not at all necessary. Rust has macros and isn't homoiconic at all.

C has macros too, but it's a second preprocessor language. They both accomplish metaprogramming, but it's questionable whether they're both the same lisplike "macros" we're talking about. Ruby source could be passed through the C preprocessor and get C macros that way. I've actually seen Java code that does just that.

Re: Lisp's Influence on Ruby

#56
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…

If the difference didn't matter, we wouldn't have so many different lisps. Obviously the difference mattered enough to the people that created Common Lisp when Scheme already existed. Rich Hickey thought it mattered when he created a completely new Lisp instead of just porting Scheme to the JVM.

Re: Lisp's Influence on Ruby

#57
post #56

Earlier quoted context omitted.

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…

If the difference didn't matter, we wouldn't have so many different lisps. Obviously the difference mattered enough to the people that created Common Lisp when Scheme already existed. Rich Hickey thought it mattered when he created a completely new Lisp instead of just porting Scheme to the JVM.

> If the difference didn't matter, we wouldn't have so many different lisps

Literally the opposite. We can make and use so many, because writing them is more or less the same. We can quickly throw together a new lisp for a new platform or such and use it without problem.

Re: Lisp's Influence on Ruby

#58

Earlier quoted context omitted.

Homoiconicity makes macros slightly more syntactically elegant, but is not at all necessary. Rust has macros and isn't homoiconic at all.

C has macros too, but it's a second preprocessor language. They both accomplish metaprogramming, but it's questionable whether they're both the same lisplike "macros" we're talking about. Ruby source could be passed through the C preprocessor and get C macros that way. I've actually seen Java code that does just that.

C macros are definitely much weaker; they're not by themselves Turing-complete (except maybe with vendor-specific extensions? I'm not an expert here). Rust has both macros by example (precisely analogous to Scheme macros, and equal in power) and procedural macros (conceptually analogous to Common Lisp macros, allowing arbitrary code at macro evaluation time, but I don't know enough about Common Lisp to say whether there are differences in power).

Re: Lisp's Influence on Ruby

#59

Earlier quoted context omitted.

C has macros too, but it's a second preprocessor language. They both accomplish metaprogramming, but it's questionable whether they're both the same lisplike "macros" we're talking about. Ruby source could be passed through the C preprocessor and get C macros that way. I've actually seen Java code that does just that.

C macros are definitely much weaker; they're not by themselves Turing-complete (except maybe with vendor-specific extensions? I'm not an expert here). Rust has both macros by example (precisely analogous to Scheme macros, and equal in power) and procedural macros (conceptually analogous to Common Lisp macros, allowing arbitrary code at macro evaluation time, but I don't know enough about Common Lisp to say whether th…

How does it work internally? It would have to output the new source code as data somehow, and have the Rust compiler consume it. How does that happen?

The lispy "macros" I speak of are FEXPRs, just everyday normal functions that just happen to not evaluate their arguments, they receive the source code as lists instead. It's easy to manipulate those lists and evaluate the result.

Lisps themselves moved away from FEXPRs because they were "too powerful" and made the compiler's life hard. Common Lisp and Scheme macros are the more restricted versions that allow compilers to make more assumptions, thereby enabling more aggressive optimization.

Re: Lisp's Influence on Ruby

#60

I've never been more thoroughly convinced that I would like ruby more than from this article. I'm currently stuck reaching for python a lot of the time (absolutely love it tbc), but maybe it's worth changing things up and trying to give ruby a shot. It was one of the first programming languages I was introduced to at 16 or so, but an older person that I looked up to told me it would get me stuck in "hobby coder land"…

Tbc?
Post reply on HN