6 ms·
A Double Handful of Programming Quotes
- noonespecial 18y ago"Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” - Bill Gates Every once in a while, I come across something new that surprises and impresses me about Bill Gates. If luck had fallen differently and Bill had become merely a millionaire, I think geeks would find him much, much cooler.
- wyday 18y agoI think a lot of people agree with that sentiment. But why should he be hated for his business acumen? If he was dirt poor would he be much, much, much cooler?
- noonespecial 18y agoNo, he'd be the same cool, but it wouldn't be occluded by the gargantuan thing that Microsoft has become. Like the Woz, we'd be able to hear more about Bill the engineer than Bill the billionaire.
- randomwalker 18y agoWhen I had a chance to meet the guy, these were the things that struck me, in order: He looks really old, way older than he does in photos. Must be all the stress. He's very, very good at thinking on his feet. He's actually quite pleasant to interact with and has milder views than you might think. People who know him have told me that the aggressive, brash behavior was merely a persona that he deliberately cultivated as part of his management style. (Incidentally, I've also interacted with RMS; he immediately came across as as a jerk. I can't help feeling that this has something to do with his project not reaching the heights that many feel it should have.)
- nailer 18y agoRMS should by all rights be pretty happy: GNU replaced Unix on servers, and has made more progress on the desktop than Unix ever did. I guess he never predicted that something that wasn't Unix would be the dominant OS. In essence, he chose the wrong enemy. Can you imagine what the world would be like if RMS had created 'GNU's Not DOS' instead?
- kirubakaran 18y agoYou mean 'GND's Not DOS' :)
- nailer 18y agoI sure do. In fact I'd written GND in my mind. But much like trying to write 'Linus' and not 'Linux', you have to really concentrate not to follow capital g, capital n, with capital u. :^)
- mutoxen 18y agoThat's why my Debian is fast, Bill: source code is on the server.
- jackowayed 18y agoNot that this has much to do with the article, but I don't like "double handful." It's very awkward. How about . . . metric dozen! Because it's close to a dozen and works with metric's 10-ness.
- gjm11 18y agoOr, y'know, "ten".
- Hexstream 18y ago"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." But if you implement a DSL and associated debugging tools and other niceties you can write your code as cleverly as possible AND be smart enough to debug it because it's so easy. But beware of that phase where you have a nice language but very leaky without supporting tools because it hurts!
- gruseom 18y agoThis is a tangent, but since I know you're a Lisp guy, I'd like to hear about how you go about debugging. Currently working in emacs/slime/sbcl, it's my one real complaint. Really all I want is a normal single-stepping debugger with the ability to view local state. That doesn't seem like such an inordinate desire, but I haven't seen any setup that comes close to it, which is annoying. My email address is in my profile if you'd care to compare notes about this.
- Hexstream 18y agoI'm sorry, I don't really have any insightful perspective on debugging. But maybe I can elaborate a bit on what goes wrong if you make a new DSL without keeping in mind debugging considerations. - You'll want to maintain a separate stack for your embedded DSL. It's really, really hard to debug when Lisp's stack and your DSL's get intertwined in a complex way in your stack trace. When I just had my straightforward HTML and CSS "closure-compilers" this wasn't such a big deal but when you make a language with more funky semantics where the order of evaluation is less obvious it's a real problem. - When you compile something (say, your semantic representation of HTML into optimized closures), you should always keep the more semantic representation of what you're compiling around. As an example of this, at first I made a macro to directly generate Lisp code that generates HTML source code. That was bad because the only thing I could do with my HTML is output it. But it turns out there are many things you can do if instead you make a macro that generates Lisp code that will build a semantic representation of HTML as Lisp objects: you can interpret it directly or optimize it or compile it directly or make a single-stepping debugger... The possibilities are limitless! Also, to preserve semantics as much as possible I think a rewriting strategy is great. You start with your super abstract representation, and then you rewrite in successive steps to an ever more concrete and low-level representation until you're done. For example, in an HTML system you'd have a login-box object that rewrites to HTML lisp objects that rewrites to HTML source code. It would be great to have a way of linking the various pieces at the different semantics level. For example, having some feature Explain that when you point to a certain character in the HTML source, it could tell: "This character was generated as part of the value of the text attribute of a img node that was generated in that page because it's part of the sidebar that's in the template of this part of the site"... Anyway, what I mean is that sometimes you want to focus on the high-level semantics and other times on the low-level, and you should be able to switch contexts at will. PS: I'm not even sure what exactly I was talking about anymore. Maybe I should start a blog...
- sofal 18y agoIt's times like this when I am glad that I can read comments here instead of being stuck with the comments on the actual blog.