| > just shifts how I encode the solution And this is actually the most important thing in industry software development. It affects: 1. how easy it is to modify an existing codebase: eg., can you add feature X before your competitor even after you app grew to 1M LOC? 2. how easy it is for a new developer to start working productively on you codebase 3. how stable your software is: do modifications introduce subtle bugs that make the whole thing more and more unstable until it becomes unusable? 4. how secure your software is: how easy (read "cost effective") is it to write secure code without having to take 10x longer to do this? From a business perspective, the "fundamental bottleneck is always what's in your head" problem can always be solved by temporarily hiring a few super-smart consultants with "bigger heads" that can get over this bottleneck, the rare times when you have the problem... The rest of the time, the "shape of your code" is 100x times more important than the abstract formulation of an elegant solution. Because what you do 99% of the time is "re-shaping" existing code to do slightly different versions of what it already does, not solving interesting problems... So yeah, at this level, languages can make all the difference! |