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

161–170 of 182 posts

Re: Rewriting the Ruby parser

#161

Post by shrimp_emoji »

soulbadguy wrote: post #160
RhodesianHunter wrote: post #141

Earlier quoted context omitted.

Because it depends entirely on the use case. There are plenty of cases where Java will be faster than c++ purely due to the available libraries.

> Because it depends entirely on the use case. Every thing depends on the use case, and one case always find special case as counter example and most engineering solution/choices. Generalization are still useful and sometime "true". C++ (and native languages) are faster than java simply because it was designed this way. C++ chose speed at the price of complexity, safety and build time. Java on the other hand focused…

> C++ chose speed at the price of complexity

If that were true, C and Rust (which are typically faster) would be just as complex as C++ (but no language is).

It chose to jump into the OOP fad while staying low level ("what if we had C with classes?"). That's the cause of most of the complexity. The rest is age, backwards compatibility handcuffs, and kitchen sink stuff from other languages like move semantics and functional stuff.

> Java on the other hand focused on simplicity and safety.

Java chose to jump into the OOP fad while being high level. Ruby and Python did the same thing, and they're also simple as a result. That or low level and not OOP are the correct combos if you don't want to wind up with something as byzantine as C++.

Re: Rewriting the Ruby parser

#162

Post by soulbadguy »

di4na wrote: post #147
soulbadguy wrote: post #59

While on the subject, anybody has good reference on parsing error recovery ?

If you find it, i am interested. But it seems to be a topic that is still open to research and niche to a small group of devs

I suspect that most of the knowledge on this topic is embedded in source code of most prominent compiler tool chain and the head of their dev. :(

I think they might an interesting intersection here we ML, where can could learn the comment mistake pattern made by real user and either error correct better, or at least provide pin point accurate error messages.

Re: Rewriting the Ruby parser

#163

Post by RhodesianHunter »

soulbadguy wrote: post #160
RhodesianHunter wrote: post #141

Earlier quoted context omitted.

Because it depends entirely on the use case. There are plenty of cases where Java will be faster than c++ purely due to the available libraries.

> Because it depends entirely on the use case. Every thing depends on the use case, and one case always find special case as counter example and most engineering solution/choices. Generalization are still useful and sometime "true". C++ (and native languages) are faster than java simply because it was designed this way. C++ chose speed at the price of complexity, safety and build time. Java on the other hand focused…

>Hard to believe, but in that case i would say that you are comparing libraries, not the languages.

No, you're not, because comparable libraries in C++ to do many activities, such as at-scale stream processing, simply do not exist in C++.

Re: Rewriting the Ruby parser

#164

Post by RhodesianHunter »

foldor wrote: post #156
RhodesianHunter wrote: post #139

Earlier quoted context omitted.

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

I would argue that an XML file that's "over 1M lines!" is no longer human readable.

That's not the point though.

Re: Rewriting the Ruby parser

#165

Post by RhodesianHunter »

ckolkey wrote: post #149
RhodesianHunter wrote: post #139

Earlier quoted context omitted.

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

It sounds like the novel idea was thinking to do that in the first place

"Use a more performant serialization format" is hardly novel. It's why things like protobuf exist.

Re: Rewriting the Ruby parser

#166

Post by RhodesianHunter »

skitter wrote: post #151
RhodesianHunter wrote: post #139

Earlier quoted context omitted.

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

I think a bigger difference is that the XML is parsed by a Ruby program and the generated Ruby code is parsed by a C program.

Using something like protobuf would have required fewer steps and adhered to a standardized format.

Re: Rewriting the Ruby parser

#167

Post by mingodad »

It's not true "the best chance you have is reading the 14 thousand-line parse.y file and trying to understand it", there are several tools to navigate yacc/bnf style grammars like https://www.bottlecaps.de/convert/ and it's companion https://www.bottlecaps.de/convert/ that make relatively easy to understand/document/debug/compare the grammar.

Just added several ruby grammars here https://github.com/mingodad/plgh/tree/main/ruby they are converted (mainly using https://www.bottlecaps.de/convert/) to an EBNF understood by https://bottlecaps.de/rr/ui to generate navigable railroad diagrams.

Copy and paste the EBNF on https://www.bottlecaps.de/rr/ui on the tab "Edit Grammar" the click on the tab "View Diagram" to see/download a navigable railroad diagram.

Re: Rewriting the Ruby parser

#168

Post by soulbadguy »

shrimp_emoji wrote: post #161
soulbadguy wrote: post #160

Earlier quoted context omitted.

> Because it depends entirely on the use case. Every thing depends on the use case, and one case always find special case as counter example and most engineering solution/choices. Generalization are still useful and sometime "true". C++ (and native languages) are faster than java simply because it was designed this way. C++ chose speed at the price of complexity, safety and build time. Java on the other hand focused…

> C++ chose speed at the price of complexity If that were true, C and Rust (which are typically faster) would be just as complex as C++ (but no language is). It chose to jump into the OOP fad while staying low level ("what if we had C with classes?"). That's the cause of most of the complexity. The rest is age, backwards compatibility handcuffs, and kitchen sink stuff from other languages like move semantics and func…

> If that were true, C and Rust (which are typically faster) would be just as complex as C++ (but no language is).

I don't think that this assertion follows from my statement.

It's totally possible that there exist simpler languages which give exactly the same level of performance and expressiveness as C++ while being simpler. Nobody said that the C++ design was optimal with regard to the complexity/zero cost abstraction ratio. Bjarne him self think so (https://www.stroustrup.com/quotes.html), and both carbon and cppfront are effort in that direction.

The point was that when comparing (as of today) java vs C++ we shouldn't be surprised that a language which has "zero cost abstraction" as a core principle, and which is willing to be arbitrary complex ended up being faster.

With regard to the language you mentioned, C is simpler because it does less... And rust is much more recent and completely rethinks the native language landscape. I am not sure that we had the understanding (or even the tech) necessary to create rust 20 years ago.

But more importantly, i don't really buy the premise, of "are typically faster". Some concrete example would be nice, otherwise from experience this statement is wildly incorrect.

> It chose to jump into the OOP fad while staying low level ("what if we had C with classes?"). That's the cause of most of the complexity

Disagree.

> The rest is age, backwards compatibility handcuffs

Very true, if we remove backwards compact. C++ would be simpler.

> like move semantics and functional

Adding features paradoxically can simplify a language by providing a coherent/unified version of previously distinct usage pattern. uniform initialization is the canonical example. I would say that move semantics also simplify the language by folding resources reuses patterns inside RAII.

Same for C++ lamda, just simpler syntax ...

So you seems to say that we can choosing to forgo low-level control (ruby,java,python) or general abstraction structure(which is what OOP is really) to would produce a simpler language.

But C++ is exploring a different design question, trying to have in the same language low-level control, and abstraction that are general enough to expression complex design, and which can be efficiently deconstructed as to not impact performance. And the C++ community seems to be willing to pay some level of complexity for that.

Re: Rewriting the Ruby parser

#169

Post by Dylan16807 »

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…

The difficulty isn't `unless(x) {}`, it's `{} unless(x)` and `{} if(x)`.

Except you also don't have the brackets to keep things organized.

Re: Rewriting the Ruby parser

#170

Post by soulbadguy »

RhodesianHunter wrote: post #163
soulbadguy wrote: post #160

Earlier quoted context omitted.

> Because it depends entirely on the use case. Every thing depends on the use case, and one case always find special case as counter example and most engineering solution/choices. Generalization are still useful and sometime "true". C++ (and native languages) are faster than java simply because it was designed this way. C++ chose speed at the price of complexity, safety and build time. Java on the other hand focused…

>Hard to believe, but in that case i would say that you are comparing libraries, not the languages. No, you're not, because comparable libraries in C++ to do many activities, such as at-scale stream processing, simply do not exist in C++.

> many activities

I do not doubt that there are domain where the best libraries are in a particular language, and this language might not be C++.

I am just not convince that java is better than C++ with this regard. (as they are more domain where the best C++ is faster than best java one).

But i think that's beside the point, we are comparing language here, so the existing/quality of characteristics of libraries shouldn't be the main focus (beside the stdlib of course).

Now there is more to choosing a tech. stack than just the programming language, and that include the libraries, current knowledge of the team etc. And i would even venture to say that those might be more important than the programming language per say. But i do believe we can still factor those concern out and compare programming languages, keeping in mind it's only part of the story.

Post reply on HN