History of Programming Languages
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
NET Core & Linux
.NET Core & Linux Fabio Di Peri [email protected] Twitter: @kipters Telegram: @kipters Linux Day 2020 | .NET Core & Linux “ I went into .NET thinking this was a programming language, but it seems I've stumbled upon a mini operating system with support for multiple execution environments, programming languages, and now I have so many questions. — Kelsey Hightower (@kelseyhightower) July 30, 2020 “ Linux Day 2020 | .NET Core & Linux Multiple execution environments .NET Framework .NET Core Mono .NET Micro .NET Nano CoreRT Linux Day 2020 | .NET Core & Linux Multiple languages C# F# VB Linux Day 2020 | .NET Core & Linux Multiple languages C# F# VB C++ Python PHP ... Linux Day 2020 | .NET Core & Linux Codice CIL CLR Linux Day 2020 | .NET Core & Linux Codice CIL CLR Java bytecode JVM Linux Day 2020 | .NET Core & Linux CLR | Common Language Runtime "La JVM" CLR Mono CoreCLR Linux Day 2020 | .NET Core & Linux BCL | Base Class Library L'intero set di librerie e classi a disposizione delle applicazioni .NET Linux Day 2020 | .NET Core & Linux Nuget Linux Day 2020 | .NET Core & Linux dotnet CLI Linux Day 2020 | .NET Core & Linux 1995 Java Linux Day 2020 | .NET Core & Linux 1996 Anders Hejlsberg Linux Day 2020 | .NET Core & Linux 1996 Anders Hejlsberg Turbo Pascal Delphi Linux Day 2020 | .NET Core & Linux 1996 Anders Hejlsberg Turbo Pascal Delphi C# TypeScript Linux Day 2020 | .NET Core & Linux Visual J++ 1.1 Linux Day 2020 | .NET Core & Linux Visual J++ 6.0 Linux Day 2020 | .NET Core & Linux Visual J++ 1.x Abbraccia Java Linux Day 2020 | .NET Core -
Typology of Programming Languages E Early Languages E
Typology of programming languages e Early Languages E Typology of programming languages Early Languages 1 / 71 The Tower of Babel Typology of programming languages Early Languages 2 / 71 Table of Contents 1 Fortran 2 ALGOL 3 COBOL 4 The second wave 5 The finale Typology of programming languages Early Languages 3 / 71 IBM Mathematical Formula Translator system Fortran I, 1954-1956, IBM 704, a team led by John Backus. Typology of programming languages Early Languages 4 / 71 IBM 704 (1956) Typology of programming languages Early Languages 5 / 71 IBM Mathematical Formula Translator system The main goal is user satisfaction (economical interest) rather than academic. Compiled language. a single data structure : arrays comments arithmetics expressions DO loops subprograms and functions I/O machine independence Typology of programming languages Early Languages 6 / 71 FORTRAN’s success Because: programmers productivity easy to learn by IBM the audience was mainly scientific simplifications (e.g., I/O) Typology of programming languages Early Languages 7 / 71 FORTRAN I C FIND THE MEAN OF N NUMBERS AND THE NUMBER OF C VALUES GREATER THAN IT DIMENSION A(99) REAL MEAN READ(1,5)N 5 FORMAT(I2) READ(1,10)(A(I),I=1,N) 10 FORMAT(6F10.5) SUM=0.0 DO 15 I=1,N 15 SUM=SUM+A(I) MEAN=SUM/FLOAT(N) NUMBER=0 DO 20 I=1,N IF (A(I) .LE. MEAN) GOTO 20 NUMBER=NUMBER+1 20 CONTINUE WRITE (2,25) MEAN,NUMBER 25 FORMAT(11H MEAN = ,F10.5,5X,21H NUMBER SUP = ,I5) STOP TypologyEND of programming languages Early Languages 8 / 71 Fortran on Cards Typology of programming languages Early Languages 9 / 71 Fortrans Typology of programming languages Early Languages 10 / 71 Table of Contents 1 Fortran 2 ALGOL 3 COBOL 4 The second wave 5 The finale Typology of programming languages Early Languages 11 / 71 ALGOL, Demon Star, Beta Persei, 26 Persei Typology of programming languages Early Languages 12 / 71 ALGOL 58 Originally, IAL, International Algebraic Language. -
Tortoisemerge a Diff/Merge Tool for Windows Version 1.11
TortoiseMerge A diff/merge tool for Windows Version 1.11 Stefan Küng Lübbe Onken Simon Large TortoiseMerge: A diff/merge tool for Windows: Version 1.11 by Stefan Küng, Lübbe Onken, and Simon Large Publication date 2018/09/22 18:28:22 (r28377) Table of Contents Preface ........................................................................................................................................ vi 1. TortoiseMerge is free! ....................................................................................................... vi 2. Acknowledgments ............................................................................................................. vi 1. Introduction .............................................................................................................................. 1 1.1. Overview ....................................................................................................................... 1 1.2. TortoiseMerge's History .................................................................................................... 1 2. Basic Concepts .......................................................................................................................... 3 2.1. Viewing and Merging Differences ...................................................................................... 3 2.2. Editing Conflicts ............................................................................................................. 3 2.3. Applying Patches ........................................................................................................... -
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. -
Computing Versus Human Thinking
By Peter Naur, recipient of ACM’s 2005 A.M. Turing Award Computing Versus Human Thinking n this presentation I shall give you an overview of efforts. Indeed, I have found that a large part of what Imy works from the past fifty years concerning the is currently said about human thinking and about sci- issue given in the title. Concerning this title I entific and scholarly activity is false and harmful to invite you to note particularly the middle word, ‘ver- our understanding. I realize that my presentation of sus’. This word points to the tendency of my efforts some of these issues may be offensive to you. This I around this theme, to wit, to clarify the contrast regret, but it cannot be avoided. between the two items, computing and human thinking. This tendency of my work has found its DESCRIPTION AS THE CORE ISSUE OF SCIENCE AND ultimate fulfilment in my latest result, which is a SCHOLARSHIP description of the nervous system showing that this The tone of critique and rejection of established system has no similarity whatever to a computer. ideas has its roots in my earliest activity, from its very It is ironic that my present award lecture is given beginning more than fifty years ago. Already in my under the title of Turing. As a matter of fact, one part work in astronomy, around 1955, a decisive item in of my work concerning computing and human think- my awareness came from Bertrand Russell’s explicit ing has been an explicit critique, or rejection, of the rejection of any notion of cause as a central issue of ideas of one prominent contribution from Alan Tur- scientific work. -
Edsger Dijkstra: the Man Who Carried Computer Science on His Shoulders
INFERENCE / Vol. 5, No. 3 Edsger Dijkstra The Man Who Carried Computer Science on His Shoulders Krzysztof Apt s it turned out, the train I had taken from dsger dijkstra was born in Rotterdam in 1930. Nijmegen to Eindhoven arrived late. To make He described his father, at one time the president matters worse, I was then unable to find the right of the Dutch Chemical Society, as “an excellent Aoffice in the university building. When I eventually arrived Echemist,” and his mother as “a brilliant mathematician for my appointment, I was more than half an hour behind who had no job.”1 In 1948, Dijkstra achieved remarkable schedule. The professor completely ignored my profuse results when he completed secondary school at the famous apologies and proceeded to take a full hour for the meet- Erasmiaans Gymnasium in Rotterdam. His school diploma ing. It was the first time I met Edsger Wybe Dijkstra. shows that he earned the highest possible grade in no less At the time of our meeting in 1975, Dijkstra was 45 than six out of thirteen subjects. He then enrolled at the years old. The most prestigious award in computer sci- University of Leiden to study physics. ence, the ACM Turing Award, had been conferred on In September 1951, Dijkstra’s father suggested he attend him three years earlier. Almost twenty years his junior, I a three-week course on programming in Cambridge. It knew very little about the field—I had only learned what turned out to be an idea with far-reaching consequences. a flowchart was a couple of weeks earlier. -
Reinventing Education Based on Data and What Works • Since 1955
Reinventing Education Based on Data and What Works • Since 1955 Carnegie Mellon is reinventing education and the way we think about leveraging technology through its study of the science of learning – an interdisciplinary effort that we’ve been tackling for more than 50 years with both computer scientists and psychologists. CMU's educational technology innovations have inspired numerous startup companies, which are helping students to learn more effectively and efficiently. 1955: Allen Newell (TPR ’57) joins 1995: Prof. Kenneth R. Koedinger (HSS Prof. Herbert Simon’s research team as ’88,’90) and Anderson develop Practical a Ph.D. student. Algebra Tutor. The program pioneers a new form of computer-aided instruction for high 1956: CMU creates one of the world’s first school students based on cognitive tutors. university computation centers. With Prof. Alan Perlis (MCS ’42) as its head, it is a joint 1995: Prof. Jack Mostow (SCS ’81) undertaking of faculty from the business, develops Project LISTEN, an intelligent tutor Simon, Newell psychology, electrical engineering and that helps children learn to read. The National mathematics departments, and the Science Foundation included Project precursor to computer science. LISTEN’s speech recognition system as one of its top 50 innovations from 1950-2000. 1956: Simon creates a “thinking machine”—enacting a mental process 1995: The Center for Automated by breaking it down into its simplest Learning and Discovery is formed, led steps. Later that year, the term “artificial by Prof. Thomas M. Mitchell. intelligence” is coined by a small group Perlis including Newell and Simon. 1998: Spinoff company Carnegie Learning is founded by CMU scientists to expand 1956: Simon, Newell and J. -
Object-Oriented Programming Basics with Java
Object-Oriented Programming Object-Oriented Programming Basics With Java In his keynote address to the 11th World Computer Congress in 1989, renowned computer scientist Donald Knuth said that one of the most important lessons he had learned from his years of experience is that software is hard to write! Computer scientists have struggled for decades to design new languages and techniques for writing software. Unfortunately, experience has shown that writing large systems is virtually impossible. Small programs seem to be no problem, but scaling to large systems with large programming teams can result in $100M projects that never work and are thrown out. The only solution seems to lie in writing small software units that communicate via well-defined interfaces and protocols like computer chips. The units must be small enough that one developer can understand them entirely and, perhaps most importantly, the units must be protected from interference by other units so that programmers can code the units in isolation. The object-oriented paradigm fits these guidelines as designers represent complete concepts or real world entities as objects with approved interfaces for use by other objects. Like the outer membrane of a biological cell, the interface hides the internal implementation of the object, thus, isolating the code from interference by other objects. For many tasks, object-oriented programming has proven to be a very successful paradigm. Interestingly, the first object-oriented language (called Simula, which had even more features than C++) was designed in the 1960's, but object-oriented programming has only come into fashion in the 1990's. -
Reasoning About Programs Need: Definition of Works/Correct: a Specification (And Bugs) but Programs Fail All the Time
Good programs, broken programs? Goal: program works (does not fail) Reasoning about Programs Need: definition of works/correct: a specification (and bugs) But programs fail all the time. Why? A brief interlude on 1. Misuse of your code: caller did not meet assumptions specifications, assertions, and debugging 2. Errors in your code: mistake causes wrong computation 3. Unpredictable external problems: • Out of memory, missing file, network down, … • Plan for these problems, fail gracefully. 4. Wrong or ambiguous specification, implemented correctly Largely based on material from University of Washington CSE 331 A Bug's Life, ca. 1947 A Bug's Life Defect: a mistake in the code Think 10 per 1000 lines of industry code. We're human. -- Grace Hopper Error: incorrect computation Because of defect, but not guaranteed to be visible Failure: observable error -- program violates its specification Crash, wrong output, unresponsive, corrupt data, etc. Time / code distance between stages varies: • tiny (<second to minutes / one line of code) • or enormous (years to decades to never / millons of lines of code) "How to build correct code" Testing 1. Design and Verify Make correctness more likely or provable from the start. • Can show that a program has an error. 2. Program Defensively • Can show a point where an error causes a failure. Plan for defects and errors. • Cannot show the error that caused the failure. • make testing more likely to reveal errors as failures • Cannot show the defect that caused the error. • make debugging failures easier 3. Test and Validate Try to cause failures. • Can improve confidence that the sorts of errors/failures • provide evidence of defects/errors targeted by the tests are less likely in programs similar • or increase confidence of their absence to the tests. -
An Early Program Proof by Alan Turing F
An Early Program Proof by Alan Turing F. L. MORRIS AND C. B. JONES The paper reproduces, with typographical corrections and comments, a 7 949 paper by Alan Turing that foreshadows much subsequent work in program proving. Categories and Subject Descriptors: 0.2.4 [Software Engineeringj- correctness proofs; F.3.1 [Logics and Meanings of Programs]-assertions; K.2 [History of Computing]-software General Terms: Verification Additional Key Words and Phrases: A. M. Turing Introduction The standard references for work on program proofs b) have been omitted in the commentary, and ten attribute the early statement of direction to John other identifiers are written incorrectly. It would ap- McCarthy (e.g., McCarthy 1963); the first workable pear to be worth correcting these errors and com- methods to Peter Naur (1966) and Robert Floyd menting on the proof from the viewpoint of subse- (1967); and the provision of more formal systems to quent work on program proofs. C. A. R. Hoare (1969) and Edsger Dijkstra (1976). The Turing delivered this paper in June 1949, at the early papers of some of the computing pioneers, how- inaugural conference of the EDSAC, the computer at ever, show an awareness of the need for proofs of Cambridge University built under the direction of program correctness and even present workable meth- Maurice V. Wilkes. Turing had been writing programs ods (e.g., Goldstine and von Neumann 1947; Turing for an electronic computer since the end of 1945-at 1949). first for the proposed ACE, the computer project at the The 1949 paper by Alan M. -
The Advent of Recursion & Logic in Computer Science
The Advent of Recursion & Logic in Computer Science MSc Thesis (Afstudeerscriptie) written by Karel Van Oudheusden –alias Edgar G. Daylight (born October 21st, 1977 in Antwerpen, Belgium) under the supervision of Dr Gerard Alberts, and submitted to the Board of Examiners in partial fulfillment of the requirements for the degree of MSc in Logic at the Universiteit van Amsterdam. Date of the public defense: Members of the Thesis Committee: November 17, 2009 Dr Gerard Alberts Prof Dr Krzysztof Apt Prof Dr Dick de Jongh Prof Dr Benedikt Löwe Dr Elizabeth de Mol Dr Leen Torenvliet 1 “We are reaching the stage of development where each new gener- ation of participants is unaware both of their overall technological ancestry and the history of the development of their speciality, and have no past to build upon.” J.A.N. Lee in 1996 [73, p.54] “To many of our colleagues, history is only the study of an irrele- vant past, with no redeeming modern value –a subject without useful scholarship.” J.A.N. Lee [73, p.55] “[E]ven when we can't know the answers, it is important to see the questions. They too form part of our understanding. If you cannot answer them now, you can alert future historians to them.” M.S. Mahoney [76, p.832] “Only do what only you can do.” E.W. Dijkstra [103, p.9] 2 Abstract The history of computer science can be viewed from a number of disciplinary perspectives, ranging from electrical engineering to linguistics. As stressed by the historian Michael Mahoney, different `communities of computing' had their own views towards what could be accomplished with a programmable comput- ing machine. -
Instructors Prerequisites Time Commitment and Schedule
Instructors Anders Hejlsberg - Anders is a prominent Danish software engineer who co-designed several popular and commercially successful programming languages and development tools. He was the original author of Turbo Pascal and the chief architect of Delphi. He currently works for Microsoft as the lead architect of C# and core developer on TypeScript. Dan Wahlin - Dan Wahlin founded The Wahlin Group (http://www.TheWahlinGroup.com) which provides consulting and training services on Web technologies such as JavaScript, TypeScript, jQuery, AngularJS, SPAs, HTML5, ASP.NET and SharePoint. Dan is a Microsoft Regional Director and has been awarded Microsoft's MVP award multiple times for ASP.NET, Connected Systems and Silverlight. Dan blogs at http://weblogs.asp.net/dwahlin and writes regular columns for various technical magazines. Follow Dan on Twitter @DanWahlin. Prerequisites Working knowledge of JavaScript and experience coding in an object-oriented programming language. Time Commitment and Schedule 3-5 hours per week for 6 weeks. For students taking this course “live” content will be released twice per week typically on Tuesday and Thursday. Also note that all deadlines and release times are in UTC. This course will cover the following topics: Introduction to the TypeScript language Setting up your environment to work with TypeScript Understanding basic types Functions in TypeScript TypeScript classes (basics, constructors and inheritance, and properties) Interfaces in TypeScript Generics in TypeScript Deadlines and Grading Exercises are not graded but students will be asked to confirm that they have completed each homework assignment successfully as a part of the module assessment and will receive points for affirming that they have completed the exercises.