Re: The plus plus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux