Live data from Hacker News

Plan to throw one away

garethrees.org

31–40 of 88 posts

Re: Plan to throw one away

#31
post #7
post #5

Earlier quoted context omitted.

I'm not sure how they've aged (I've only really used ANTLR) but I think this one of those situations where 95% of the importance is using the right kind of tool for the job, even if the tool itself is a little rusty.

The only thing that lets old tools get rusty is a lack of maintenance or improper storage. Software does not need to suffer from either and plenty of 'old' tools are still in maintenance. Kernels, compilers, file-systems and network stacks originally written decades ago are still in common use today. Flex and Bison are still being maintained and still have major releases. Whether they are still 'state of the art' is…

> The only thing that lets old tools get rusty is a lack of maintenance or improper storage. Software does not need to suffer from either

1. Yes, you can ruin every metaphor if you over-analyze it enough.

2. No, software has its own "rust" scenarios, like not staying compatible with other ecosystem elements, or simply being different than the current best-practice.

Re: Plan to throw one away

#32

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

If you're in the market for a parser generator, you may want to look into the lemon parser distributed with sqlite3. I found it much nicer to play with.

Re: Plan to throw one away

#33
post #19

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

I don't know about "state of the art", but they are tried and true for lexing and parsing respectively. If you are looking for something more exotic or a very specific use-case, I'd say use something like Ragel[0]. [0] http://www.colm.net/open-source/ragel/

Ragel is great for replacing regex validation code ("Does this string look like a IP address, email address, or date?"), or for writing a lexer, but if you need to actually parse something (i.e. extract even a moderate amount of structured data) then you need something else.

It has a particularly sublime output mode for generating Graphviz dot files however.

Re: Plan to throw one away

#35
post #14

Earlier quoted context omitted.

In terms of ease of use, Parser Combinators beat most Parser Generators. (For absolute speed, Generators might still beat Combinators.)

Yeah, I should try them. I remember a previous discussion about the old language SNOBOL having parser combinators as a built-in feature: https://news.ycombinator.com/item?id=10103460

I learned Parser Combinators on Haskell. But a basic version is easy to write yourself in any language that supports first class functions.

Re: Plan to throw one away

#36
post #13
post #3

Cool read, however, I feel the need to point out that 20 years ago, javascript in the server wasn't "too soon", it already existed. In 1995 Netscape had the Netscape Enterprise Server[0] that ran javascript for server-side scripting. Actually, the two books I used, back in the day, to learn Javascript was the client- and the server-side javascript guides published by Netscape. [0] https://en.wikipedia.org/wiki/Netsca…

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

SpiderMonkey was around way before v8, and once it begat TraceMonkey, it had JIT. Bloomberg used this pervasively on their billion-dollar product for years before v8 was a thing--you can read that from one horse's mouth here: https://news.ycombinator.com/item?id=3984617

Re: Plan to throw one away

#37
post #36
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…

SpiderMonkey was around way before v8, and once it begat TraceMonkey, it had JIT. Bloomberg used this pervasively on their billion-dollar product for years before v8 was a thing--you can read that from one horse's mouth here: https://news.ycombinator.com/item?id=3984617

That's quite interesting. I only mentioned v8 for the fairly obvious reason that it formed the core of the first really popular server side JS implementation, which I don't really need to name.

Re: Plan to throw one away

#38
Wow, this seems quite idiotic to me. Sure, recursive descent parsers have some theoretically inferior properties to other techniques, but in reality they're much better because you can actually handle errors in a user-friendly way. That's why basically every bigger compiler uses handwritten recursive descent parsers.

Re: Plan to throw one away

#39
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.

The same issue comes up with classic cars. Is a car which has seen many/most of its parts replaced (including chassis members, body panels,...), still the same car?

Re: Plan to throw one away

#40
post #3

Cool read, however, I feel the need to point out that 20 years ago, javascript in the server wasn't "too soon", it already existed. In 1995 Netscape had the Netscape Enterprise Server[0] that ran javascript for server-side scripting. Actually, the two books I used, back in the day, to learn Javascript was the client- and the server-side javascript guides published by Netscape. [0] https://en.wikipedia.org/wiki/Netsca…

[deleted]
Post reply on HN