Ouch. My jaw dropped when I saw my old article on the front page of HN.
To me, posting this article in 2007 taught me two lessons:
#1: The goal of good writing is not to be understood, but rather to not be misunderstood.
Judging by the hundreds of angry comments on that original link, I failed miserably. At the time, nobody read my little blog, so I didn't expect anyone to see this post. I was really just writing it to answer a few of my Rails friends' questions. I didn't brace it for public attack.
#2: The public you is not you.
I'm a mediocre programmer, trying to improve, and at the time just trying to make my website the way I wanted it. So it kinda hurt at first to read hundreds of fellow programmers saying I'm the biggest idiot to walk the earth.
Then I just realized that my post should have been written clearer, and the reason people were so upset is because it sounded like I was attacking this framework/language that they had spent so many hundreds of hours learning. It had nothing to do with me. Only I know my real programming skills, so their comments were not really about me.
Ever since then I don't let comments get to me, either way. Neither praise nor criticism should be taken personally. It's just feedback on the post/subject. Useful for learning how not to be misunderstood, but has nothing to do with you.
I agree. I read it for the first time and honestly couldn't care less about languages and found it quite clear that you liked ruby but found php worked for your needs.
The content of that article is fine. It all boils down to #2:
"OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION"
Joel classically addressed this with regard to the Netscape re-write from scratch. In a word: don't. You have working code, meeting customer needs, and re-writing the whole thing is time you are not spending fixing bugs, adding features, or improving performance of the existing code.
I would say what you ended up doing in that 2 months was a massive refactoring. You took what you had, along with the knowledge of all the mistakes you made, and turned it into the code it should have been from the start. The key was that at every point, you still had a working system that was still integrated with all the other systems you needed to run your business, which is pretty much the definition of refactoring.
None of this has anything to do with Rails or PHP. You can substitute any other two languages or technologies and the outcome would not change. I suppose that is one thing you could have stressed more, but even from what you wrote that should have been clear to anyone not overly emotionally invested in the particular technologies you were discussing. The comment about being perfectly willing to start a green-field project in Rails should have made that clear.
I also liked the part about liking SQL. I'm finding more and more that ORMs are just getting in my way and making my code longer, slower, and harder to understand.
I think that was an important point, but not the central point. I think more important was his argument that if you are using a tool and doing something significantly different from it's intended purpose then you're better off rolling your own; and php is a fine enough tool for the job. Not that it's pretty or anything though :-/
I would't take it that hard, it is impossible to name two languages in one sentence without getting a pile of dirt thrown at you (from both sides, and possibly an unexpected third).
Nothing wrong with your writing, but it's nice to see you striving to do better.
This article was written in 2007. Since then both PHP and Rails have undergone considerable changes making much of what is being said only of historical interest.
This is supposedly a site about news which by implication is not something that happened three years ago, unless you have been living in cave.
Old articles can be interesting, for some value of interesting, but this does nothing for me as either a Rails developer or a PHP developer. I can see no reason to post this or perhaps I should hunt down some old articles about the deficiencies of Java 1.0?
If a Rails developer has switched from a current version of Rails to the new version of PHP I would be interested but even with that being said the article is comparing a programming language to a web framework. Ruby is not Rails just as PHP is not Drupal.
There really isn't anything specific in the article that makes it significantly dated. His reasons would be just as valid if he'd written this yesterday about the latest and greatest PHP and Rails versions.
1 - He felt he could get what he needed to get done in PHP just as well as in Rails
2 - Integration costs of One Grand Switch from existing large PHP codebase to entirely new Rails codebase were high
3 - Felt no need for most of the infrastructure Rails provides, was too complex for him to understand easily
4 - Better performance
5 - Easier integration (due to 1 & 3, presumably)
6 - Didn't want/need an ORM layer and related handholding and/or headaches
7 - Rails/Ruby were better for him to lift ideas from than to actually use directly
I can't think of anything so dramatic that's happened to PHP and Rails since Sept 2007 to really make his reasoning of 'historical interest only'. Certainly nothing like the change from Java 1.0 (a small, sluggish language released 14(!!) years ago) and Java today (huge ecosystem of products, languages, frameworks running on one of the faster VMs/JITs around).
It's obviously untrue for 'any two technologies'. And I don't know about you but I like to assume that if the author's 'real message' was 'don't rewrite working code from scratch' he'd have simply said that. Are you suggesting he put the effort into summarizing his particular experience while having some secret and entirely different message? What makes you believe that?
Submissions have to be either new or interesting. There are a lot of submissions that aren't necessarily new, but still have interest for this community judging by the votes. An example that's on the frontpage right now is this: http://news.ycombinator.com/item?id=1051493 which is from 2007.
Personally I think the linked article is interesting because of some of the truths hiding between the lines such as this one: "But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now! You look back at your old ugly PHP code, compared to your new beautiful Ruby code, and think, “God that PHP is ugly!” But don’t forget you wrote that PHP years ago and are unfairly discriminating against it now."
He also learnt new approaches from Ruby - reminds me of esr's "learn lisp to improve your coding, not necessarily to use it".
It also seems he became something of a coding god, especially in his domain, able to create frameworks he needed - on demand. It's impressive to be able to create those tools, but even more impressive to realize what you need - and then for the tools to be both actually useful and usable. Generally, it's said to be a bad idea to write your own tools - unless you can (i.e. have the ability), says Alan Kay, because then you can create just the right tool for the job. Though perhaps no one else quite understands them, not being gods, and so they need to rewrite in aspx.
I like his non-coding observation. GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE * YOU * ARE BETTER
He intimately understood exactly what his application needed, and had working code to start from. I think that was what enabled him to build the tools he needed.
PHP is a "framework" in the sense that it provides the core mechanisms for doing webby things - accessing query string and POST variables, sending HTTP headers, reading cookies, mapping URLs to executable code.
I actually think comparing stand-alone PHP to frameworks like Rails or Django is reasonable, since they all solve the same problem. Of course, such a comparison should also take the existence of higher level PHP libraries and frameworks in to account - it would be silly to criticise PHP for not shipping with an ORM, for example.
To some degree it is relevant (it's not about fixing the transmission of a Ford Cortina) just not very relevant given the changes both languages have undergone in the intervening times.
If you are a PHP programmer how would you view an article about someone who started to use Drupal found that they didn't like some aspects of it and switched to programming in Java. You would probably think that giving up on PHP because of a framework when there are plenty of others to choose from was pretty short sighted and was representing PHP unfairly.
This is why comparing Rails, which is a framework, to PHP, which is a programming language, feels wrong. Rails is not the only framework, it just feels like it :D
I've worked with PHP in the past, and occasionally still do when the situation demands it. I've also built web apps using Ruby, with Rails and without a framework. All of the following are possible options for building a website:
* Bare PHP
* Bare Ruby (but you probably should not use mod_ruby)
* PHP and a framework
* Rails and a framework
From a pure language perspective, I'm willing to declare Ruby superior without hesitation. It's cleaner, and it's more powerful. Ruby seems to have had a fairly clear vision from the beginning, while PHP has accumulated features over the years, sometimes without regard to how well those features might work together.
If you just need to get something done, you should use what you're familiar and comfortable with. No advantage of any of these options is as important as the programmer's ability to use the tool.
Frameworks are opinionated. The purpose of a framework is to take away the work of making certain kinds of decisions. If your opinions clash with those of the framework, the project isn't going to go well. Rails is of the opinion that the database should have a certain sort of schema, and be abstracted away by ORM. If you like SQL, don't use Rails. If you have a complex existing database, and you want to keep it instead of moving the data to a Rails-friendly schema, don't use Rails.
The article doesn't really serve as a comparison of PHP and Rails. It's just a story about what happens when a tool is a poor fit for a project.
I guess it's not quite as reflective as that girlfriend thing, but I strongly suspect that everyone who actually succeeds in releasing working software to the world has an "I said fuckit" moment.
I care less about the PHP/Rails thing, which is probably what got everyone riled up. To be, this could have been about tech A and tech B. I just like hearing that people who have succeeded in writing software that others use eventually feel this way, cause man do I ever sometimes.
The points raised in the article are still relevant today. Not that you can't do good web sites with Rails, but sometimes it is easier to use the tool you are more familiar with.
Funny comment:
"PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS".
Like Ada and Linda:
http://c2.com/cgi/wiki?LindaEtymology.
If a langage was a girlfriend, what would be the equivalent of _ ?
the worst carpenter on the planet is the one who whines about the tools he/she has at hand to complete the task, cheeky because he/she doesn't have his or her favorite hammer around.
the best carpenter is the one who gets the job done with the tools at hand. go php. there are just bad programmers, not bad tools.
I would have to disagree with you when you say there are no bad tools. Try frame a house using a brick, or perhaps a sledgehammer.
Software is the same, for example, C is a bad language to use when creating a website, its possible, but not a good idea.
Even the best carpenter in the world isn't going to produce his best work if you force him to use a blunt $3 chisel. Conversely hiring the best carpenter in the world and trying to save money by making him use a blunt $3 chisel is a huge waste of money.
Sure a great carpenter will be able to produce good work even with bad tools, but if you want him to produce his best work you have got let him work with what he considers the best tools.
I would agree with hackermom. Of course, there are tools that may adhere to some standard better than others, but who is to say that adhering to a particular standard is the right move every time? And to what degree should a tool adhere to said standard before it becomes magically "good"?
Without context of the given problem at hand, the timeframe to complete the project, and the skillset of those involved, it's naive to make a blanket statement saying there are just plain bad tools.
In my humble opinion, tools should enable you to get your job done faster and at a higher quality than had you not used the tools. The more skilled a programmer is, the more variation there is in leveraging a tool for the end goal. This goes for any framework and any language.
Seems like people are forgetting that there are a lot of very handy functions built into PHP5 that make life simple for the web developer. Yes, some args are inconsistently ordered, and naming conventions are not the most consistent. Still, the fact of the matter that there are several high-quality frameworks available for PHP5 that are as strict or loose as you like speaks to me that PHP--like Ruby or Python or Perl--is a platform that at allows people to get things done. Isn't that the point, after all?
> the best carpenter is the one who gets the job done with the tools at hand. go php. there are just bad programmers, not bad tools.
It really depends on your subjective view of what "best" means.
The best programmer in the world can probably do a better job than you at any given task, using only the GCC compiler.
But ... I'd bet he's going to cost you hundreds of dollars per hour, and he probably wouldn't get the job done faster that a decent programmer who is using "the right tool for the job".
Good design / Low cost / Fast ... pick 2
Myself ... I could use PHP, since it's mainstream and there are lots of low-cost hosting solutions, but I prefer Python because the tools are more mature and not necessarily related to web-dev (iPython, PyQT, Nltk, numpy, Django) ... and really, I've worked with Symfony, Django, ASP.NET MVC, Ruby on Rails and Perl's Catalyst ... the quality of a framework is heavily dependent on the language, trust me ;)
Fairly interesting that they've now jumped ship again to aspx. I guess Sivers gets an itch any time a new web language turns the corner. What's worse is that CD Baby feels considerably slower than when I used it ages ago.
No no no. That apsx crap running the existing site is absolutely not mine.
I sold the company in 2008 to Disc Makers, a company whose internal systems are all Windows.
After leaving the site as it was (FreeBSD + PHP + MySQL + Ruby) for a year, they rewrote it all from scratch in Windows ASP stuff, so they could merge it with their existing systems.
I was long-gone and knew nothing about their rewrite until it was launched.
Funny thing is: when I sold the company, people kept asking, "How does it feel that it's not yours anymore?" It was always fine and didn't phase me a bit because it was still my software running the site. It still felt like my vision was upheld.
But when they trashed all my old software (even the internal intranet that all employees use to run operations!) - THEN it hurt. A single "View Source" on any page of cdbaby.com shows a bloated mess of crap that goes completely against the minimalist aesthetic that drove CD Baby for 10 years. That was really sad.
But, like the new owners painting your old house pink, it was the final proof that it's not mine anymore.
So it's crap only because it's aspx ? You don't know how the code looks on the server side, and it's not fair to judge a webapp by the resulting html alone.
> A single "View Source" on any page of cdbaby.com shows a bloated mess of crap that goes completely against the minimalist aesthetic that drove CD Baby for 10 years.
That's nothing to do with aspx, that's to do with wrecking a philosophy.
Aspx was the chosen tool to do the wrecking in, but that could have been anything else. You can write bad bloated code in just about any language.
To me, posting this article in 2007 taught me two lessons:
#1: The goal of good writing is not to be understood, but rather to not be misunderstood.
Judging by the hundreds of angry comments on that original link, I failed miserably. At the time, nobody read my little blog, so I didn't expect anyone to see this post. I was really just writing it to answer a few of my Rails friends' questions. I didn't brace it for public attack.
#2: The public you is not you.
I'm a mediocre programmer, trying to improve, and at the time just trying to make my website the way I wanted it. So it kinda hurt at first to read hundreds of fellow programmers saying I'm the biggest idiot to walk the earth.
Then I just realized that my post should have been written clearer, and the reason people were so upset is because it sounded like I was attacking this framework/language that they had spent so many hundreds of hours learning. It had nothing to do with me. Only I know my real programming skills, so their comments were not really about me.
Ever since then I don't let comments get to me, either way. Neither praise nor criticism should be taken personally. It's just feedback on the post/subject. Useful for learning how not to be misunderstood, but has nothing to do with you.