3 ms·
Stevey's Blog Rants: Rich Programmer Food
- far33d 19y agoWell, 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 19y agoI 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 19y agoMy mistake on Java - frankly, I haven't written any in quite a while.
- tx 19y agoJava has much simpler syntax than C, you got your buckets wrong.
- palish 19y agoLisp has no syntax. :)
- tx 19y agoFinally 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" :)
- palish 19y agoWall. Of. Text. Seriously, is it necessary?
- paul 19y agoI enjoy his posts, though apparently they aren't for everyone.
- ralph 19y agoHe's just too verbose. If the content took 40% of the words I'd be interested.
- paul 19y agoBut a lot of the other words make it entertaining. Cutting it down to a few power-point slides full of bullets would be a lot more concise, but also boring (and therefore less effective).
- palish 19y agohttp://www.orwell.ru/library/essays/politics/english/e_polit http://www.orwell.ru/library/essays/politics/english/e_polit
- akkartik 19y agoHe doesn't break any of the rules too badly, I don't think. He isn't using large words, or convoluted sentences. He's just saying things perhaps you don't find interesting.
- ralph 19y agoThat's excellent, thanks very much. I'm also reminded of Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte. -- Blaise Pascal, Lettres provinciales, letter 16, 1657. (I am sorry for the length of my letter, but I had not the time to write a short one.) Paul, I agree it needs to attract, entertain, and hold the reader but feel the verbosity is laziness in editing rather than style.
- Tichy 19y agoIf you are interested in compilers, you might also enjoy Wolfram Research's 2,3 Turing Machine Research Price: http://www.wolframscience.com/prizes/tm23/ 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.
- fireandfury 19y agoThat 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 19y agoI 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 http://brlewis.com/source.brl?q=/map.brl
- Goladus 19y agoIn 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.
- reitzensteinm 19y agoThis 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.