5 ms·

Geek story hour: Parser of death

47 points by araneae 17y ago

michael_dorfman 17y ago
"The boss took one look at the speed test, and shook his head. ‘We can't ship that,’ he said, ‘it's far too embarrassing. We'll have to deliberately slow it back down again, and ship lots of incremental speed upgrades.’" Classic.
deleted 17y ago
[deleted]
- Luc 17y ago
  > If this guy was on my team, I'd fire him. I don't care if his code was "20 orders of magnitude faster." Ok, I'd hire him straight away after that, so things would work out well for everyone!
  - deleted 17y ago
    [deleted]
- shabble 17y ago
  Between your lack of comprehension of "factor of 20 speedup" and "20 orders of magnitude", combined with the fact that this seems to be the person who wrote PuTTY, I'm pretty sure he wouldn't want to be working for you anyway. Also, when did it become wrong to point out people's stupidity when they do something as utterly stupid as (quite clearly) demonstrated in the article?
  - adw 17y ago
    This has shown up here before, but http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html is even scarier. By the way, Simon's a top bloke with a really, really dry sense of humour. I'm wondering how much is being lost in cultural translation here.
alain94040 17y ago
I don't think the original code was stupid, it was just done quickly by someone whose background is not in parsers. If it did the job, it's already ahead of a lot of code out there. Sure, the code was bad and not thought through. That's kind of how I code when I don't care and need a quick workaround :-) It takes special people to write beautiful code 100% of the time.
- gaius 17y ago
  If you need a parser, ESR's your boy.
  - gaius 17y ago
    Oops, posting while drunk again :-/
- DougBTX 17y ago
  > it was just done quickly Ugly code can be written slowly too...
  - mbrubeck 17y ago
    Yes, definitely. If this was anything like my own experience writing parsers both the wrong way and the right way, the original programmer probably could have saved time by going out and reading a couple of textbook chapters, doing the homework problems, and reading the Bison or ANTLR manuals, and then doing it properly. Implementing a parser without knowing what you're doing is not quick or easy.
    - jerf 17y ago
      Worse than that, it is a frustrating, Sisyphean endeavor, always taking one step forward and two steps back once you get past a certain point. It is not a task I'd wish on anyone. It's a lot like writing a multithreaded program when you don't have a clue; you get a few quick things working and then descend into an endless hell of fixing one bug and causing two others, forever.
ldh 17y ago
It's too bad the relevant technical details of the story were overwhelmed by what felt a lot like arrogance and contempt for anyone without extensive experience with parsers.
- gaius 17y ago
  If you need arrogance and contempt, ESR's your boy.
- CapitalistCartr 17y ago
  To be fair, a parser shouldn't by written by "anyone without extensive experience with parsers," and it was unethical for his company to sell such a thing.
  - maximilian 17y ago
    I know that until, say, 3 years ago, I wouldn't know a thing about parsers, and if they boss wanted a scripting language, I would have parsed the whole thing by hand in C. It would have been a total nightmare to maintain (and develop) and would have been awful. Now I know about lex and yacc and I know what a parser really is. If everybody at the company was a bunch of random engineers or something with no experience with language design or parsers, its totally understandable that something like that could happen.
- sethg 17y ago
  You don't need "extensive experience with parsers" to do what the OP is describing. Lex and yacc (and their moral equivalents in other languages) were written precisely so that a programmer of ordinary skill could write a parser and feel reasonably confident that it would behave properly. I've done this kind of thing more than once, even back when I was fairly junior as a programmer.
- camccann 17y ago
  I think it was more along the lines of "contempt for anyone who, when asked to write code to do something difficult that they're unfamiliar with, chooses to write very, very bad code instead of learning the bare minimum needed to do a passable if amateurish job". For what it's worth, a day or two reading a decent textbook would provide sufficient "extensive experience with parsers" to avoid most of the horrible mistakes described. Intolerance for egregious unprofessionalism and incompetence is not exactly something our field suffers due to an excess of.
Hexstream 17y ago
I'm strangely reminded of SQL syntax (emphasis mine): "The language contained an operator ITEM n OF s, which would return the nth word of the string s. (Yes, that was a basic operator in the expression language; a function call syntax or a separate standard library would certainly have been well beyond the programmer's mental horizon.) But you could also alter the implicit use of whitespace as the ‘word’ separator, by writing ITEM n OF s SEPARATED BY d; this would allow you to, say, fetch the third field of a colon-delimited line. So far, nothing too out of the ordinary – except that one now naturally wonders which way ITEM a OF ITEM b OF c SEPARATED BY d would bracket, since it's exactly isomorphic to the well-known if–else ambiguity."

47 points by araneae 17y ago

"The boss took one look at the speed test, and shook his head. ‘We can't ship that,’ he said, ‘it's far too embarrassing. We'll have to deliberately slow it back down again, and ship lots of incremental speed upgrades.’" Classic.

deleted 17y ago

[deleted]

Luc 17y ago
> If this guy was on my team, I'd fire him. I don't care if his code was "20 orders of magnitude faster." Ok, I'd hire him straight away after that, so things would work out well for everyone!
- deleted 17y ago
  [deleted]
shabble 17y ago
Between your lack of comprehension of "factor of 20 speedup" and "20 orders of magnitude", combined with the fact that this seems to be the person who wrote PuTTY, I'm pretty sure he wouldn't want to be working for you anyway. Also, when did it become wrong to point out people's stupidity when they do something as utterly stupid as (quite clearly) demonstrated in the article?
- adw 17y ago
  This has shown up here before, but http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html is even scarier. By the way, Simon's a top bloke with a really, really dry sense of humour. I'm wondering how much is being lost in cultural translation here.

alain94040 17y ago

I don't think the original code was stupid, it was just done quickly by someone whose background is not in parsers. If it did the job, it's already ahead of a lot of code out there. Sure, the code was bad and not thought through. That's kind of how I code when I don't care and need a quick workaround :-) It takes special people to write beautiful code 100% of the time.

gaius 17y ago
If you need a parser, ESR's your boy.
- gaius 17y ago
  Oops, posting while drunk again :-/
DougBTX 17y ago
> it was just done quickly Ugly code can be written slowly too...
- mbrubeck 17y ago
  Yes, definitely. If this was anything like my own experience writing parsers both the wrong way and the right way, the original programmer probably could have saved time by going out and reading a couple of textbook chapters, doing the homework problems, and reading the Bison or ANTLR manuals, and then doing it properly. Implementing a parser without knowing what you're doing is not quick or easy.
  - jerf 17y ago
    Worse than that, it is a frustrating, Sisyphean endeavor, always taking one step forward and two steps back once you get past a certain point. It is not a task I'd wish on anyone. It's a lot like writing a multithreaded program when you don't have a clue; you get a few quick things working and then descend into an endless hell of fixing one bug and causing two others, forever.

ldh 17y ago

It's too bad the relevant technical details of the story were overwhelmed by what felt a lot like arrogance and contempt for anyone without extensive experience with parsers.

gaius 17y ago
If you need arrogance and contempt, ESR's your boy.
CapitalistCartr 17y ago
To be fair, a parser shouldn't by written by "anyone without extensive experience with parsers," and it was unethical for his company to sell such a thing.
- maximilian 17y ago
  I know that until, say, 3 years ago, I wouldn't know a thing about parsers, and if they boss wanted a scripting language, I would have parsed the whole thing by hand in C. It would have been a total nightmare to maintain (and develop) and would have been awful. Now I know about lex and yacc and I know what a parser really is. If everybody at the company was a bunch of random engineers or something with no experience with language design or parsers, its totally understandable that something like that could happen.
sethg 17y ago
You don't need "extensive experience with parsers" to do what the OP is describing. Lex and yacc (and their moral equivalents in other languages) were written precisely so that a programmer of ordinary skill could write a parser and feel reasonably confident that it would behave properly. I've done this kind of thing more than once, even back when I was fairly junior as a programmer.
camccann 17y ago
I think it was more along the lines of "contempt for anyone who, when asked to write code to do something difficult that they're unfamiliar with, chooses to write very, very bad code instead of learning the bare minimum needed to do a passable if amateurish job". For what it's worth, a day or two reading a decent textbook would provide sufficient "extensive experience with parsers" to avoid most of the horrible mistakes described. Intolerance for egregious unprofessionalism and incompetence is not exactly something our field suffers due to an excess of.

Hexstream 17y ago

I'm strangely reminded of SQL syntax (emphasis mine): "The language contained an operator ITEM n OF s, which would return the nth word of the string s. (Yes, that was a basic operator in the expression language; a function call syntax or a separate standard library would certainly have been well beyond the programmer's mental horizon.) But you could also alter the implicit use of whitespace as the ‘word’ separator, by writing ITEM n OF s SEPARATED BY d; this would allow you to, say, fetch the third field of a colon-delimited line. So far, nothing too out of the ordinary – except that one now naturally wonders which way ITEM a OF ITEM b OF c SEPARATED BY d would bracket, since it's exactly isomorphic to the well-known if–else ambiguity."