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

Lisp's Influence on Ruby

blog.tacoda.dev

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Lisp's Influence on Ruby

#61

Post by Kaliboy »

0x3444ac53 wrote: post #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"…

I've had one job in my life, still at the same company. (8 years).

I applied cause the listing mentioned Python, and I was programming in Python at the time.

Once I started they were like yeah we put that there to reach a broader public but we use Ruby (on Rails).

So that's what I learned. I've just returned to Python via LLM's. I literally have not felt the need nor desire to use Python once I got used to writing Ruby.

Re: Lisp's Influence on Ruby

#62

Post by ameliaquining »

matheusmoreira wrote: post #59
ameliaquining wrote: post #58

Earlier quoted context omitted.

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 FEXPR…

Yes, a Rust procedural macro is a function that takes a Rust syntax tree as an argument and returns a Rust syntax tree. When you use it, the compiler compiles it (for the host architecture), dynamically loads it into the compiler process, calls it, and inserts the output into the code to be compiled. https://doc.rust-lang.org/book/ch20-05-macros.html#procedura...

I don't see why this would inhibit optimization, unless you mean it slows down compilation, in which case, yep, that's a real and rather notorious downside.

Re: Lisp's Influence on Ruby

#63

Post by steveklabnik »

matheusmoreira wrote: post #59
ameliaquining wrote: post #58

Earlier quoted context omitted.

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 FEXPR…

Rust has two form of macros: “macros by example” and “procedural macros.”

The latter is basically a function from token streams to token streams, and macros by example are more traditional macros which were initially designed by Dave Herman, who was heavily involved in Racket.

Re: Lisp's Influence on Ruby

#64

Post by neilv »

> Both marks come from Scheme, where [...]

Reminds me of an email I wish I still had.

Circa 2000, I wrote that I was leaning towards moving to Scheme, for more rapid R&D work than I could do in Java.

Some nice-sounding person I didn't know emailed me from Japan, to mention a language I hadn't heard of, called Ruby.

I don't know whether the person was Yukihiro Matsumoto himself, but it's a small world.

Re: Lisp's Influence on Ruby

#65

Post by matheusmoreira »

ameliaquining wrote: post #62
matheusmoreira wrote: post #59

Earlier quoted context omitted.

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 FEXPR…

Yes, a Rust procedural macro is a function that takes a Rust syntax tree as an argument and returns a Rust syntax tree. When you use it, the compiler compiles it (for the host architecture), dynamically loads it into the compiler process, calls it, and inserts the output into the code to be compiled. https://doc.rust-lang.org/book/ch20-05-macros.html#procedura... I don't see why this would inhibit optimization, unles…

> the compiler compiles it (for the host architecture), dynamically loads it into the compiler process, calls it, and inserts the output into the code to be compiled

That's actually amazing. So the compiler's own data structures are visible in the language.

I see how it works now. Thanks for explaining.

Re: Lisp's Influence on Ruby

#67

Post by jksmith »

atcol wrote: post #21
jksmith wrote: 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?

I use the Franz Allegro toolchain exclusively.

Re: Lisp's Influence on Ruby

#68

Post by chirsz »

Blikkentrekker wrote: post #25
jksmith wrote: 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.

Welcome to https://jsonc.org

Re: Lisp's Influence on Ruby

#69

Post by pluralmonad »

evw wrote: post #15

For folks that want all of this plus macros (and a lot of other great things), check out Elixir.

Elixir has forever ruined me for other languages. Every new PL I dip my toe into gets measured against it. Jose and the core team seem to always land on the right decisions, or at least very good ones.

Re: Lisp's Influence on Ruby

#70

Post by allthetime »

veqq wrote: post #57
chabska wrote: post #56

Earlier quoted context omitted.

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.

Why is it necessary to throw together a new lisp and not just use an existing one?
Post reply on HN