3 ms·

Author's anger is misdirected here. The core thesis of the TechCrunch article -- shipping some working PHP code is approximately a million times better than des

Author's anger is misdirected here. The core thesis of the TechCrunch article -- shipping some working PHP code is approximately a million times better than designing something mindblowing in Haskell that never actually ships -- is true. If your team can get a Python project out the door faster than one written in PHP, go with Python. And vice versa. Users don't care what language it's written in, so why should you?

rdw 14y ago
Completely agreed that getting it out the door is the real core problem. However, there seems to be a meme that PHP is somehow a panacea for getting things out the door, as if suddenly upon picking up the PHP shovel, the programmer realizes how much time he was wasting having a real equality operator, and bangs out a solution in no time. I've seen the exact opposite: at least three PHP projects that got snowed under by "attempting to write something mindblowing", and zero Python projects that had the problem. I think that the truth behind the meme is that there is a certain level of intermediate programmer who has learned that doing things right saves time in the end, but hasn't yet internalized YAGNI and KISS. So this programmer discards PHP and picks up another language and is all excited about this new world of doing things robustly! "I'm going to write the best UUID generator. I'm going to unit test every line of the admin console. I'm going to make an ORM that batches queries in the most efficient way." And because these things weren't necessary, and the programmer is still intermediate, they can't get those things done and get the actual application done in anything approaching reasonable time. If the programmer is forced to use PHP, basically the same thing happens; just with object inheritance, and curl_multi, and novel configuration file formats, and so on. It's a cliff of enlightenment, and if you fall off it too hard, you might reject the enlightenment itself. Ignorance is bliss!
nnq 14y ago
"Users don't care what language it's written in, so why should you?" ...uhm ...because YOU are the one WRITING it? and because your productivity matters, and you learning how to do better things or expand your mind or learn new things matters and because your enjoyment matters (and if you don't write code because you enjoy it, then you shouldn't be a programmer, so just pick another job, PLEASE!) I think all good programmers should be somewhat selfish and care about their needs, not just the user's, because this helps them grow and makes them better, which in the long run is better for the user too. The "user doesn't care" mentality embraced by so many managers leads to lots of long-run pain and sometimes, paradoxically, even to business failures, because not keeping your "coders" (I utterly dislike this word, btw) happy is really BAD for business.
eevee 14y ago
That thesis reflects a common false dichotomy that many programmers (who often have only used PHP!) seem to actually believe: that anything written in a non-scruffy language won't ever ship because the authors will be too busy sipping lattes and debating type polymorphism. That persistent belief is what I (the author) find annoying. The underlying point here is that you can get something out the door quickly and have it not be a Jenga tower held up by duct tape. I'm sure there are plenty of people who can do that with PHP and I don't mean to imply otherwise; I'm only asserting that it can also be done with Python.
- gbog 14y ago
  Hi, nice article of yours, thanks. I think you could even go further: doing things The Right Way is not slower than doing them "dirty", it is actually faster. Those "quick and dirty" guys always throw some "god machine" thing that never worked as an example of The Right Thing. It is wrong. The Right Thing is just the correct amount of forethought and architecture for the problem at hands. The Right Thing leads to no overengineering, because overengineering is wrong. Doing The Right Thing leads to things like Vim, Git, Python, Postgres, coreutils, etc. Note that none of these is perfect. But they have 1) sane basic assumptions 2) some level of internal coherency that allow them to be reliable tools one can build upon.
  - eevee 14y ago
    Hey, thanks. :) The problem with evangelizing the Right Way is that the benefits tend to come later; if you haven't experienced the pain of dealing with the Wrong Way's fallout once it hits critical mass, it seems easy to brush off. "SQL injection? Pfft, no one cares enough to attack my site." "Transactions? I only write one or two rows at a time anyway." "Templates? What's wrong with string formatting?" Our profession is a bit lacking in context. Nobody believes the lessons of others. (Granted, we're so crazy that half the time we learn the wrong lessons.) Still a young discipline, though. Maybe we'll grow out of it.
    - gbog 14y ago
      Not only true for web dev, true for all software related stuff. I listened to a podcast of a bunch of conferences held in the 90s about software. The most clever guy of the bunch did say something that stroke me as very true and very important, but so big and so scary that no one seem to see it: the simple fact that we have absolutely no idea about what the object "software" really is. We know what are cars pretty well, and spaceships too. We know how they work, how to build them so they don't break easy, how to check for their health, etc. But we have no firm grasp on software, we have no (economically sustainable) way to build them rationally and safely. Bugs are piling and the more we remove the more they are. No widely accepted method allow us to build software that has a quantifiable guarantee to work as planned under a fixed approximation interval. Etc. We programmers know that. Software development is at alchemy (magic) stage. Funilly, this guy did specially point at OOP, saying that this was adding even more uncertainty to the mess. All that is well explained in SICP, and FP might be one of the strings we should pull to us out of the dark ages of software engineering. IMO.

rdw 14y ago

Completely agreed that getting it out the door is the real core problem. However, there seems to be a meme that PHP is somehow a panacea for getting things out the door, as if suddenly upon picking up the PHP shovel, the programmer realizes how much time he was wasting having a real equality operator, and bangs out a solution in no time. I've seen the exact opposite: at least three PHP projects that got snowed under by "attempting to write something mindblowing", and zero Python projects that had the problem. I think that the truth behind the meme is that there is a certain level of intermediate programmer who has learned that doing things right saves time in the end, but hasn't yet internalized YAGNI and KISS. So this programmer discards PHP and picks up another language and is all excited about this new world of doing things robustly! "I'm going to write the best UUID generator. I'm going to unit test every line of the admin console. I'm going to make an ORM that batches queries in the most efficient way." And because these things weren't necessary, and the programmer is still intermediate, they can't get those things done and get the actual application done in anything approaching reasonable time. If the programmer is forced to use PHP, basically the same thing happens; just with object inheritance, and curl_multi, and novel configuration file formats, and so on. It's a cliff of enlightenment, and if you fall off it too hard, you might reject the enlightenment itself. Ignorance is bliss!

nnq 14y ago

"Users don't care what language it's written in, so why should you?" ...uhm ...because YOU are the one WRITING it? and because your productivity matters, and you learning how to do better things or expand your mind or learn new things matters and because your enjoyment matters (and if you don't write code because you enjoy it, then you shouldn't be a programmer, so just pick another job, PLEASE!) I think all good programmers should be somewhat selfish and care about their needs, not just the user's, because this helps them grow and makes them better, which in the long run is better for the user too. The "user doesn't care" mentality embraced by so many managers leads to lots of long-run pain and sometimes, paradoxically, even to business failures, because not keeping your "coders" (I utterly dislike this word, btw) happy is really BAD for business.

eevee 14y ago

That thesis reflects a common false dichotomy that many programmers (who often have only used PHP!) seem to actually believe: that anything written in a non-scruffy language won't ever ship because the authors will be too busy sipping lattes and debating type polymorphism. That persistent belief is what I (the author) find annoying. The underlying point here is that you can get something out the door quickly and have it not be a Jenga tower held up by duct tape. I'm sure there are plenty of people who can do that with PHP and I don't mean to imply otherwise; I'm only asserting that it can also be done with Python.

gbog 14y ago
Hi, nice article of yours, thanks. I think you could even go further: doing things The Right Way is not slower than doing them "dirty", it is actually faster. Those "quick and dirty" guys always throw some "god machine" thing that never worked as an example of The Right Thing. It is wrong. The Right Thing is just the correct amount of forethought and architecture for the problem at hands. The Right Thing leads to no overengineering, because overengineering is wrong. Doing The Right Thing leads to things like Vim, Git, Python, Postgres, coreutils, etc. Note that none of these is perfect. But they have 1) sane basic assumptions 2) some level of internal coherency that allow them to be reliable tools one can build upon.
- eevee 14y ago
  Hey, thanks. :) The problem with evangelizing the Right Way is that the benefits tend to come later; if you haven't experienced the pain of dealing with the Wrong Way's fallout once it hits critical mass, it seems easy to brush off. "SQL injection? Pfft, no one cares enough to attack my site." "Transactions? I only write one or two rows at a time anyway." "Templates? What's wrong with string formatting?" Our profession is a bit lacking in context. Nobody believes the lessons of others. (Granted, we're so crazy that half the time we learn the wrong lessons.) Still a young discipline, though. Maybe we'll grow out of it.
  - gbog 14y ago
    Not only true for web dev, true for all software related stuff. I listened to a podcast of a bunch of conferences held in the 90s about software. The most clever guy of the bunch did say something that stroke me as very true and very important, but so big and so scary that no one seem to see it: the simple fact that we have absolutely no idea about what the object "software" really is. We know what are cars pretty well, and spaceships too. We know how they work, how to build them so they don't break easy, how to check for their health, etc. But we have no firm grasp on software, we have no (economically sustainable) way to build them rationally and safely. Bugs are piling and the more we remove the more they are. No widely accepted method allow us to build software that has a quantifiable guarantee to work as planned under a fixed approximation interval. Etc. We programmers know that. Software development is at alchemy (magic) stage. Funilly, this guy did specially point at OOP, saying that this was adding even more uncertainty to the mess. All that is well explained in SICP, and FP might be one of the strings we should pull to us out of the dark ages of software engineering. IMO.