Live data from Hacker News

Plan to throw one away

garethrees.org

21–30 of 88 posts

Re: Plan to throw one away

#21
post #15

> The failure to store a represention of the parsed code was disastrous because it meant that in order to evaluate an expression or statement for a second time, the engine had to parse it a second time. Ha! They must have learned how to write an interpreter from Herbert Schildt: http://www.drdobbs.com/cpp/building-your-own-c-interpreter/1... [1989] In this piece of amusement, the Little C program is a giant null-term…

Didn't PHP also used to use the position of a fileseek as the instruction pointer?

Shell script interpreters like bash do. You can change a bash script while it's running (append, or truncate and re-write) and it'll keep going from the same offset.

But then again, shell script is in a different class of language I'd say.

  #!/bin/bash
  COUNTER=0
  addmore() {
      echo hi $COUNTER
      ((COUNTER++))
      echo "addmore" >>$0
      sleep 1
  }
  addmore

Re: Plan to throw one away

#22
post #21
post #15

Earlier quoted context omitted.

Didn't PHP also used to use the position of a fileseek as the instruction pointer?

Shell script interpreters like bash do. You can change a bash script while it's running (append, or truncate and re-write) and it'll keep going from the same offset. But then again, shell script is in a different class of language I'd say. #!/bin/bash COUNTER=0 addmore() { echo hi $COUNTER ((COUNTER++)) echo "addmore" >>$0 sleep 1 } addmore

[deleted]

Re: Plan to throw one away

#23

I find the dates a bit suspect (referenced ECMA script standard was June 1997, book was late 1996, so how did this all happen twenty years ago, just months following the official release of JavaScript in May 95?), but guess that's not the point. Maybe I'm alone, but implausible details distract me from an otherwise great story that can teach a lesson many should learn.

[deleted]

Re: Plan to throw one away

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

Or maybe the job of the tool has become more complex in it's nature.

Re: Plan to throw one away

#25

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

The freeware versions have improved a bit. For exmaple, Both Bison and Berkeley Yacc (the new one maintained by T. E. Dickey) support reentrant parsing, which works hand-in-glove with likewise support in GNU Flex. A parser that whacks around global variables (like parser generated by classic Yacc) is going to be a nonstarter in any modern language which gives programs run-time and compile-time access to the parser (c…

> freeware

Did you mean "free software"?

Re: Plan to throw one away

#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 (the creator of Tcl) knew he was building a rough first system that he would need to rewrite later, or he really thought it was the right way to do things at the time.

(To be fair, Tcl is a whole lot simpler to parse than JavaScript and Ousterhout is a good coder, so even the pre-8.0 versions were fast enough to be practical for everyday scripting tasks.)

Re: Plan to throw one away

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

Am I the only one who remembers LiveWire? It didn't last long, but it was Javascript on the server.

Re: Plan to throw one away

#29

I find the dates a bit suspect (referenced ECMA script standard was June 1997, book was late 1996, so how did this all happen twenty years ago, just months following the official release of JavaScript in May 95?), but guess that's not the point. Maybe I'm alone, but implausible details distract me from an otherwise great story that can teach a lesson many should learn.

He says 18 years at one point in the article. Since it was almost certainly in England or Wales it shouldn't be too difficult to identify the company involved. Zeus, maybe?

Re: Plan to throw one away

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

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.
Post reply on HN