

Geek story hour: Parser of death - araneae
http://simont.livejournal.com/216731.html

======
michael_dorfman
_"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.

------
alain94040
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.

~~~
DougBTX
> it was just done quickly

Ugly code can be written slowly too...

~~~
mbrubeck
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
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
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.

~~~
CapitalistCartr
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
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.

------
Hexstream
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."

