| layout | title |
|---|---|
default |
People |
This is a partial list of notable figures in computer science.
If all these people would work together how would it change the computing industry?
List of pioneers in computer science
"Die meisten meiner Kollegen glauben, alles ist berechenbar und wir können eine künstliche Mensche herstellen. Das hat auch was mit Größenwahn zu tun." ... Doch ausgerechnet einer der Pioniere der Computerentwicklung und der künstlichen Intelligenz, der ehemalige MIT-Professor Joseph Weizenbaum, hat sich zum schärfsten Kritiker dieser technologischen Allmachtsvisionen entwickelt. Er betrachtet die weit verbreitete Ansicht, die Natur sei mit Hilfe der Wissenschaft vollkommen zu erfassen und somit objektiv berechenbar, als katastrophale Fehlentwicklung des menschlichen Denkens.
... The second issue is of a different kind. I am firmly convinced that APL and LISP are related to each other along an important axis of language design and that acquiring simultaneous expertise in both languages is possible and desirable for the beginning student. Were they unified, the set of tasks that succumb to terse, flexible and expressive descriptions will enlarge enormously without overly increasing the intellectual burden on the student over his initial 16 week contact period. ...
- Wiki
- Function level Programming
- Can programming be liberated from the von Neumann style?: a functional style and its algebra of programs
- BNF
- EBNF
- Homepage
- Roots of Lisp
- Lisp
- Recursive Functions of Symbolic Expressions and Their Computation by Machine
- Garbage Collection
- John McCarthy, on Philosophy of AI
- AI winter
- Picture 1960 Algol conference in Paris
- Wiki
- Home @ MIT
- Fresh Breeze: A Novel Multiprocessor Chip
- The Fresh Breeze Model of Thread Execution
- A preliminary architecture for a basic data-flow processor
- Thoughts about Computer Architecture
- How It All Began
In September 1988 the MIT Laboratory for Computer Science celebrated the thirty-fifth anniversary of Project MAC. At that event I pointed out the limitations of conventional multiprocessor architecture:
"Yet present multiprocessors are very limited in their effective application. Their programming tools are absurdly limited and primitive in contrast to those of Multics. There is no automatic management of memory by the system on behalf of its users. Moreover, within the massive research effort now devoted to parallel architecture, hardly any effort is devoted to the problem of improving programmability in any fundamental sense."
Some wild ideas may be the key to a breakthrough: Functional programming; the idea of a memory that directly supports creation and access to data objects, but does not permit updates; hardware-supported allocation and garbage collection of memory. They need to be seriously explored.
At the Project MAC anniversary I explained:
"... the key idea ... is functional programming: getting away from the burden of sequential programming concepts embedded in our popular programming languages and computer architectures. The ideas to accomplish this advance exist; in fact they have been known for some time. Yet they are not in favor. Why? They do not fall into the current main stream of computer science. They do not solve the *multiprocessor cache problem*--__instead they make it irrelevant__. They do not solve the problem of *shared objects in object-oriented programming*--__they eliminate the problem__. They do not minimize the overhead of *processor synchronization*--__they make it disappear altogether__."
Fifteen years later these remarks remain valid. I concluded by saying:
"The computer systems of today do not realize our original vision from the inception of Project MAC. Yet the opportunity to make our dreams come true is still there. The vision is not obsolete. It is one that will be achieved. I believe the day will come when the ideas are widely accepted and we can move forward to build the Computer Utility. I hope to contribute to its realization and I look forward to enjoying its fruits."
McIlroy is attributed the quote "The real hero of programming is the one who writes negative code,"[32] where the meaning of negative code is taken to be similar to the famous Apple developer, Bill Atkinson, team anecdote[33] (i.e., when a change in a program source makes the number of lines of code decrease ('negative' code), while its overall quality, readability or speed improves).
Conversely, McIlroy has criticized modern Linux as having software bloat, remarking that, "adoring admirers have fed Linux goodies to a disheartening state of obesity."[8] He contrasts this with the earlier approach taken at Bell Labs when developing and revising Research Unix:[9]
Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option.
- Null References: The Billion Dollar Mistake
- Communicating sequential processes
- QuickSort
- Concurrent Computing
- Home at ETH Zürich
- A Plea for Lean Software
- Oberon
- Project Oberon (New Edition 2013)
- Project Oberon - The Design of an Operating System, a Compiler, and a Computer
- Compiler Construction
- Algorithms and Data Structures
- Computer-Pionier Niklaus Wirth: 80 und aktiv
- Homepage
- Wiki
- TeX
- Metafont
- Computer_Modern
- Web
- Literate Programming
- The Art of Computer Programming (TAOCP)
- A RISC computer for the new millennium
-
Brian Kernighan interviews Ken Thompson
Ken Thompson: "One week, one week, one week and we had Unix." Brian Kernighan: "I think programmers weren't quit productive like these days."
- Homepage
- Flexible Systems, The Power of Generic Operations
- We Really Don't Know How To Compute!
- Revised Report on the Propagator Model
- Homepage
- JavaScript: The World's Most Misunderstood Programming Language
- How JavaScript Works
- The Post JavaScript Apocalypse
- The Power of the Paradigm
- Principles of Security
- DEC64
- The Good, the Bad, and the Ugly: The Unix Legacy
- Go
- Plan 9
- Concurrency is not Parallelism
- The Go Programming Language and Environment
- History of Unix
- Homepage
- The Root of Lisp
- What Made Lisp Different
- If Lisp is so great
- Taste for Makers - About good Design
- Arc
- Bel
- About
- cleancoders.com
- Future of Programming
- Clean Architecture and Design
- The Last Programming Language
Eric Raymond's 17 Unix Rules[edit] In his book The Art of Unix Programming that was first published in 2003,[11] Eric S. Raymond (open source advocate and programmer) summarizes the Unix philosophy as KISS Principle of "Keep it Simple, Stupid."[12] He provides a series of design rules: Build modular programs | Write readable programs | Use composition | Separate mechanisms from policy | Write simple programs | Write small programs | Write transparent programs | Write robust programs | Make data complicated when required, not the program | Build on potential users' expected knowledge | Avoid unnecessary output | Write programs which fail in a way that is easy to diagnose | Value developer time over machine time | Write abstract programs that generate code instead of writing code by hand | Prototype software before polishing it | Write flexible and open programs | Make the program and protocols extensible.