The plus plus

[Andy Green]

Steffen Kluge wrote:
> On 04/11/2006, at 3:31 AM, Andy Green wrote:
> 
>> Therefore it does matter what language you are using, it does affect 
>> how you come at a problem, how you can consider a solution, and how 
>> successful you will be with the implementation.  In short you cannot 
>> correctly choose an architecture without deeply understanding the 
>> constraints of the implementation, and that inevitably includes the 
>> abilities of the language.
> 
> I guess this is where we disagree. No modern programming environment 
> imposes limits on the software engineer that requires him or her change 
> the software design. If it does then the software engineer is misguided 
> and tool-centric.

Well nobody can argue with such a proposition, since you already defined 
any choices that do not agree with your concept as "misguided and 
tool-centric", as if that is invalid.  My point was and remains that we 
all have to be tool-centric, since we will in fact be using one compiler 
or assembler or another, and the scope of what we can safely expect to 
achieve is defined by the tools we expect to use.

> I'm old fashioned (not 1970's as you guessed but 1980's) and I think 

You said 30 years ago, by my math that means 1970s.

> software engineering is 90% paper and pencil. This doesn't sit at all 
> well with geeks who can't be dragged away from the keyboard. But if you 
> design as you code (within the constraints of your development 
> environment) you are bound to make fundamental design errors. Design 
> versus implementation, such an old mantra I'm almost embarassed to 
> repeat it.

This is nothing to do with anything.  For sure somebody who meditates 
and muses on the abstract problem first will likely come to a better 
solution.  My suggestion is that the set of *genuinely achievable* 
solutions depends on the tools used.  Put another way, the gibbering 
drooling autistic machinecode man, skilled as he might be, cannot solve 
problems of the same complexity as the C++ guy.  And it is because of 
the power of his tools, not because of some error that he started coding 
before he thought long enough.

Your brain is only so big, you only have to place one palm at the your 
forehead and one at the back of your head to realize this.  If you waste 
your finite brainspace on detail that does not advance the solution of 
your problem in the abstract, then that processing is not available for 
work that DOES advance your solution.  Therefore a language that moulds 
itself more cleanly to a resolution of your true problem will help you 
more than one that demands you track what is in the carry flag: the 
carry flag has no direct bearing on your abstract problems.  It is some 
poisonous implementation detail your choice of language is meant to save 
you from.

> Here's a challenge: design the most ambitious software project you can, 
> and then point out any of our modern programming languages you cannot 
> use to implement your design. Performance doesn't count, since we're 
> trying to prove that choice of tools doesn't limit imagination.

Yeah in theory you can make a turing machine that can do anything that 
is possible computationally.  But we don't talk of theory.  In fact, 70% 
of IT project fail[1].  Your point is that choice of language has no 
bearing on if you win or lose, my point is that it is crucial, and is 
why KDE continues to forge ahead despite the onslaught of the brave 
Gnome knights.

-Andy

[1]
http://scholar.google.com/url?sa=U&q=http://www.diva-portal.org/diva/getDocument%3Furn_nbn_se_hj_diva-519-1__fulltext.pdf
see p7