
Stevey's Blog Rants: Rich Programmer Food - paul
http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html
======
reitzensteinm
This article resonated with me a lot. On Tuesday I wrote a custom build app
for my games, something that'll take my game dir filled with crap, preprocess
the source code to create multiple versions, filter out unnecessary files,
auto generate an inno setup install script and spit out setup files (or run
the game in auto play test mode, etc).

Back in high school I wrote a similar thing in C#. I wrote custom code for
every window and literally every control - lots of redundant code there. It
was a big horrible mess and took two months to develop. For various reasons
(cross platform high on that list, but also lack of flexibility and a horrible
source base) I decided to rewrite it. I used to think I was a pretty good
programmer (Dunning Kruger effect?).

This time around, I instead built a system which automatically generated a GUI
around RTTI and handled loading and saving - very similar to Rails'
Scaffholding. A day instead of months, because I chose to build a domain
specific library with which to construct my application out of.

It's not exactly compiler writing (a parser wasn't needed thanks to RTTI, but
if it was I would have written it) but I think it's very analogous to what
he's talking about - problems that appear big and nasty can be abstracted down
and become trivial by solving one hard problem instead of a larger amount of
slightly smaller ones. This is true of compiler writing, frameworks like RoR,
layers like HTTP/TCP/IP. It's the very reason why the spread in programmer
productivity is so high. Better programmers don't attack problems faster, they
attack them from a position of higher leverage.

------
tx
Finally the dude started blogging again. I am in no position to prove him
right or wrong, but his emphasis on parsing/mining skills is very
understandable.

Simplifying, commercial software does (mostly) two things: collects data and
transforms data. Too many programmers focus on the later ignoring the former.
For instance, designing and running cool algorithms on a some sort of a giant
graph is cool indeed, but parsing and representing a real-world data in a form
of graph is boring and challenging.

"Web 2.0" likes it easy way: "Users will bring you data themselves" :)

------
fireandfury
That was hilarious. I still can't really gauge how serious that guy was. From
the article:

"Situation 7: you have a small, lightweight startup company filled with cool
young people with long blue-tinted hair and nose rings and tongue rivets and
hip black clothes and iphones and whatever the hell else young people have
these days. You use Ruby on Rails for your site..."

lol

------
brlewis
I enjoyed this essay, but still didn't get what the big benefit is of learning
compilers past the point of creating a parse tree. He seemed to imply that
situations 5-7 could benefit from the later part of what compilers do. I can
see that you're doing something with the parse tree after you get it, but in
each case it looks different from what a compiler would do.

If all that matters is being able to get a parse tree, then maybe more
languages should provide a parsing function, just as Lisp does.

I wrote a source highlighter without really knowing compilers, but that's just
because getting a Scheme (or BRL) parse tree is trivial.

<http://brlewis.com/source.brl?q=/map.brl>

~~~
Goladus
In situation 5, I think he's suggesting that being good at making a de-
compilers would help a lot in being able to interpret the undocumented router
responses. I think maybe he got sidetracked talking about compiler
optimization and didn't explicitly mention the sort of practical benefits
you'd get from understanding how to do it.

------
Tichy
If you are interested in compilers, you might also enjoy Wolfram Research's
2,3 Turing Machine Research Price:
<http://www.wolframscience.com/prizes/tm23/>

Win 25000$ and eternal fame if you can prove that the Turing machine described
there is universal, or if you can prove that it is not universal (in the
latter case, I think eternal fame won't be included in the price).

It is a beautiful problem.

------
far33d
Well, this is certainly an argument for more simple languages (syntactically)
like LISP, C, even Tcl, over C++ and Java. Because I don't think anyone really
understands how the C++ compiler really works (it took a looooong time to get
a C++ compiler that actually adhered to the standard).

~~~
paul
I wouldn't put c++ in the same category as Java. C++ has many layers of
"stuff" (templates, macros, etc) while the Java compiler is so simple that you
can easily do a reverse-compile.

Personally, I'd rather have a useful syntax and maybe a standard parser that
gives easy access to the parse tree. I wrote a Javascript-to-Javascript
compiler (that did optimization and correctness checks along the way) once and
the fact that JS has syntax wasn't a big problem. (especially since I ripped
off the parser from Rhino)

~~~
far33d
My mistake on Java - frankly, I haven't written any in quite a while.

------
palish
Wall. Of. Text.

Seriously, is it necessary?

~~~
paul
I enjoy his posts, though apparently they aren't for everyone.

~~~
palish
Oh, I enjoyed the post.. I was more commenting about the style of the
presentation. There's many ways to break up a wall of text into brain-
compilable sections. Joel on Software has an article that mentions one or two.
<http://joelonsoftware.com/articles/fog0000000033.html>

~~~
akkartik
All the writing style and organization in the world is only to get people to
read something. If he's gotten you to read it, and you will continue to read
what he writes next, he doesn't need to work on all that stuff anymore.

Organization isn't to make the reader's life easier. Making sense of what one
reads is largely an introspective activity. No matter how well-organized it
is, you the reader have to regurgitate into a form suitable for yourself
before you can digest it. This is called active reading.

