I also thought this argument was obvious, even though people clearly didn't think so, but I'm glad you did such a good job explaining the point.
> when did learning become bad?
This is when you hit on what I think people mean when they use the "just get stuff done" argument. What they mean is they can get stuff done now, without having to learn anything along the way or think too hard.
Sometimes that's defensible, deadlines and real life and all. Most of the time it's defensiveness because they know they are getting less stuff done and that stuff is lower quality because they didn't take the time to learn better tools and stuck with the training wheels.
> hip guys in class who write cool code in Ruby or Python
How out of touch do you have to be to think that people are using Ruby or Python because they are hip unknown languages? I have literally gotten this same statement thrown at me (to be fair, he had two young kids so he really was out of touch and had good reason to be).
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?
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.
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.
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.
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.
Cars and spaceships built on existing engineering and physics principles. We've never had anything like programming. We can't even decide if it's a math, a science, or some kind of engineering.
We have languages with built-in async support (and some that fake it decently), languages with syntax for safe and unsafe pointer use, languages that bundle impurity away from everything else.
It's a slow process, since any new language has a massive uphill battle to gain any traction. But I think we're getting there.
"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.
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!
> most of PHP’s trade immediacy for the slightest hint of reliability.
This article is a list of best (or at least the author's favorite) practices for Python.
I'm so tired of reading a person banging on PHP and then hyping up best practices for another language. As if nobody can be productive with PHP or would choose it for a new project. Or that PHP doesn't have better practices than what the authors have experienced.
If you like Python, that's great. So do I. Just get over it, these threads are so lame.
You're quoting from a paragraph about tradeoffs in core language design. That's not the same as best practices, though the latter often exist to avoid pitfalls in the former.
> I use Python because it balances getting stuff done with having that stuff not fall over as soon as I turn my back.
Uhh... Heard of automated testing?
It makes absolutely no difference what language you write your code in, whether it's PHP, Python or Brainfuck - reliability is dictated by your testing strategy, not the language. In the PHP applications I write, the only things that break are the things I didn't test.
Have you tried automated testing on a large complex web application? It's an insanely monumental task.
I actually mentioned Haskell in the post because coworkers have lamented not having its type system, which would immediately find problems at compile-time that we otherwise have a very very hard time thoroughly covering with tests.
Hi, Can you elaborate a little more on some use-cases or some examples from your troubles?. Am writing a web application(moderately complex) in python and find myself annoyed by the amount of unit test cases needed. My reaction so far has been to write them whenever i seem to test more than a couple of times. But, have a feeling dynamic typing is actually creating problems by enlarging the number of test cases. Don't know enough haskell to comment on it's type system, but curious to learn. P.S: Feel free to mail me, if you don't want it to be blog post.
There are plenty of cases where a data type doesn't sufficiently capture semantics, and without static typing, Python isn't very well built for checking that values have the right semantic type. A float could mean money or time or a percentage; a string could be plain text or HTML or JavaScript or a filename.
The really really hard part is still checking that a given page "isn't broken"—something that's easy for a human to spot but hard for a computer—for all possible combinations of state. But very strict typing would at least make the output less likely to break.
>Have you tried automated testing on a large complex web application? It's an insanely monumental task.
What's so insanely monumental about writing unit, functional (i.e. like these http://symfony.com/doc/current/book/testing.html#functional-...) and Selenium tests to cover everything before committing new changes? It's just like any other code - test the main condition and edge cases and everything will be running smoothly next time you come back to that feature.
This is quite the oversimplification of the value vs. costs of automated testing while also being completely orthogonal to the discussion. I'd never accept "automated testing" by itself as a strong argument to prefer PHP or anything for that matter.
I merely provided a rebuttal to the argument that PHP, or any other language, for that matter, is unreliable. I did not make the case that automated testing somehow makes PHP a preferred choice. How you test the code is what dictates reliability, not the language.
I'm not sure how you can possibly separate the concept of a rebuttal from that of making an argument. And as I've alluded, how you test code does not, in fact, dictate any form of quality or reliability in and of itself.
> when did learning become bad?
This is when you hit on what I think people mean when they use the "just get stuff done" argument. What they mean is they can get stuff done now, without having to learn anything along the way or think too hard.
Sometimes that's defensible, deadlines and real life and all. Most of the time it's defensiveness because they know they are getting less stuff done and that stuff is lower quality because they didn't take the time to learn better tools and stuck with the training wheels.
> hip guys in class who write cool code in Ruby or Python
How out of touch do you have to be to think that people are using Ruby or Python because they are hip unknown languages? I have literally gotten this same statement thrown at me (to be fair, he had two young kids so he really was out of touch and had good reason to be).