[nailer]

All languages have problems with scale, including C and Java, which most programmers don't know how to deal with either.

If you can make something (or likely many things, quickly) you can be lucky enough to get the point where scale is a problem. At which point you can pick up these skills where you need them - they're not difficult, especially if they directly apply to a problem domain you're working on rather than a arbitrary one.

The Rails guys I know who these issues typically end up with a quick move to JRuby and pick up what they need.

If you can't make something quickly, all the premature optimization won't help you with the problems you'll never have.

[gloob]

I'm afraid I might have misunderstood you, but you seem to believe that having a reasonable understanding of compsci counts as premature optimization, and is therefore somewhere between "a waste of time" and "actively harmful". Is that the case? Or are you playing devil's advocate? Or what?

[nailer]

Not quite. I believe that the emphasizing scalability and efficiency over actually making something is wrong.

I also believe that teaching algorithms before logic and engineering concepts is wrong.

I would rather hire someone who has made more apps than someone who has excellent knowledge of algorithms but has made no apps. Would you?

[mquander]

I would rather hire someone who has made more apps than someone who has excellent knowledge of algorithms but has made no apps. Would you?

This is rather a false dichotomy, isn't it? Who can obtain "excellent" knowledge of algorithms without ever making anything? Very few people can learn so much without ever doing.

Nobody is suggesting that it's better to not make something than to make something. The real suggestion is that it's better to make something good that you won't have to throw out later than to make something substandard, born of ignorance. Having reasonable background knowledge about algorithms, data structures, and architecture makes it much easier to get it right than if you're solving those problems as you come to them.

[nailer]

Its not a false dichotomy at all. Don Knuth hasn't made a successful product, the original stated goal of TeX (see http://en.wikipedia.org/wiki/TeX) was never achieved and most folk who require typesetting neither use the product or know of its existence. Knuth's knowledge of algorithms is excellent, but try and submit a usability bug for TeX like it was a real product. Academics focus on very specific areas of computing, sometimes at the expense of broader knowledge. If I had a web app to make, I'd hire the rails guy that had made a successful app before I'd hire Knuth.

> Nobody is suggesting that it's better to not make something than to make something.

Certainly. But they do focus on optimization as the core of programming. It isn't - turning logical problems into code - aka, making programs - is.

[mquander]

I'll take your word for it with TeX; I use LaTeX and I know other people who have, but I don't know what professional authors or publishers use for typesetting.

However, I think your specific example doesn't reflect the argument I imagined you making. Your comparison is someone smart who doesn't know the tools (Ruby, Rails, Javascript) with someone who knows them well. If it were a short project, at least, I agree with you; I'd probably take the guy who knows the tools.

[nailer]

It's not even the tools, it's things like iterating quickly, having working code, good deployment tools, understanding of usability, etc. Nobody has an unlimited amount of time. And sometimes the people who kick ass at algorithms don't give a damn about anything else (and if they're academics that fine). The 'Rails guys' won't have their dreams crushed by performance issues. They'll learn what they need - in fact, since most web app performance is IO bound that's often the first thing they learn to optimise.