Posted by Daniel Lyons
Fri, 14 Sep 2007 06:15:00 GMT
Someone on Reddit shared the most cogent summary of DHH’s philosophy. Love him or hate him, he deserves most of the credit for Rails (and indirectly much of the recent furor over DSLs), and understanding him will get you far in understanding those things. He’s also a Web 2.0 personality of no small importance.
It must be very gratifying to be David Heinemeier Hansson. After all, he’s entered that quite small group of people in the programming world who are known by their very own TLA. Designers and programmers of various stripes regard him very highly. Of course, this has only happened to three or four other geeks in all of time: ESR, RMS, DJB, and maybe EWD. In short, it only happens to blowhards.
DHH is a blowhard and you know it. 37signals’ products tend to be so “opinionated” as to be anti-user. Lots of people have walked away from Basecamp because part of having “vision” is apparently knowing and understanding your tool so well that no customer—no matter how much they use your tool—can possibly have a suggestion for you that you should even bother responding to with anything less than total contempt. Want some proof? There’s even a hilarious parody of 37signals’ blog.
Without a bunch of highlighter, let’s skip to the point: Lots of companies achieve success, make a blog, and rant about their awesome formula. Lots of fans arrive, read the blog, and start to copy the formula. You shouldn’t, though, because mixed in with “good” companies are bad companies with crap products. They’re just as successful. DHH believes that his formula is perfect and it’ll work for everyone, but he has no way to know which parts of his formula are brilliant and which parts are bullshit. If you start your company ready to say “fuck you” to the users, well, you might be successful, but you might not.
I’m really glad someone as surly as myself managed to start a company and get invited to talks to put up slides that say “fuck you” on them. Really. It makes me feel really good about myself. The cult behavior is what’s pissing me off. Hating users is not a road to success. It’s an obstacle to success that, in DHH’s case, was apparently not enough of one to stop it from happening.
37signals used to have a great page comparing the cost of Basecamp to their competitors. The competition, if they’re still around at all, was charging hundreds or thousands of dollars for comparable or less functionality with really bad UI. Basecamp showed up and for $20 you could use it and it was easy. Might the real take-away here be the oldie-but-goodie “find a niche and fill it?” Do I need to point out the utterly missing runaway success with their other programs, largely warmed-over versions of Basecamp with different UIs? Does anybody really use Backpack? I’m sure twenty people will show up to point out that they do, but it’s hardly the millions who are using Basecamp. Campfire? Writeboard? Please.
So let’s be serious. They’re a one-hit wonder and their success has everything to do with capitalism and nothing to do with their cult of personality. That may sound depressing, but it should be liberating. You don’t need to drink any kool-aid. You just need to find a niche and fill it. You can be the biggest asshole in the world, and you’ll still get stinking rich. If you play your cards right, you too can be reduced to just three little letters.
Just be sure to give DKL some the credit when that happens.
Edit: comments are closed. Please see my commenting policy, my response to another troll on Reddit, and think about why you wanted to waste your time insulting someone on their blog when you could just get one of your own. Thank you.
Tags bullshit, rails, rants
Posted by Daniel Lyons
Fri, 07 Sep 2007 08:46:00 GMT
Apparently people are talking about what it means to know a language. The debate seems to be centered around whether or not knowing the language syntactically or in terms of the library is what really constitutes “knowing” it.
Even in natural language there is disagreement around this kind of thing. Some teachers prefer to focus on vocabulary, others on grammar. Many others prefer immersion to formal methods. I think this translates roughly to teaching programming in terms of idiomatic forms.
I’ve been exposed to all of those methods of learning a language in computer science. Lots of people buy, read and are devoted to “cookbooks.” I have found that, although they are often good, some are overly simplistic (O’reilly’s PHP Cookbook comes to mind), but neither is really a good substitute for reading actual code in the language. Immersion, if you will.
In Compiler Writing in college, we were required to implement a compiler for a language nobody knew which bore very little resemblance to other languages we knew (Tiger). In that class I got to exercise my skills at reading a BNF specification of a grammar, and I was able to write code that should have compiled pretty easily with just a little bit of studying. This doesn’t come up very often, because usually there is a body of code to learn from idiomatically. There are no idioms for Tiger, because nobody uses it enough to establish them and it’s designed to by syntactically troublesome without being particularly expressive in the first place. (I did once email the REALbasic developers to see if they would supply me with a BNF for the language, and I was told it didn’t exist). So the skill is nice to have but comes up very rarely.
The author above is, I believe, reaching for the same idea of idiomatic use in talking about max() in Python, because anyone who really understood Python would use it. At the same time, I have to say there’s more to it than that, because someone who really knew Python would know not only the idioms but also when not to use them. Lots of English speakers do not use “me” and “whom” correctly (including me, sometimes). True mastery includes that level of knowledge. For many languages, it probably includes a certain amount of knowledge about the implementation, or at least an intuition as to what equivalent constructs are going to perform faster, for example.
But taking this concept even further, I would say nobody is master of any programming language without knowing at least one other programming language. Linguistic myopia is a huge problem. Languages are primarily tools. If you think there are no better tools for any problems, you will find yourself writing unidiomatic code in your language to solve problems which are idiomatic in other languages. In the case where you’re forced to solve a problem in the wrong language, it may even be better sometimes to solve it in a way idiomatic to the more appropriate tool than heave and misapply your energy to an idiomatic but confusing solution. It certainly will be worth it for the affect on your brain.
Tags languages, programming, rants | 1 comment
Posted by Daniel Lyons
Thu, 06 Sep 2007 03:52:00 GMT
Recently I had a kind-of debate with a kind-of friend about programming. It came to basically one thing: do you value readability?
I certainly do. I think one of the things that makes programming interesting is that we’re trying to express something to a computer and another human being at the same time. All programming failures fall on one side or the other of that balancing act.
The argument for readability cannot be absolute though. A hundred lines of Python may be more readable than 20 lines of Haskell. So we have to ask ourselves some more questions besides pure readabilit. We have to ask ourselves if we are following the elements of style. Can we “omit needless words?”
- Does this code communicate in 20 lines the same thing as 100 lines of Python?
- Do we gain from the conciseness?
- Does it take the same amount of time to understand?
- Do we want to constrain all of our developers to the same standard?
The allure of functional programming is that it is both more rigorous and more concise. When you understand a fold, you are tempted to use it even in languages where its application will be awkward or difficult, such as Ruby. This template substitution probably has appeared on my blog before; normally this would be coded as an imperative loop, but I chose to use Array#inject which is basically a fold:
vars.inject(@template.clone) do |template, (region, value)|
template.gsub(/%#{region}%/, value.to_s)
end
In OCaml this would probably have looked a lot more concise than it does in Ruby, and it would be considered more readable. So you have to consider your audience too. Haskell’s audience is smarter than Java’s, or at least thinking in a more high-level way. Though, really, you should try to learn Haskell, it’ll make you smarter. (Or if you’re really vindictive you’ll at least bring the average down.)
So my operative concept is not readability anymore. It’s conciseness. Concise not like Perl or APL, concise like “omit needless words.” It may take you longer to figure out than comparable 5x larger Python code, but it won’t take you 5x longer, and you won’t be falling asleep.
And why do you believe your code is so important anyway? I’d bet 99.9% of code in this world is couch paintings. It seems so important right now. In five years, is it going to be important? Or is it going to already have been rewritten by then? So much code is treated like an investment when it is written as so much slapdash cut-and-paste filler. Other code is written elegantly and perfectly and winds up forgotten because nobody knew how to treat it like an investment. The entities most qualified to treat code as an investment seem to have practices that encourage the quality being the lowest. Hiring lots of developers, outsourcing, having corporate policies about language choice and a complete lack of code reviews have a strong negative effect on code quality.
If we really wanted to treat code as an investment, wouldn’t we want to revel in it a bit more? Read it, really take the time to enjoy it, pass the tricks around the organization? Treat the code like a member of the company rather than a process or, worse, the result of some process like so much insect shit?
And while we’re on the subject, I no longer believe any project really needs more than three developers.
Tags rants | no comments
Posted by Daniel Lyons
Thu, 06 Sep 2007 03:07:00 GMT
I don’t hate a lot of things, though the quantity and ardor seems to increase with every year. I want to share a few of those things with you now, so you can get to know me a little better than you already do.
The top three things I hate are:
- The wrong technology (MySQL and PHP)
- The wrong reasons (couch painting)
- Polyamory (more crap must be better)
Some technological equal-opportunists say things like “every technology has an appropriate use.” Guess what? Some technology doesn’t.
Let’s not beat around the bush. You shouldn’t be using MySQL or PHP. Not on this project, not on the next project, not now, not ever. I don’t care what monstrous shit they’ve stapled onto MySQL to try and make it look like a database or what monstrous object system they’ve stapled onto PHP to make it look like a real programming language. Neither of these things are real, they’re both charlatans and if you’re tempted to use them for a technological reason you don’t understand the problem and you should ask someone who does.
MySQL pretends to be a database. It is no such thing. It is an SQL front-end for a hair-removal tool. Dr. Codd’s Physical Data Independence says your view of the data should be independent of the physical representation of the data on disk. So which integer do you want, the 1-bit, 2-bit, 4-bit, 8-bit, 16-bit, 32-bit or 64-bit? Nevermind, let’s talk about the tables, those are pure relational entities, right? Oh wait, you wanted transactions? I guess you’d better use the InnoDB table type (what happens if you start a transaction and some of your tables are InnoDB and others aren’t?) Nevermind, let’s talk about SQL the standard. How would you like a TIMESTAMP column, that’s standard SQL? Oh wait, that one automagically changes when you update the row, you actually wanted a DATETIME. Want to concatenate some strings? Better remember that the concatenation operator is treated as logical OR in MySQL, or you’re going to see a bunch of 0’s where you expect strings (I know, instead I’ll use the handy CONCAT function!) Does this sound like hell yet? If not, MySQL is for you!
PHP is great, assuming you aren’t the slightest bit interested in consistent functionality across more than one server, like restating things over and over again, prefer your languages guess at what you meant when they can’t quite tell, and have configuration files. Off the top of your head, how many languages can you think of that have configuration files? Did you know PHP doesn’t ever free memory in the core, because it was never meant to be running longer than a fraction of a second? Or that you can define functions inside functions, but they’re actually defined in the enclosing scope (you like warnings, right?) Try accessing an array returned by a function without sticking it in a variable first sometime. And the joy of having dictionaries that are arrays at the same time never ends! What about SQL, PHP’s supposed to have that down, right? Of course there’s the PEAR DB module, which is deprecated, the MDB2 module, which doesn’t work properly on PHP 4, and ADODB, which everyone was using for years before PEAR existed. Oh, and let’s not forget that PHP will helpfully escape those strings on the way in, unless you’ve disabled that in the configuration, or locally with a .htacess, or at the top of the script with a setvariable function call. And my, what consistency in naming conventions! I hope you have a fast link to php.net.
Do not use this software for your own projects unless your husband or wife thinks you would be hotter bald, wrinkled and angry.
Oh, but you don’t have a choice about your deployment software, do you, because your son who’s good with computers already bought you hosting on a $5 a month shared plan, and whatever I write has to work on that thing. This is called the wrong reason. You didn’t call me when you were thinking about writing the app, you called me after you started. This is like calling your plumber with your toilet on the lawn and a kitchen sink on the floor in your bathroom where your toilet should be, and saying, “No, I already bought this sink, you have to make this work.”
Firstly: no, I don’t. This analogy is really much closer to Windows. You called me up and said, “Daniel, you’re good with computers; what kind of computer should I get?” And I said you should get a Mac. You gave me some excuses. I told you to get a Mac anyway. Instead, you bought this PC and now you’re on the phone with me. Why? Because you didn’t do what I said, when I told you what would happen if you got another PC, and you got one anyway, and lo and befucking hold, I was fucking right. What were your reasons again?
- The price. $600 is too much? You can’t afford a computer. Nevermind the fact you spent $1500 on a PC. Doesn’t Apple tell you about their financing?
- You can’t upgrade it. That’s bullshit on a stick. Did you ever upgrade that PC? Of course not. You didn’t do shit with it. You bought another stick of RAM two months before you decided it was toast. Nobody who upgrades their shit for real calls me up asking for help. You want to play upgrade-the-PC? Have a great time. Call me when it’s broken and it’s your peril.
- “But I need compatibility with X!” Have you ever looked at a Mac? For $80 they come with programs that are fully compatible with X. Or for free, if you like NeoOffice. You know something else? Macs run Windows better than Windows computers do, with Parallels or VMWare or whatever. Try that, I dare you. In six months you’ll never run it and you won’t miss it.
- “But what about emailing documents!” What is this, 1989?
- “But my games!” Oh, that’s funny, I thought you had work to do. Because that’s what I was talking about. You want a video game system, buy one. I’m not here to help you get your fix.
There’s a reason all the artists and programmers are using Macs. We know quality when we see it. If you’re using Windows you’re making a statement to the world: I don’t deserve a real computer. Well, stop inflicting it on those of us that do, and get over your $600 sticker shock. Get a fucking Mac already.
Same thing goes for your database. If you need a database, chances are, you have data you want to keep and query. If you need a database, you need PostgreSQL. Not MySQL, not SQLite, a real G-ddamn database.
If you have a program to write, you need to pick the right tool for the job. Sometimes that’s Ruby, sometimes that’s Haskell. There are other languages, sure, but it’s never PHP and it’s never C++.
Would you let your car dealer determine what outfits you wear to work? Of course not. Then why do you let your ISP determine what you write your applications in? They’re your applications, not your ISP’s, for fuck’s sake. When you call up your ISP and ask about PostgreSQL you should hear one of two things:
- Oh, actually we recommend all our customers use PostgreSQL because it’s faster and doesn’t lose their data.
- It’s installed, have fun. We don’t give a damn what you’re up to.
If you instead hear one of these responses, get a new ISP:
- We recommend MySQL, because it’s [faster, better, more reliable, some other lie]
- We only support MySQL. (Who’s asking about support, asshole?)
- Let me transfer you to someone who can answer your question.
So you got the wrong ISP. So what? You dated the wrong people in high school. Now you know better. Quit trying to justify your stupidity by hand-waving, referencing other companies, or talking about popularity. Yeah, it’s true, doing things the right way is hard.
I don’t really have a good segue to polyamory but that’s a rant for another time anyhow.
Tags rants, technology | no comments
Posted by Daniel Lyons
Tue, 07 Aug 2007 20:02:00 GMT
If someone searches for something and winds up on your site, does it look like this?
This is completely unreadable. Like probably over 95% of visitors to your site, I showed up because I made a google query and you said something relevant about it. Instead of being able to read it, I’m staring at goddamn keyword confetti. You just cornholed my eyes. Google told me you had great stuff to share with me about whatever it is I’m searching for, but you decided to impress me with your HTTP_REFERER parsing rather than just giving me the goddamn content.
If I want to see the keywords highlighted, I’ll use Google Toolbar or I’ll search with my browser. As an actual user of the internet, I can and do read. Often. You do not have to mangle the layout for people who do not read.
I don’t know who started this fad, but they need to take a little lead in the face.
Tags design, engines, hate, rants, search, violence, web | 2 comments
Posted by Daniel Lyons
Thu, 17 May 2007 09:11:00 GMT
Functional programming is undergoing a sort of a collective raised eyebrow these days. Here’s why I think it’s cool and useful:
- Functional programs are more concise.
This is because recursive definitions are closer to their mathematical counterparts than procedural ones.
- Functional data structures have interesting properties.
For example, purely functional lists and trees work through an implicit copy-on-write, meaning older versions of the data structure can continue to exist very cheaply.
- Lazy languages improve performance through memoization.
If all your functions have the same result for a given input, then the compiler can just substitute the answer for the whole computation after it has been computed once. This saves a lot of compute cycles at the cost of some memory.
- Lazy algorithms let us use high-level metaphors without sacrificing performance.
It’s natural to talk about, for example, the Fibonacci sequence as an infinite list, but only lazy languages like Haskell let you really define it that way.
- Functional programs are more modular than procedural or object-oriented programs.
Through algebraic data types, type classes, polymorphic functions and functors, you can reap almost all the benefits of OO software construction. But you also get pattern-matching and a wealth of function composition functions, and very cheap and pretty anonymous functions. Your glue code becomes small and transparent. The net effect is tremendous.
- Functional programs have fewer bugs.
Functional programs depend on mathematical properties to a far greater extent than on intrinsic state. This means the method of computation is not hidden in the background in terms of correct sequencing of modifications to some binary chunk of data. Because the pieces are smaller and work deterministically with a given input, you are more confident of the result when they are combined. Higher-order functions (functions which combine other functions) are smaller and well-understood, and replace much of what would be hand-written glue code in a procedural language. All these attributes combine to make code that, in general, is more reliable than procedural or OO code.
Flame on.
Tags functional, programming, rants | no comments
Posted by Daniel Lyons
Tue, 10 Apr 2007 07:23:00 GMT
This is a response to Why Misunderstanding OO Sucks.
As systems get larger and more complex then the reductionist view becomes less and less relevant. It continues to have useful inputs into the design, but the development process itself must become more holistic in outlook or it will fail to produce a harmonious whole.
This is an appealing view. It’s of course amusing to throw this at Joe Armstrong, who not only pretty much implemented Erlang but has had his hand in a number of largish systems. If Joe’s perspective were merely reductionist, I’d find it hard to believe that his creation is running the majority of telecom systems in the world. That can’t be a trifling matter.
I think it’s insane to call OO a process and emphasize its effect on software design. If that were the case, how did we have the OO revolution in the 80’s, and not have agile development until the late 90’s? No, if OO had anything to do with process, it had to do with waterfall-model spec, design, then implement thinking. And yet the strongest OO systems today, Smalltalk, Ruby, Python and Io, have nothing to say about the development model, because it had nothing to do with their development or use. If anything, Ruby has a model in agile, thanks to the agile people being overly fond of it.
As for everything being an object, this is only partly true. To make this statement true we have to group together two varieties of object—those with identity and those which are values. Many object oriented languages do in fact conflate these two types of data structure, but of course many do not.
The only OO languages that are a joy to use are those which “conflate” these two things. In Ruby, for example, I can define whatever method I like on integers and call it on a literal, such as the built-in 1.upto(10) { |x| puts x }. Ruby would blow without this feature. In fact, even Python has slowly started to adopt this as a feature. It’s Java and C++, which stupidly maintain a separation between objects and types, that receive the ire of programmers who wish to treat things uniformly.
This difference between object and value semantics is as fundemental to understanding object oriented design and programming as that of function composition is to functional programming. It is unfortunate that it is generally rather badly taught.
I would like to believe that, having been an OO programmer for five years, that statement would have meaning to me, but it doesn’t, for the reasons mentioned above.
If we could build systems that didn’t need to bother with state our jobs would be much easier, but the resulting software would be much less useful and interesting.
That’s interesting, because as mentioned above, Joe Armstrong’s Erlang is now the backbone of the telecom industry, and it doesn’t support modifying your variables. Now, it certainly has state, just like Haskell has state—implicit state, or state managed through a mechanism so alien that OOP isn’t even a concept that can be applied to it.
This shocked me when I started learning functional programming about a year ago. I looked at ML and I snorted. How can this possibly be usable without being able to factor my code into classes? What am I going to do when the client calls me up and I need to have the program do something totally different?
Well, it turns out in functional programming, we have a type system that makes some of OOP unnecessary. Firstly, it’s simple to construct types which enumerate all the different ways of carrying around state you would use in an object. Secondly, we have a pattern-matching system which makes it both possible and cheap to write functions that do different things depending on the nature of their input.
The straw man argument in that is: aha! What about when you add a new alternative to your type, then you have to go through all those functions again and update them! Supposing this is true, consider how hard it is to add a new operation in OO. Say you come up with some new method you need—Aha! You have to go through all those classes and implement that method. And that is the worst case in OO.
OO is, in general, a very good thing when compared to procedural languages. It’s nutty to defend Java and C++ type systems when Ruby and Eiffel exist.
The interesting thing about OO’s lamentable state is quite clear if you look at the history. C++ was made to be as backwards compatible with C as possible. Java was made to be essentially a simplification of C++ with a few improvements. The functional language community wasn’t in a position to have these worries, because these worries come from having a user base, so instead it came up with more and more amazing languages, trying desperately to get people interested.
Actually, this was the second time this had happened. The same thing had basically happened with Lisp in the late 70’s. Everyone was using it and making incompatible variations. Then eventually they decided to have a big standardization process during which the AI winter apparently came and everyone switched to C++. I guess.
What makes the debate bizarre is essentially the Smalltalk factor. While everyone was switching to C++ and lauding the wonder that is OO, how many people were using Smalltalk? It’s not like Smalltalk went away, but it seems to have as many users now as it had after everyone defected for the other. And yet it’s so much more capable and powerful. I find it hard to believe that C bindings could be so difficult or that optimizating compiler technology could be so out of reach when C++ is about the most complex language being used (after FORTRAN or Ada, probably).
In my opinion, I should be spending more of my time worrying about what I’m doing with data rather than worrying about the data itself. OO is definitely interested in helping you worry about the data itself. This is a natural fit for boring business data processing, which is why Java’s being hailed the new COBOL. The crown belongs to the functional languages, but boredom has killed the king.
Tags erlang, oop, rants | 2 comments
Posted by Daniel Lyons
Mon, 25 Dec 2006 09:15:33 GMT
The article The Bipolar Lisp Programmer has been making the rounds lately. I read it and felt, as did many other programmers, that I was reading my biography.
The author did touch on one point, that you see in Lisp many one-man projects. He concludes that Lisp is what you make it. I think that the corpses of half-finished, buggy projects littering the Lisp community are actually more than just a symptom of the condition. I think they actually perpetuate the condition. In theory, installing a Common Lisp library is as simple as (asdf-install:install 'library), but in reality it’s a pain in the ass. It’s especially hard if you aren’t using SBCL. This contributes to the problem.
Here’s another good example: the Series library, which is so important it’s actually in CLTL2 as Appendix A. What Lisps does it work on? CMUCL and CLISP. So it doesn’t seem to support the commercial Lisps or the most popular open-source Lisp SBCL, or OpenMCL. Suck. But very symptomatic.
Look at the GUI situation. You’ve got everyone talking about CLIM, specifically McCLIM. Does it work? Nope. There’s a non-portable Cocoa library for OpenMCL, there’s CLX, and then there’s McClim which only works on Linux with Xlib or GTK. Now that’s portability. Additionally, all of these libraries produce UIs that are quite ugly.
Part of my big problem is, I really don’t know what kind of programs I want to spend my life writing. I am, frankly, quite tired of web applications. The languages that I love—the functional languages—don’t seem to have anything approaching decent UI libraries. It seems like there are some emerging web frameworks that don’t suck, such as ErlyWeb and WASH, but ultimately I dislike the repetitiveness of web programming. What’s left? Servers, I guess. I’d like to write more programs that do actual work, but I don’t quite know how to get from here to there.
Somehow I wound up a web programmer. This is all very strange to me.
Tags programming, rants | no comments
Posted by Daniel Lyons
Wed, 20 Dec 2006 23:47:00 GMT
blog = 1,180,000,000.
blog -ramblings = 844,000,000.
Therefore, ramblings = 336,000,000.
Tags blogging, rants | 1 comment
Posted by Daniel Lyons
Fri, 15 Dec 2006 06:23:38 GMT
Are you the kind of programmer that thinks architecture is really great, and writes pretentious articles about bridges? Or are you more of a corny artist type?
Let me submit a third option: the plumber. Fixing the shitter may not be glorious, but isn’t it rather a lot like email? Especially when you consider that 98% of it is spam? Have you seen Java? Nobody builds the Empire State Building or paints the Mona Lisa in any curly-brace-and-semicolon abomination.
Have you seen all those parentheses in Lisp? Aren’t they rather a lot like, well, pipes?
Tags programming, rants | no comments
