

Quick doesn't have to mean dirty - ryannielsen
http://me.veekun.com/blog/2012/07/28/quick-doesnt-mean-dirty/

======
freshhawk
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).

------
therealarmen
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?

~~~
eevee
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
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
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
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.

~~~
eevee
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.

------
mikescar
> 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.

~~~
eevee
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.

------
Produce
> 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.

~~~
eevee
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.

~~~
aangjie
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.

~~~
eevee
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.

