Computer Scientists

"Talk is cheap. Show me the code."

"Note that nobody reads every post in linux-kernel. In fact, nobody who expects to have time left over to actually do any real kernel work will read even half. Except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea. None of the individual gnomes read all the postings either, they just work together really well."

"I'd like to say that I knew this would happen, that it's all part of the plan for world domination."

"I was thrown out of fourth grade because I couldn't write my own name, and it's been all downhill from there."

"If Microsoft ever does applications for Linux it means I've won."

"My name is Linus Torvalds and I am your god."

""Regression testing"? What's that? If it compiles, it is good; if it boots up, it is perfect."

"(In answer to the question: In the extreme case, if it was just you doing all the code, and the rest of the world quietly used it, would it make sense to give it away free? Unless you're particularly grateful for other free things you've got off the Net, would the answer be No?":)"

"Making Linux GPL'd was definitely the best thing I ever did."

"The main reason there are no raw devices [in Linux] is that I personally think that raw devices are a stupid idea."

"…the Linux philosophy is "laugh in the face of danger". Oops. Wrong one. "Do it yourself". That's it."

"If you still don't like it, that's OK: that's why I'm boss. I simply know better than you do."

"Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it ;)"

"See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too ;-)"

"Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen an angry penguin charging at them in excess of 100 mph. They'd be a lot more careful about what they say if they had."

"It's a bird … it's a plane … no, it's KernelMan, faster than a speeding bullet, to your rescue. Doing new kernel versions in under 5 seconds flat …"

"An infinite number of monkeys typing into GNU Emacs would never make a good program."

"You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now."

"If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

"When you say "I wrote a program that crashed Windows", people just stare at you blankly and say "Hey, I got those with the system, *for free*""

"Dijkstra probably hates me."

"No. That's it. The cool name, that is. We worked very hard on creating a name that would appeal to the majority of people, and it certainly paid off: thousands of people are using linux just to be able to say "OS/2? Hah. I've got Linux. What a cool name". 386BSD made the mistake of putting a lot of numbers and weird abbreviations into the name, and is scaring away a lot of people just because it sounds too technical."

"Well, I probably won't get too good grades even without you: I had an argument (completely unrelated – not even pertaining to OS's) with the person here at the university that teaches OS design. I wonder when I'll learn :)"

"Portability is for people who cannot write new programs."

"Your job is being a professor and researcher: That's one hell of a good excuse for some of the brain-damages of Minix."

"Well, with a subject like this, I'm afraid I'll have to reply. Apologies to minix-users who have heard enough about linux anyway. I'd like to be able to just "ignore the bait", but … time for some serious flamefesting!"

"Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?"

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones."

"Testing shows the presence, not the absence of bugs"

"Go To statement considered harmful"

"Computer Science is no more about computers than astronomy is about telescopes."

"We generally trace the idea of building computer systems in layers back to a 1967 paper that the Dutch computer scientist Edsger Dijkstra gave to a joint IEEE Computer Society/ACM conference. Prior to this paper, engineers had struggled with the problem of how to organize software. If you look at early examples of programs, and you can find many in the electronic library of the Computer Society, you will find that most code of that era is complicated, difficult to read, hard to modify, and challenging to reuse. In his 1967 paper, Dijkstra described how software could be constructed in layers and gave an example of a simple operating system that used five layers. He admitted that this system might not be a realistic test of his ideas but he argued that the "larger the project, the more essential the structuring!" The idea of using layers to control complexity has become a mainstay of software architecture. We see it in many forms and apply it to many problems. We see it in the hierarchy of classes in object-oriented programming and in the structure of Service-Oriented Architecture (SOA). SOA is a relatively recent application of layering in computer science. It was articulated in 2007 as a means of controlling complexity in business systems, especially distributed systems that make substantial use of the Internet. Like Dijkstra's plan for system development, its layering system is called the SOA Solution Stack or S3. The S3's nine layers are: 1) operational systems, 2) service components, 3) services, 4) business processes, 5) consumer actions, 6) system integration, 7) quality control and assurance, 8) information architecture, and 9) system governance and policies."

"While concurrent program execution had been considered for years, the computer science of concurrency began with Edsger Dijkstra's seminal 1965 paper that introduced the mutual exclusion problem. (...) The first scientific examination of fault tolerance was Dijkstra's seminal 1974 paper on self-stabilization. (...) The ensuing decades have seen a huge growth of interest in concurrency—particularly in distributed systems. Looking back at the origins of the field, what stands out is the fundamental role played by Edsger Dijkstra, to whom this history is dedicated."

"Although Dijkstra will always be remembered for structured programming, and for his style and approach, he also invented many other of the standard ideas of programming. If you are struggling with multi-threaded programming you may have encountered the semaphore, and the idea of the "deadly embrace". These, and more, are the result of Dijkstra's work on concurrent programming. He showed how this particularly difficult area of programming could be made relatively safe."

"Since the early work of E.W. Dijkstra (1965), who introduced the mutual exclusion problem, the concept of a process, the semaphore object, the notion of a weakest precondition, and guarded commands (among many other contributions), synchronization is no longer a catalog of tricks but a domain of computing science with its own concepts, mechanisms, and techniques whose results can be applied in many domains. This means that process synchronization has to be a major topic of any computer science curriculum."

"The revolution in views of programming started by Dijkstra's iconoclasm led to a movement known as structured programming, which advocated a systematic, rational approach to program construction. Structured programming is the basis for all that has been done since in programming methodology, including object-oriented programming. As the first book on the topic [Structured Programming by Dijkstra, Ole-Johan Dahl, and Tony Hoare] shows, structured programming is about much more than control structures and the goto. Its principal message is that programming should be considered a scientific discipline based on mathematical rigor."

"The notion of the concurrent program as a means for writing parallel programs without regard for the underlying hardware was first introduced by Edsger Dijkstra (1968). Moti Ben-Ari (1982) elegantly summed up Dijkstra's idea in three sentences: 'Concurrent programming is the name given to programming notation and techniques for expressing potential parallelism and solving the resulting synchronization and communication problems. Implementation of parallelism is a topic in computer systems (hardware and software) that is essentially independent of concurrent programming. Concurrent programming is important because it provides an abstract setting in which to study parallelism without getting bogged down in the implementation details.'"

"In 1965 Dijkstra wrote his famous Notes on Structured Programming and declared programming as a discipline in contrast to a craft. Also in 1965 Hoare published an important paper about data structuring. These ideas had a profound influence on new programming language, in particular Pascal. Languages are the vehicles in which these ideas were to be expressed. Structured programming became supported by a structured programming language."

"Of great influence to Pascal was Structured Programming, put forth by E. W. Dijkstra. This method of proceeding in a design would obliviously be greatly encouraged by the use of a Structured Language, a language with a set of constructs that could freely be combined and nested. The textual structure of a program should directly reflect its flow of control."

"Edsger Dijkstra, one of the giants of our field and a passionate believer in the mathematical view of programs and programming (...) Over the previous quarter-century, he had formulated many of the great intellectual challenges of the field as programming—the goto statement, structured programming, concurrent processes, semaphores, deadlocks, recursive programming in Algol, and deriving correct programs."

"Most experienced IT professionals will agree that developing and adhering to a standard architecture is key to the success of large-scale software development. Computer pioneer Edsger Dijkstra validated this notion when he developed THE operating system in 1968. Since then, layered architectures have proved their viability in technological domains, such as hardware and networking. Layering has proved itself in the operating system domain; however, the same benefits are available when applied to e-commerce or to thin client–oriented applications. Layered architectures have become essential in supporting the iterative development process by promoting reusability, scalability, and maintainability."

"The Edsger W. Dijkstra Prize in Distributed Computing is named for Edsger Wybe Dijkstra (1930-2002), a pioneer in the area of distributed computing. His foundational work on concurrency primitives (such as the semaphore), concurrency problems (such as mutual exclusion and deadlock), reasoning about concurrent systems, and self-stabilization comprises one of the most important supports upon which the field of distributed computing is built. No other individual has had a larger influence on research in principles of distributed computing. The prize is given for outstanding papers on the principles of distributed computing, whose significance and impact on the theory and/or practice of distributed computing have been evident for at least a decade."

"The first classic is one of the great works in computer programming: E. W. Dijkstra, Cooperating Sequential Processes (1965). Here Dijkstra lays the conceptual foundation for abstract concurrent programming."

"...I also discovered books of two great computer scientists from whose work I learned the scientific foundation of my trade: Donald Knuth and Edsger Dijkstra. Knuth taught me the answers. Dijkstra taught me the questions. Time and time again I come back to their works for new insights."

"You probably know that arrogance, in computer science, is measured in nanodijkstras."

"The difference between a computer programmer and a computer scientist is a job-title thing. Edsgar Dijkstra wants proudly to be called a "computer programmer," although he hasn't touched a computer now for some years. (...) His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++."

"Edsger W. Dijkstra's 1969 "Structured Programming" article precipitated a decade of intense focus on programming techniques that has fundamentally altered human expectations and achievements in software development. Before this decade of intense focus, programming was regarded as a private, puzzle-solving activity of writing computer instructions to work as a program. After this decade, programming could be regarded as a public, mathematics-based activity of restructuring specifications into programs. Before, the challenge was in getting programs to run at all, and then in getting them further debugged to do the right things. After, programs could be expected to both run and do the right things with little or no debugging. Before, it was common wisdom that no sizable program could be error-free. After, many sizable programs have run a year or more with no errors detected. These expectations and achievements are not universal because of the inertia of industrial practices. But they are well-enough established to herald fundamental change in software development."

"The working vocabulary of programmers everywhere is studded with words originated or forcefully promulgated by E. W. Dijkstra—display, deadly embrace, semaphore, go-to-less programming, structured programming. But his influence on programming is more pervasive than any glossary can possibly indicate."

"A revolution is taking place in the way we write programs and teach programming, because we are beginning to understand the associated mental processes more deeply. It is impossible to read the recent [E. W. Dijkstra, O.-J. Dahl, and C. A. R. Hoare] book Structured Programming, without having it change your life. The reason for this revolution and its future prospects have been aptly described by E.W. Dijkstra in his 1972 Turing Award Lecture, The Humble Programmer."

"The precious gift that this Turing Award acknowledges is Dijkstra's style: his approach to programming as a high, intellectual challenge; his eloquent insistence and practical demonstration that programs should be composed correct, not just debugged into correctness; and his illuminating perception of problems at the foundations of program design."