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

Rewriting the Ruby parser

railsatscale.com

Post reply on HN
Print view View original

131–140 of 182 posts

Re: Rewriting the Ruby parser

#131

Post by haberman »

PaulHoule wrote: post #74

It’s little appreciated how much current parser generators are holding the industry back. That is, LISP maintains a lead in metaprogramming because it bypasses Chomskyism alltogether. It really should be a few lines of code to add an “unless(X) {}” statement to “if(!X) ()” to Java, Python, Ruby but the very idea that you could patch an existing grammar with a separate file is like technology that fell off a UFO. Also…

I used to strongly agree with this. This is an article I wrote on the subject 10 years ago: https://blog.reverberate.org/2013/09/ll-and-lr-in-context-wh...

I even had ideas like what you mentioned about encoding precedence and associativity explicitly: https://github.com/haberman/gazelle/blob/a12a123129dfb7e1f3e...

But I'm no longer as optimistic. The main problem is that nearly all languages have syntax that cannot be easily formalized using declarative abstractions like CFG or PEG, and must fall back to imperative code. And once you have a mix of imperative and declarative code, most of the benefits of a purely-declarative abstraction go away -- or at least the benefits that mattered to me.

Re: Rewriting the Ruby parser

#133

Post by clairity »

twic wrote: post #83
clairity wrote: post #28

Earlier quoted context omitted.

i think if rails continues to push hotwire (turbo + stimulus, and perhaps strada?) and get a coherent story on view components, it will continue to take mindshare from the js hype of the last decade. mobile dev is in decline, and browser makers just released web notifications, web app support, webtransport, page transitions, etc., so the backend has largely reached parity for cross-platform development. no longer is…

> mobile dev is in decline This is news to me. Is this really true?

i don't have rigorous data at hand, but browsers and mobile hardware are now good enough that most apps are just fine being developed using cross-platform web tech rather than java or swift. plus, apps no longer attract and retain users as they once did (we're past the hype cycle). native mobile, as a result, has retreated to domains where the tighter integration has benefits, like games, health, IoT, etc. even apple is loosening its iron grip over its app store as the tradeoff between integration and flexibility no longer makes sense for most apps. apple now focuses more on content and on integrating more functionality into iOS itself because of that.

Re: Rewriting the Ruby parser

#134

Post by nine_k »

munificent wrote: post #130
jrochkind1 wrote: post #9

As a devoted rubyist, it seems clear to me in retrospect that ruby's "pretty complex to parse is just fine" approach has been a real challenge to the language's success. For reasons related to discussion in OP. This project could be one approach to ameliorating that challenge, I'm very pleased to see shopify willing to invest in this, and hope it ends up effecting the ecosystem as hoped.

I disagree. There are many languages that are hard to parse that are very successful. C and C++ are the obvious examples: there are many dark corners around the preprocessor, type annotations, etc. C++ is an absolute nightmare to parse. C# is pretty complex too. Python has its weirdness around indentation. Honestly, most popular languages end up acquiring a decent amount of grammatical complexity over the years and i…

I'd say that C and C++ were successful despite their being hard to parse, and other unfortunate hacks, like null-terminated strings and include files instead if modules There was little choice for other features they offered (like Unix being written in C and bundling a C compiler) which.were the compelling reason to use them.

JavaScript was a huge success not because it was a great language, but because everyone wanted to write for the browser.

Re: Rewriting the Ruby parser

#135

Post by viiralvx »

pcthrowaway wrote: post #86
noelwelsh wrote: post #55

Earlier quoted context omitted.

I don't deny the utility of Rails for building a certain class of web site. But I think there is a difference between Rails and Ruby, and a difference between use of a technology and improvements to that technology. I think a technology must continue to change and adapt to remain relevant. I see Shopify as the main driver of current improvements to Ruby (the core features of the most recent release, and the upcoming…

I'm a bit surprised that Github isn't doing work on Ruby, since they're probably the largest RoR deployment

A lot of ex-Hubbers went to Shopify. Additionally, a lot of upstream commits to Rails occurred from things pulled out of GitHub. GitHub has (had?) an entire team dedicated to Ruby and Rails and performance and optimizations/improvements

Re: Rewriting the Ruby parser

#137

Post by tiffanyh »

ximus wrote: post #136
tiffanyh wrote: post #132

GraalVM? What’s the progress on Ruby/GraalVM that Shopify has heavily invested in?

GraalVM Ruby, more commonly known as TruffleRuby, is actively developed still. As the article states, it adopted YARP already.

My understanding is that Shopify still hasn’t been able to migrate to Graal/TruffleRuby, even after 10-years of its development.

Re: Rewriting the Ruby parser

#138

Post by munificent »

nine_k wrote: post #134
munificent wrote: post #130

Earlier quoted context omitted.

I disagree. There are many languages that are hard to parse that are very successful. C and C++ are the obvious examples: there are many dark corners around the preprocessor, type annotations, etc. C++ is an absolute nightmare to parse. C# is pretty complex too. Python has its weirdness around indentation. Honestly, most popular languages end up acquiring a decent amount of grammatical complexity over the years and i…

I'd say that C and C++ were successful despite their being hard to parse, and other unfortunate hacks, like null-terminated strings and include files instead if modules There was little choice for other features they offered (like Unix being written in C and bundling a C compiler) which.were the compelling reason to use them. JavaScript was a huge success not because it was a great language, but because everyone want…

I think you and I are saying essentially the same thing: grammatical complexity seems to have little negative impact on language success.

> There was little choice for other features they offered (like Unix being written in C and bundling a C compiler) which.were the compelling reason to use them.

Pascal was around at the same time, is grammatically infinitely more elegant... and is dead.

Re: Rewriting the Ruby parser

#139

Post by RhodesianHunter »

cout wrote: post #39

With the mention of the parser's performance, I am reminded of Rich Kilmer's 2004 RubyConf presentation. Rich used Ruby to test reliability of a distributed system with hundreds of Java VMs. Some of the serialized data was stored as XML (over 1M lines!), which was slow to parse and load. Rich modified the program to serialize the data as Ruby code, which loaded much faster ( https://www.infoq.com/news/2007/06/infoq-i…

>Some of the serialized data was stored as XML (over 1M lines!), which was slow to parse and load. Rich modified the program to serialize the data as Ruby code, which loaded much faster

So he took a data format designed for human readability and converted it to a data format that's designed purely to be read by Ruby and people are surprised that it's faster?

Re: Rewriting the Ruby parser

#140

Post by RhodesianHunter »

byroot wrote: post #82
soulbadguy wrote: post #50

Earlier quoted context omitted.

Disclaimer : my career has mainly been on compiler/runtime and other infrastructure related stuff, so not much of a business logic/web dev kind of guy. > The end of the day I think the way to get tech too scale, is for companies / academics / etc to really just put the work in. This is true in the abstract, but my point is mainly about the comparative effectiveness of different strategies when it come to building sca…

> Disclaimer : my career has mainly been on compiler/runtime and other infrastructure related stuff, so not much of a business logic/web dev kind of guy. That probably explain your surprise. This question comes up extremely often on HN, the answer is that even if you were to stop all feature development, re-platforming a large organization like Shopify would take years, not even considering all the re-training, lost…

When you reach the level of scale where you need to move to distributed systems, you pretty much need to re-platform anyways. That's usually the ideal time to make a decision like this.
Post reply on HN