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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
