DOCSLIB.ORG

By Alan Kay Introduction "OOP"

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
By Alan Kay Introduction A Few Thoughts About "OOP" by Alan Kay Introduction "OOP" is now a term for a variety of languages and techniques which have little resemblance to the original ideas and their spirit. ~30 years ago I was asked to write a history for the ACM, and this eventually appeared in their "History of Programming Languages II" conference and book. The best online version appeared in SIGPLAN Notices: http://www.smalltalk.org/ downloads/papers/SmalltalkHistoryHOPL.pdf Histories are tough because "reality is highly detailed". Summaries have to leave things out -- and not just positive influences, but especially negative influences (one can praise an influence without explaining it, but one should not damn an influence without some explanation -- so I simply left out a lot of things I really disliked). Given that there is a written history, here I can ignore it and just talk about issues. I spent most of my teen and twenties years (50s and 60s) working in 6 main areas: math, physical sciences, especially the new molecular biology, languages (mainly English), anthropology, music (mostly jazz playing), and theater (mostly technical theater). My general outlook was an un-organized amalgam of these pursuits. I learned to program in the Air Force in the early 60s and was able to use this part- time to put myself through college. Like most of us, I both (a) "knew less than I knew" and I (b) "knew more than I knew". For example, I knew that a computer could "simulate anything that could be described", but never connected it to computation itself. I knew that "modularity is good in design" but never connected it in a strong way for programming itself. When I quite accidentally wound up in the ARPA-IPTO research community in grad school, I started having "reactions"/"ideas" -- this was mostly because the community had already had lots of really good ones, many of which had the side effect of debugging (a,b) above. It is hard to describe how a "strong community of individuals" can really make progress while sustaining both sides of what seems to be a contradiction in terms. There are other interesting and important examples of this, including how the US was invented via its Constitution (and the Convention that made it), Los Alamos, and later, Xerox Parc, which was derived from ARPA-IPTO. In any case, that community was the reason for most of its ideas -- Context is worth 80 IQ points! -- and I think of the awards given to individuals in that community as actually the province of the entire community including, especially, its funders. OOP The history gives a partial account of many ideas in the 60s that were "like OOP" being around, but all were addressed to specific problems and lacked both context and a few essential features needed for unification. For example, there was Sketchpad and Simula, there was "data-driven programming (using pointers to procedures in the data itself), there were various kinds of virtualizations of hardware (in time-sharing processes, and especially in the Burroughs B5000). There were attempts at module schemes at many different levels. There were calls for "protection" of state at many different levels of computing, including the call for "relational data bases". There was the combined initiative of the ARPA community to start to make good on its internal demands for an "Intergalactic Network" by first building a packet switching "ARPAnet". There was a strong interest and increasing use of recursive embedding and its more general cousin "reentrant code allowing separate instantiations", etc. One way to sum up my reaction to all this after being pushed by circumstance was the trivial realization -- but a hard one to see given "Normal" -- that on the one hand you can divide a computer into data structures and procedures -- "Normal" -- but you can also divide a computer into further computers. The latter would be immensely powerful in a myriad of ways compared to the former because retaining a computer retains universality, whereas neither procedures nor date were universal. The results would be breath-taking if the overheads at small scales could be removed, so the principle could be used everywhere. Just to take one of many examples: if you wanted to send data "a thousand miles" you had to send a manual or a person with it. If you "sent a computer a thousand miles" you would be sending everything needed, and you would be sending it as the real entity "data" actually is (i.e. data just lies there without code, code just lies there without data, so you should package them together to make a viable thing). This suggests among many things that "data" is a bad idea/concept and should be eliminated. Along similar lines the pernicious but needed notion of "type" -- both for dynamic and static typing -- would be answered much more strongly with these packages. If you wanted something "like data" you could simulate it, and trap attempts to change it if desired. You could go beyond this to "forget about data" and think more in terms of "knowledge" that is being accumulated over time (this would start to overlap with the way "data-bases" in enterprises are actually handled albeit haphazardly). They are versioned, race-conditions are verboten, etc. These "computers" would intercommunicate via messages, and ideally should act like servers to each other (i.e. a message should not be treated as an external command, but the receiver of the message should have full control of what to do with a message). This meant that procedure calls would be eliminated in favor of looser coupling and something more like a search for resources. The "computer boundary" and protection and messages all meant that the messages could have abstract "algebraic" qualities where "requests" could be in generic terms, and the "fulfillment" of a request would be idiosyncratic to the receiver. Since everything in computing requires definition of some kind, the actual parts of the programming language could be simulated by these general computers -- for example, control structures, could easily be made. New kind of language could easily be made. Keeping the messaging system pure and general would allow many kinds of things done ultimately in many kinds of way to be mixed together and interoperate. This also means that you get layers of "meta" automatically, and they are still defined in terms of these software computers. Speaking of "operate", such a system could be its own operating system, and the kernel could be astonishingly small. It would also be a great basis for real-time interaction because the messaging provides the loosely bound system needed for doing everything on the fly. A programming system could be just conventions about the messages being sent and received, and this could be distributed because each computer can have its own interpreter for the pure message. The possibilities for scaling were exciting. Large numbers of many sized computers intercommunicating resembles many different levels of Biology, and just a single human being has ~100 trillion cells (~10 trillion with our DNA, plus thousands of species of micro-organisms for the other 90 trillion). There are many more implications that are exciting and powerful. For example, one could imagine a message send as a "request for resources/services" of some kind. These messages target *ideas* rather than specific computers, and go to facilities that try to find computers than can help with resources and services. We could imagine moving these computers in time by versioning rather than updating (this is an old idea of McCarthy's). It is particularly easy to set up using this scheme. Similarly "speculative 'possible worlds' evaluation" is a cousin of these ideas). Recent research (by Alex Warth et al. http://www.vpri.org/pdf/ tr2011001_final_worlds.pdf) shows that it can be taken "into the small" as well as the large. This is also a way to get the benefits from "functional programming" without the liabilities and distortions. The basic point of this part of the story is that a "unifying principle" can be the most powerful (or the most destructive) idea we can have, because the limited capacity of our minds is greatly amplified by *not* having too many particulars to mess up our 4±3 dynamic mental slots. Looking for unifying principles (as opposed to "hacks") is a way to advance a field that is way behind in its learning curve. Practicalities The second part of the story is that any new perspective can often require a lot of design and engineering effort to bring it out of the place where dreams are made into practical existence. For example, it took some work to get "3" to be one of these computers, and have it be as small and run as fast as prior practice -- and part of the solution came from prior practice in Lisp. In fact, Lisp had quite a positive influence on many parts of the realization of these ideas. Getting every part of a programming system to be made from "computers", especially when running on "a computer that is not made of computers" took several stages. Lisp showed part of it. Smalltalk took this very far. "The Art of the Metaobject Protocol" takes it the rest of the way. It was quite a feat of systems design -- in both Lisp and especially Smalltalk (mostly by Dan Ingalls) -- to allow errors and debugging to happen without penalty while the system itself is running. Etc. "OOP" got popular from the success of the Parc systems efforts, but quickly got turned into "just a label" partly because of misunderstanding, partly from laziness, partly from un-careful optimizations, partly from conservatism.
Load more

Recommended publications
  • QATAR ASW ONLINE SCRIPT V.8.0 Pages
    “DEXIGN THE FUTURE: Innovation for Exponential Times” ARNOLD WASSERMAN COMMENCEMENT ADDRESS VIRGINIA COMMONWEALTH UNIVERSITY IN QATAR 2 MAY 2016 مساء الخير .Good afternoon It is an honor to be invited to address you on this important day. Today you artists and designers graduate into the future. Do you think about the future? Of course you do. But how do you think about the future? Is the future tangible - or is it intangible ? Is it a subject for rational deliberation? Or is it an imagined fantasy that forever recedes before us? Is the future simply whatever happens to us next? Or is it something we deliberately create? Can we Dexign the Future? What I would like us to think about for the next few moments is how creative professionals like yourselves might think about the future. What I have to say applies as much to art as it does to design. Both are technologies of creative innovation. I will take the liberty here of calling it all design. My speech is also available online. There you can follow a number of links to what I will talk about here. The future you are graduating into is an exponential future. What that means is that everything is happening faster and at an accelerating rate. For example, human knowledge is doubling every 12 months. And that curve is accelerating. An IBM researcher foresees that within a few years knowledge will be doubling every 12 hours as we build out the internet of things globally. This acceleration of human knowledge implies that the primary skill of a knowledge worker like yourself is research, analysis and synthesis of the not-yet-known.
    [Show full text]
  • The Future: the Story of Squeak, a Practical Smalltalk Written in Itself
    Back to the future: the story of Squeak, a practical Smalltalk written in itself Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay [Also published in OOPSLA ’97: Proc. of the 12th ACM SIGPLAN Conference on Object-oriented Programming, 1997, pp. 318-326.] VPRI Technical Report TR-1997-001 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 Back to the Future The Story of Squeak, A Practical Smalltalk Written in Itself by Dan Ingalls Ted Kaehler John Maloney Scott Wallace Alan Kay at Apple Computer while doing this work, now at Walt Disney Imagineering 1401 Flower Street P.O. Box 25020 Glendale, CA 91221 [email protected] Abstract Squeak is an open, highly-portable Smalltalk implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. To achieve practical performance, a translator produces an equivalent C program whose performance is comparable to commercial Smalltalks. Other noteworthy aspects of Squeak include: a compact object format that typically requires only a single word of overhead per object; a simple yet efficient incremental garbage collector for 32-bit direct pointers; efficient bulk- mutation of objects; extensions of BitBlt to handle color of any depth and anti-aliased image rotation and scaling; and real-time sound and music synthesis written entirely in Smalltalk. Overview Squeak is a modern implementation of Smalltalk-80 that is available for free via the Internet, at http://www.research.apple.com/research/proj/learning_concepts/squeak/ and other sites. It includes platform-independent support for color, sound, and image processing.
    [Show full text]
  • Simula Mother Tongue for a Generation of Nordic Programmers
    Simula! Mother Tongue! for a Generation of! Nordic Programmers! Yngve Sundblad HCI, CSC, KTH! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Inspired by Ole-Johan Dahl, 1931-2002, and Kristen Nygaard, 1926-2002" “From the cold waters of Norway comes Object-Oriented Programming” " (first line in Bertrand Meyer#s widely used text book Object Oriented Software Construction) ! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Simula concepts 1967" •# Class of similar Objects (in Simula declaration of CLASS with data and actions)! •# Objects created as Instances of a Class (in Simula NEW object of class)! •# Data attributes of a class (in Simula type declared as parameters or internal)! •# Method attributes are patterns of action (PROCEDURE)! •# Message passing, calls of methods (in Simula dot-notation)! •# Subclasses that inherit from superclasses! •# Polymorphism with several subclasses to a superclass! •# Co-routines (in Simula Detach – Resume)! •# Encapsulation of data supporting abstractions! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Simula example BEGIN! REF(taxi) t;" CLASS taxi(n); INTEGER n;! BEGIN ! INTEGER pax;" PROCEDURE book;" IF pax<n THEN pax:=pax+1;! pax:=n;" END of taxi;! t:-NEW taxi(5);" t.book; t.book;" print(t.pax)" END! Output: 7 ! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad!
    [Show full text]
  • Design and Implementation of an Optionally-Typed Functional Programming Language
    Design and Implementation of an Optionally-Typed Functional Programming Language Shaobai Li Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2017-215 http://www2.eecs.berkeley.edu/Pubs/TechRpts/2017/EECS-2017-215.html December 14, 2017 Copyright © 2017, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Design and Implementation of an Optionally-Typed Functional Programming Language by Patrick S. Li A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Engineering { Electrical Engineering and Computer Sciences in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Koushik Sen, Chair Adjunct Professor Jonathan Bachrach Professor George Necula Professor Sara McMains Fall 2017 Design and Implementation of an Optionally-Typed Functional Programming Language Copyright 2017 by Patrick S. Li 1 Abstract Design and Implementation of an Optionally-Typed Functional Programming Language by Patrick S. Li Doctor of Philosophy in Engineering { Electrical Engineering and Computer Sciences University of California, Berkeley Professor Koushik Sen, Chair This thesis describes the motivation, design, and implementation of L.B. Stanza, an optionally- typed functional programming language aimed at helping programmers tackle the complexity of architecting large programs and increasing their productivity across the entire software development life cycle.
    [Show full text]
  • Smalltalk's Influence on Modern Programming
    1 Smalltalk’s Influence on Modern Programming Smalltalk’s Influence on Modern Programming Matt Savona. February 1 st , 2008. In September 1972 at Xerox PARC, Alan Kay, Ted Kaeher and Dan Ingalls were discussing programming languages in the hallway of their office building. Ted and Dan had begun to consider how large a language had to be to have “great power.” Alan took a different approach, and “asserted that you could define the "most powerful language in the world" in "a page of code."” Ted and Dan replied, “Put up or shut up” (Kay). And with that, the bet to develop the most powerful language was on. Alan arrived at PARC every morning at 4am for two weeks, and devoted his time from 4am to 8am to the development of the language. That language was Smalltalk. Kay had “originally made the boast because McCarthy's self-describing LISP interpreter was written in itself. It was about "a page", and as far as power goes, LISP was the whole nine- yards for functional languages.” He was sure that he could “do the same for object-oriented languages” and still have a reasonable syntax. By the eighth morning, Kay had a version of Smalltalk developed where “symbols were byte-coded and the receiving of return-values from a send was symmetric” (Kay). Several days later, Dan Ingalls had coded Kay’s scheme in BASIC, added a “token scanner”, “list maker” and many other features. “Over the next ten years he made at least 80 major releases of various flavors of Smalltalk” (Kay).
    [Show full text]
  • A Model of Inheritance for Declarative Visual Programming Languages
    An Abstract Of The Dissertation Of Rebecca Djang for the degree of Doctor of Philosophy in Computer Science presented on December 17, 1998. Title: Similarity Inheritance: A Model of Inheritance for Declarative Visual Programming Languages. Abstract approved: Margaret M. Burnett Declarative visual programming languages (VPLs), including spreadsheets, make up a large portion of both research and commercial VPLs. Spreadsheets in particular enjoy a wide audience, including end users. Unfortunately, spreadsheets and most other declarative VPLs still suffer from some of the problems that have been solved in other languages, such as ad-hoc (cut-and-paste) reuse of code which has been remedied in object-oriented languages, for example, through the code-reuse mechanism of inheritance. We believe spreadsheets and other declarative VPLs can benefit from the addition of an inheritance-like mechanism for fine-grained code reuse. This dissertation first examines the opportunities for supporting reuse inherent in declarative VPLs, and then introduces similarity inheritance and describes a prototype of this model in the research spreadsheet language Forms/3. Similarity inheritance is very flexible, allowing multiple granularities of code sharing and even mutual inheritance; it includes explicit representations of inherited code and all sharing relationships, and it subsumes the current spreadsheet mechanisms for formula propagation, providing a gradual migration from simple formula reuse to more sophisticated uses of inheritance among objects. Since the inheritance model separates inheritance from types, we investigate what notion of types is appropriate to support reuse of functions on different types (operation polymorphism). Because it is important to us that immediate feedback, which is characteristic of many VPLs, be preserved, including feedback with respect to type errors, we introduce a model of types suitable for static type inference in the presence of operation polymorphism with similarity inheritance.
    [Show full text]
  • Reading List
    EECS 101 Introduction to Computer Science Dinda, Spring, 2009 An Introduction to Computer Science For Everyone Reading List Note: You do not need to read or buy all of these. The syllabus and/or class web page describes the required readings and what books to buy. For readings that are not in the required books, I will either provide pointers to web documents or hand out copies in class. Books David Harel, Computers Ltd: What They Really Can’t Do, Oxford University Press, 2003. Fred Brooks, The Mythical Man-month: Essays on Software Engineering, 20th Anniversary Edition, Addison-Wesley, 1995. Joel Spolsky, Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity, APress, 2004. Most content is available for free from Spolsky’s Blog (see http://www.joelonsoftware.com) Paul Graham, Hackers and Painters, O’Reilly, 2004. See also Graham’s site: http://www.paulgraham.com/ Martin Davis, The Universal Computer: The Road from Leibniz to Turing, W.W. Norton and Company, 2000. Ted Nelson, Computer Lib/Dream Machines, 1974. This book is now very rare and very expensive, which is sad given how visionary it was. Simon Singh, The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography, Anchor, 2000. Douglas Hofstadter, Goedel, Escher, Bach: The Eternal Golden Braid, 20th Anniversary Edition, Basic Books, 1999. Stuart Russell and Peter Norvig, Artificial Intelligence: A Modern Approach, 2nd Edition, Prentice Hall, 2003.
    [Show full text]
  • Cross-Language Interop Poster
    Low Cognitive Overhead Bridging "Interoperability isn't just a technical problem, it's also a user interface problem. We have to make it easy to call between languages, so that users can The demo shown at FOSDEM always pick the most appropriate tool for the job at hand." example [ this year showed fully dynamic "This shows how to call a C function from Smalltalk" development spanning C objc_setAssociatedObject: { Objective-C and Smalltalk. The self. 42. developer can inspect the ’fishes’. existing class hierarchy and C enumValue: OBJC_ASSOCIATION_ASSIGN }. the code for any methods "Note how C enumerations can be accessed. When encountering this construct, the Pragmatic Smalltalk compiler will generate exactly the same code as an implemented in Smalltalk. It Objective-C compiler would for this line: is also possible to add, modify, objc_setAssociatedObject(self, 42, @"fishes", OBJC_ASSOCIATION_ASSIGN); or replace methods, add It will get the types for the function by parsing the header and automatically map Smalltalk types to C and Objective-C types. The instance variables and classes Easy Development programmer doesn't need to write any bridging or foreign function interface at run time. Invoking a code." nonexistent class or method (C objc_getAssociatedObject: {self . 42 }) log. ] pops up a dialog asking the user to implement it, all from within a running app. The final version is statically compiled, with no explicit user Cross-Language Interoperability for intervention required. Fast, Easy, and Maintainable Code David Chisnall The World Today: But I wanted to use the But libfoo is C, libbar Frobnicator framework, and it's I have a great idea is C++, and I want to only for Java.
    [Show full text]
  • Smalltalk Language Mapping Specification
    Smalltalk Language Mapping Specification New Edition: June 1999 Copyright 1995, 1996 BNR Europe Ltd. Copyright 1998, Borland International Copyright 1991, 1992, 1995, 1996 Digital Equipment Corporation Copyright 1995, 1996 Expersoft Corporation Copyright 1996, 1997 FUJITSU LIMITED Copyright 1996 Genesis Development Corporation Copyright 1989, 1990, 1991, 1992, 1995, 1996 Hewlett-Packard Company Copyright 1991, 1992, 1995, 1996 HyperDesk Corporation Copyright 1998 Inprise Corporation Copyright 1996, 1997 International Business Machines Corporation Copyright 1995, 1996 ICL, plc Copyright 1995, 1996 IONA Technologies, Ltd. Copyright 1996, 1997 Micro Focus Limited Copyright 1991, 1992, 1995, 1996 NCR Corporation Copyright 1995, 1996 Novell USG Copyright 1991,1992, 1995, 1996 by Object Design, Inc. Copyright 1991, 1992, 1995, 1996 Object Management Group, Inc. Copyright 1996 Siemens Nixdorf Informationssysteme AG Copyright 1991, 1992, 1995, 1996 Sun Microsystems, Inc. Copyright 1995, 1996 SunSoft, Inc. Copyright 1996 Sybase, Inc. Copyright 1998 Telefónica Investigación y Desarrollo S.A. Unipersonal Copyright 1996 Visual Edge Software, Ltd. The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified ver- sion. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having con- formed any computer software to the specification. PATENT The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights.
    [Show full text]
  • STEPS Toward Expressive Programming Systems, 2010 Progress Report Submitted to the National Science Foundation (NSF) October 2010
    STEPS Toward Expressive Programming Systems, 2010 Progress Report Submitted to the National Science Foundation (NSF) October 2010 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 VPRI Technical Report TR-2010-004 NSF Award: 0639876 Year 4 Annual Report: October 2010 STEPS Toward Expressive Programming Systems Viewpoints Research Institute, Glendale CA Important Note For Viewing The PDF Of This Report We have noticed that Adobe Reader and Acrobat do not do the best rendering of scaled pictures. Try different magnifications (e.g. 118%) to find the best scale. Apple Preview does a better job. Table Of Contents STEPS For The General Public 2 STEPS Project Introduction 3 STEPS In 2010 5 The “Frank” Personal Computing System 5 The Parts Of Frank 7 1. DBjr 7 a. User Interface Approach 9 b. Some of the Document Styles We’ve Made 11 2. LWorld 17 3. Gezira/Nile 18 4. NotSqueak 20 5. Networking 20 6. OMeta 22 7. Nothing 22 2010 STEPS Experiments And Papers 23 Training and Development 26 Outreach Activities 26 References 27 Appendix 1: Nothing Grammar in OMeta 28 Appendix 2: A Copying Garbage Collector in Nothing 30 VPRI Technical Report TR-2010-004 A new requirement for NSF reports is to include a few jargon‑free paragraphs to help the general public un‑ derstand the nature of the research. This seems like a very good idea. Here is our first attempt. STEPS For The General Public If computing is important—for daily life, learning, business, national defense, jobs, and more—then qualitatively advancing computing is extremely important.
    [Show full text]
  • Dynamic Object-Oriented Programming with Smalltalk
    Dynamic Object-Oriented Programming with Smalltalk 1. Introduction Prof. O. Nierstrasz Autumn Semester 2009 LECTURE TITLE What is surprising about Smalltalk > Everything is an object > Everything happens by sending messages > All the source code is there all the time > You can't lose code > You can change everything > You can change things without restarting the system > The Debugger is your Friend © Oscar Nierstrasz 2 ST — Introduction Why Smalltalk? > Pure object-oriented language and environment — “Everything is an object” > Origin of many innovations in OO development — RDD, IDE, MVC, XUnit … > Improves on many of its successors — Fully interactive and dynamic © Oscar Nierstrasz 1.3 ST — Introduction What is Smalltalk? > Pure OO language — Single inheritance — Dynamically typed > Language and environment — Guiding principle: “Everything is an Object” — Class browser, debugger, inspector, … — Mature class library and tools > Virtual machine — Objects exist in a persistent image [+ changes] — Incremental compilation © Oscar Nierstrasz 1.4 ST — Introduction Smalltalk vs. C++ vs. Java Smalltalk C++ Java Object model Pure Hybrid Hybrid Garbage collection Automatic Manual Automatic Inheritance Single Multiple Single Types Dynamic Static Static Reflection Fully reflective Introspection Introspection Semaphores, Some libraries Monitors Concurrency Monitors Categories, Namespaces Packages Modules namespaces © Oscar Nierstrasz 1.5 ST — Introduction Smalltalk: a State of Mind > Small and uniform language — Syntax fits on one sheet of paper >
    [Show full text]
  • EDSGER W. DIJKSTRA Turing Award 1972 Contributions To: Compiler Design Algorithms Formal Verification Programming Languages
    LISP IN HPC MARCO HEISIG [email protected] 0 TABLE OF CONTENTS Motivational Quotes The Lisp Language Performance Our Research Questions & Answers 1 MOTIVATIONAL QUOTES … showing you that Lisp is not just another programming language 2 EDSGER W. DIJKSTRA Turing Award 1972 contributions to: compiler design algorithms formal verification programming languages 3 EDSGER W. DIJKSTRA FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes. 3 - 1 EDSGER W. DIJKSTRA Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great compliment because it transmits the full flavor of liberation […] 3 - 2 ALAN KAY Turing Award 2003 Inventor of Object Oriented Programming Graphical User Interface Smalltalk 4 ALAN KAY I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS. 4 - 1 ALAN KAY [Lisp is] … the greatest single programming language ever designed 4 - 2 RICHARD M. STALLMAN Founder of the Free Software Foundation Author of GCC GDB Emacs GNU Make … 5 RICHARD M. STALLMAN The most powerful programming language is Lisp. […] Once you learn Lisp you will see what is missing in most other languages. 5 - 1 OUR MOTIVATION The primary goal of a language should be the elegant notation of algorithms. Mandatory requirements should therefore be automatic memory management proper integers, fractions and complex numbers higher order functions (also at runtime) the possibility of reaching machine peak performance (computational completeness ?) 6 THE LISP LANGUAGE 7 THE LISP LANGUAGE discovered 1958 by John McCarthy short for LISt Processing Modern dialects: Common Lisp Scheme Clojure 8 PAIRS AND LISTS ;; basic datastructure: The pair! (a .
    [Show full text]