Es gibt 54 Zitate in dieser Kategorie.
...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
All editor programmers are deemed to re-create emacs again, unless they're writing emacs.
Richard P. Gabrielhttp://dreamsongs.com/ObjectsHaveFailedNarrative.html
And as a result we find that object-oriented languages have succumbed to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair.
Any code of your own that you haven't looked at for six or more months might as well have been written by someone else.
Any company large enough to have a research lab is too large to listen to it.
Any comparison of hot JVM languages is likely to note that "Clojure is not object-oriented." This is true, but it may lead you to the wrong conclusions. It’s a little like saying that a rifle is not arrow-oriented.
As much as I love a debugger, it is disheartening to need to use it to understand my code.
Grady BoochIEEE 3/4 09, p. 12
Beauty has its place, but the search for beauty in software - indeed in most things - at the expense of value is an empty pursuit.
Debugging is twice as hard as writing the code in the first place. Therefore, if you wirte the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.
For optimisation, more is known about a program written in a dynamically typed language at runtime than is known about programs in statically typed languages at compile time
Steve McConnellCode Complete
Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?' Improve the code and then document it to make it even clearer.
Sir Charles Antony Richard (C. A. R.) Hoarehttp://lambda-the-ultimate.org/node/1446 - Out of the Tarpit
I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
I did say something along the lines of "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows your whole leg off."
I do my Java editing in Eclipse now. It doesn't work as well as EMACS
once did, but it works better than EMACS does now.
I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.
I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end.
I should not choose long, hard words just to make other persons think that I know a lot. I should try to make my thoughts clear; if they are clear and right, then other persons can judge my work as it ought to be judged.
I think programmers have become inured to incidental complexity, in particular by confusing familiar or concise with simple. And when they encounter complexity, they consider it a challenge to overcome, rather than an obstacle to remove. Overcoming complexity isn't work, it's waste.
I think programmers have become inured to incidental complexity... when they encounter complexity, they consider it a challenge to overcome, rather than an obstacle to remove.
Overcoming complexity isn't work, it's waste.
I would compare the Smalltalk stuff that we did in the '70s with something like a Gothic cathedral. We had two ideas, really. One of them we got from Lisp: late binding. The other one was the idea of objects. Those gave us something a little bit like the arch, so we were able to make complex, seemingly large structures out of very little material, but I wouldn't put us much past the engineering of 1,000 years ago.
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilisation.
If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.
It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.
Java and C# are both such stifling languages that you need to be able to use code generators to make them effective.
Make it work. Make it right. Make it beautiful. Make it fast.
Meta means that you step back from your own place. What you used to do is now what you see. What you were is now what you act on. Verbs turn to nouns. What you used to think of as a pattern is now treated as a thing to put in the slot of an other pattern. A meta foo is a foo in whose slots you can put foos.
Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. Alan's breakthrough in object oriented programming, wasn't objects, it was the realizing that the Lisp metasystem was what we needed.
Old friends are more fun to visit that old code.
Only a subset of all possible programs can be written with statically typed languages. For some people that is enough.
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Our ability to imagine complex applications will always exceed our ability to develop them.
Out of the Tarpit - http://lambda-the-ultimate.org/node/1446
Simplicity can only be attained if it is recognised, sought and prized.
Structure is nothing if it is all you got. Skeletons spook people if they try to walk around on their own. I really wonder why XML does not.
Steve McConnellCode Complete
Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don't improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better.
Testing is the engineering rigor of software development.
Edsger Wybe Dijkstra
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
DilbertIEEE 11/12 2008, p. 35
The goal of a software engineer is to retire without having caused any major catastrophe.
Sir Charles Antony Richard (C. A. R.) HoareOut of the Tarpit - http://lambda-the-ultimate.org/node/1446
The price of reliability is the pursuit of the utmost simplicity.
The real romance is out ahead and yet to come. The computer revolution hasn't started yet. Don't be misled by the enormous flow of money into bad defacto standards for unsophisticated buyers using poor adaptations of incomplete ideas.
inspired by http://www.codinghorror.com/blog/archives/001299.html
the road to hell is patched with patches
There are two ways to try to make a software system reliable: make it so simple that it obviously has no bugs, or make it so complicated that it has no obvious bugs.
IEEE 3/4 09, p. 68
There's nothing wrong with plan-driven, waterfall-based, document-centric approaches.
They're just not suited to controlling complex activities like software development.
Reg BraithwaiteReg Braithwaite
This is not a trivial exercise. And yes, you can shoot yourself in the foot if you aren't careful. But in the end, there's two kinds of programmers in the world: those with dangerous techniques and those who dig.
Eric S. Raymond
Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.
Ralf Westphaldotnetpro 9.2008, 64f.
Unterm Strich geschieht Softwareentwicklung also in einer monolithischen, hierarchischen Atmosphäre, die sich nicht grundsätzich von einer Fabrik des 19. Jahrhunderts unterscheidet.
Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects.
Edward V Berardhttp://stackoverflow.com/questions/58640/great-programming-quotes/58806#58806
Walking on water and developing software from a specification are easy if both are frozen.
Donald E. Knuth
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Tony ClarkIEEE Software Sept./Oct. 2010 p. 63
What became UML 2.0 is generally regarded as something that is good for growing roses, but it is less useful for flexible systems engineering.
Where's the domain specific language for the domain of software programming?
[Lisp is] "the greatest single programming language ever designed"