[nailer]

> Just because modern dynamic frameworks abstract away lots of "hard" stuff does not mean that your dreams wont come crashing down without any understanding of computational complexity theory etc.

Your post is missing any supporting arguments for this claim.

I know a lot of 'Rails guys' and their dreams certainly aren't crashing down. If anything, they enjoy their lives more because their programming education has been focused on making things, before making things fast.

Conversely, there's a lot of guys with CS degrees who ended up jaded with the idea of making things and became Unix admins, mid-level managers, or PMs.

[JonnieCache]

>Your post is missing any supporting arguments for this claim.

We all know rails has problems with scale, and that these problems can be overcome. The way to overcome these problems is through optimal and performant coding/data-storage patterns, and to practice these one requires knowledge of CS-type matters.

Now Rails or Rails-esque apps obviously will not encounter these issues until they reach a certain size. Therefore unless one has the requisite CS-style acumen, one's projects have a cap on their maximum success/popularity.

Assuming that when we say "dreams" we are referring to hackers' projects becoming big and successful and popular, (thats what everyone around here seems to dream about,) they will not be realized without someone around who knows their big O from their divide and conquer.

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