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

Plan to throw one away

garethrees.org

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Plan to throw one away

#81

Post by srathbun »

srathbun wrote: post #76
jaytaylor wrote: post #4

Are Lex and Yacc still the state of the art 20 years later?

Yes, yes they are. I've used them successfully for various parsing projects. And in fact Bison recently picked up GLR parsing to deal with multiple options ( https://www.gnu.org/software/bison/manual/bison.html#General... ). But for something even more fun, I suggest you check out Marpa ( https://jeffreykegler.github.io/Marpa-web-site/ ). It is, by far, the nicest parsing tool I have ever worked with. Being able to p…

Oh, and I found something new and fun for Marpa just now! It seems there's already the beginnings of a Python port (https://github.com/rns/libmarpa-bindings/blob/master/python/...) available.

Re: Plan to throw one away

#82

Post by dang »

legulere wrote: post #68
dang wrote: post #41

Earlier quoted context omitted.

> this seems quite idiotic to me Please don't be uncharitably dismissive. The author didn't throw away the parser because it was recursive descent—in fact he explicitly excludes that as a reason. (The rest of your comment is fine.)

Sorry I was too harsh, but to me it reads much like: I personally don't like this code, so I threw away everything.

It's true that that's a mega motivation lurking in the soul of every programmer. But it's also often true that writing a program can be faster than revising one (or even reading it) when the original programmer isn't available.

To me his justification sounded pretty convincing, though not to you, which is totally fair. As far as HN commenting goes it's just a matter of explaining your view in a substantive way.

Re: Plan to throw one away

#83

Post by hinkley »

dvirsky wrote: post #46
hinkley wrote: post #34

As a corollary: https://en.wikipedia.org/wiki/Ship_of_Theseus You can replace all the parts of your crappy v1.0 code and still call it the same code base. That's what the smart ones go around doing quietly.

While in most cases it's probably a better option, I think that in this case there wasn't time to do that. I would probably explore the option to still use the parser, and have it generate an AST first, and from there go pretty much in the direction of the author.

Part of the problem is being given an assignment two weeks before a ship date. I know people do stuff like that all the time but that's hardly an excuse (we do terrible things to each other all the time so it's okay?)

The author is already screwed before he even has a chance to start.

Re: Plan to throw one away

#84

Post by normac »

acveilleux wrote: post #72
normac wrote: post #27

Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error. Tcl is now about as fast as a typical scripting language and its implementation is regarded as a model of high-quality readable code. I wonder if John Ousterhout (t…

Most shell interpreter follow this model, perhaps he started Tcl has an improved shell scripting system and only later improved it? It would explain some of the syntax choices which is fairly reminescent of c-shell and some bourne thrown in.

That's pretty much what Tcl is, even to this day. Ousterhout saw scripting languages as extremely high level tools used to issue commands to the low level code that does the heavy lifting. It's very much the same philosophy as shell scripts, except you implement new commands as extensions to Tcl instead of command line programs, and it all runs in the same process.

Of course, the language has matured and now it's also usable for building rich and complex apps top to bottom, just like any modern scripting language.

Re: Plan to throw one away

#85

Post by [deleted] »

munificent wrote: post #78
normac wrote: post #27

Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error. Tcl is now about as fast as a typical scripting language and its implementation is regarded as a model of high-quality readable code. I wonder if John Ousterhout (t…

> Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error. Fun fact: most modern JavaScript engines in browsers work this way today , though at a different level of granularity. Parsing slows down application startup, so…

[deleted]

Re: Plan to throw one away

#86

Post by normac »

munificent wrote: post #78
normac wrote: post #27

Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error. Tcl is now about as fast as a typical scripting language and its implementation is regarded as a model of high-quality readable code. I wonder if John Ousterhout (t…

> Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error. Fun fact: most modern JavaScript engines in browsers work this way today , though at a different level of granularity. Parsing slows down application startup, so…

That's pretty neat. Clearly some level of parsing needs to happen before run time, or else it couldn't even balance braces to know where the function body ends. So it must be that it parses the function body just enough to figure out where it starts and ends, then does a complete parse at runtime (probably building off the results from the first stage).

Re: Plan to throw one away

#87

Post by kybernetikos »

ghayes wrote: post #30
smegel wrote: post #13

Earlier quoted context omitted.

> javascript in the server wasn't "too soon", it already existed Those two things aren't necessarily in conflict. Netscape's server wasn't exactly a roaring success. What really made Javascript-in-the-server work was a Javascript JIT engine (v8) that actually made Javascript very competitive compared to traditional server side scripting languages. So given that there did not exist a Javascript JIT engine back then, m…

Agree that was probably too soon, even if it existed in some form. I've often wondered why precisely people love JavaScript on the server. I would guess it's a mix of 1) event machine parallelism, 2) isomorphism, 3) speed (since V8/SpiderMonkey/Chakra), 4) cross-compatibility, and 5) engineers not needing to learn another language.

Also, the npm ecosystem.

The early js-on-the-server systems had miserable ecosystems.

Re: Plan to throw one away

#88

Post by munificent »

normac wrote: post #86
munificent wrote: post #78

Earlier quoted context omitted.

> Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error. Fun fact: most modern JavaScript engines in browsers work this way today , though at a different level of granularity. Parsing slows down application startup, so…

That's pretty neat. Clearly some level of parsing needs to happen before run time, or else it couldn't even balance braces to know where the function body ends. So it must be that it parses the function body just enough to figure out where it starts and ends, then does a complete parse at runtime (probably building off the results from the first stage).

> or else it couldn't even balance braces to know where the function body ends

That's literally all it does. It tokenizes and counts braces.

Post reply on HN