A History of Object- Oriented Programming Languages and Their Impact on Program Design and Software Development
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Equal Rights for Functional Objects Or, the More Things Change, The
ACM OOPS Messenger 4,4 (Oct. 1993), 2-27. Equal Rights for Functional Objects1 or, The More Things Change, The More They Are the Same2 Henry G. Baker Nimble Computer Corporation 16231 Meadow Ridge Way, Encino, CA 91436 (818) 986-1436 (818) 986-1360 FAX August, October, 1990, October, 1991, and April, 1992 This work was supported in part by the U.S. Department of Energy Contract No. DE-AC03-88ER80663 We argue that intensional object identity in object-oriented programming languages and databases is best defined operationally by side-effect semantics. A corollary is that "functional" objects have extensional semantics. This model of object identity, which is analogous to the normal forms of relational algebra, provides cleaner semantics for the value-transmission operations and built-in primitive equality predicate of a programming language, and eliminates the confusion surrounding "call-by-value" and "call-by-reference" as well as the confusion of multiple equality predicates. Implementation issues are discussed, and this model is shown to have significant performance advantages in persistent, parallel, distributed and multilingual processing environments. This model also provides insight into the "type equivalence" problem of Algol-68, Pascal and Ada. 1. INTRODUCTION Parallel, distributed and persistent programming languages are leaving the laboratories for more wide-spread use. Due to the substantial differences between the semantics and implementations of these languages and traditional serial programming languages, however, some of the most basic notions of programming languages must be refined to allow efficient, portable implementations. In this paper, we are concerned with defining object identity in parallel, distributed and persistent systems in such a way that the intuitive semantics of serial implementations are transparently preserved. -
The Evolution of Lisp
1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp. -
Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria
Department of Computer Science and Software Engineering Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Jiang Li Sleiman Rabah Concordia University Concordia University Montreal, Quebec, Concordia Montreal, Quebec, Concordia [email protected] [email protected] Mingzhi Liu Yuanwei Lai Concordia University Concordia University Montreal, Quebec, Concordia Montreal, Quebec, Concordia [email protected] [email protected] COMP 6411 - A Comparative studies of programming languages 1/139 Sleiman Rabah, Jiang Li, Mingzhi Liu, Yuanwei Lai This page was intentionally left blank COMP 6411 - A Comparative studies of programming languages 2/139 Sleiman Rabah, Jiang Li, Mingzhi Liu, Yuanwei Lai Abstract There are many programming languages in the world today.Each language has their advantage and disavantage. In this paper, we will discuss ten programming languages: C++, C#, Java, Groovy, JavaScript, PHP, Schalar, Scheme, Haskell and AspectJ. We summarize and compare these ten languages on ten different criterion. For example, Default more secure programming practices, Web applications development, OO-based abstraction and etc. At the end, we will give our conclusion that which languages are suitable and which are not for using in some cases. We will also provide evidence and our analysis on why some language are better than other or have advantages over the other on some criterion. 1 Introduction Since there are hundreds of programming languages existing nowadays, it is impossible and inefficient -
Seaver 2001 Catalog
GENERAL INFORMATION 1 PEPPERDINE UNIVERSITY Seaver College Catalog, 2001-2002 For More Information Requests for further information should be addressed to: Of fice of Admission, Seaver College Pe p p e r dine University Malibu, California 90263-4392 Telephone (310) 506-4392 Facsimile (310) 506-4861 General Information (310) 506-4000 ww w. p e p p e rd i n e . e d u Pe p p e r dine University, Volume Sixty-Four, Number One, March, 2001. Published by Pepperdine University, 24255 Pacific Coast Highway, Malibu, CA 90263-4392. An official publication of Pepperdine University, located at 24255 Pacific Coast Highway, Malibu, California 90263-4392. epperdine is a Christian university Pcommitted to the highest standards of academic excellence and Christian values, where students are strengthened for lives of purpose, service, and leadership. 8 As a Christian university, Pepperdine affirms: That God is That God is revealed uniquely in Christ That the educational process may not, with impunity, be divorced from the divine process That the student, as a person of infinite dignity, is the heart of the educational enterprise That the quality of student life is a valid concern of the University That truth, having nothing to fear from investigation, should be pursued relentlessly in every discipline That spiritual commitment, tolerating no excuse for mediocrity, demands the highest standards of academic excellence That freedom, whether spiritual, intellectual, or economic, is indivisible That knowledge calls, ultimately, for a life of service CONTENTS 3 CO N T E N T S Seaver College Academic Calendar. .4 Pr esident’s Message . -
Dynamically Typed Languages
Dynamically Typed Languages Laurence Tratt [email protected] Bournemouth University, Poole, Dorset, BH12 5BB, United Kingdom. Mar 13, 2009 Dynamically typed languages such as Python and Ruby have experienced a rapid grown in popularity in recent times. However, there is much confusion as to what makes these languages interesting relative to statically typed lan- guages, and little knowledge of their rich history. In this chapter I explore the general topic of dynamically typed languages, how they differ from statically typed languages, their history, and their defining features. 1 Introduction As computing is often split into software and hardware, so programming languages are often split into dynamically and statically typed languages. The traditional, simplified, definition of dynamically typed languages are that they do not enforce or check type- safety at compile-time, deferring such checks until run-time. While factually true, this definition leaves out what makes dynamically typed languages interesting|for example that they lower development costs [Ous98] and provide the flexibility required by specific domains such as data processing [MD04]. For many people, dynamically typed languages are the youthful face of a new style of programming introduced in the past few years. In fact, they trace their roots back to the earliest days of high-level programming languages in the 1950's via Lisp [McC60]. Many important techniques have been pioneered in dynamically typed languages from lexical scoping [SJ75] to Just-In-Time (JIT) compilation [Ayc03], and they remain a breeding ground for new ideas. Systems programming { seen as `serious' and thus demanding statically typed lan- guages { is often contrasted with scripting programming { seen as `amateurish' and thus needing little more than dynamically typed languages [Ous98]. -
Writing Cybersecurity Job Descriptions for the Greatest Impact
Writing Cybersecurity Job Descriptions for the Greatest Impact Keith T. Hall U.S. Department of Homeland Security Welcome Writing Cybersecurity Job Descriptions for the Greatest Impact Disclaimers and Caveats • Content Not Officially Adopted. The content of this briefing is mine personally and does not reflect any position or policy of the United States Government (USG) or of the Department of Homeland Security. • Note on Terminology. Will use USG terminology in this brief (but generally translatable towards Private Sector equivalents) • Job Description Usage. For the purposes of this presentation only, the Job Description for the Position Description (PD) is used synonymously with the Job Opportunity Announcement (JOA). Although there are potential differences, it is not material to the concepts presented today. 3 Key Definitions and Concepts (1 of 2) • What do you want the person to do? • Major Duties and Responsibilities. “A statement of the important, regular, and recurring duties and responsibilities assigned to the position” SOURCE: https://www.opm.gov/policy-data- oversight/classification-qualifications/classifying-general-schedule-positions/classifierhandbook.pdf • Major vs. Minor Duties. “Major duties are those that represent the primary reason for the position's existence, and which govern the qualification requirements. Typically, they occupy most of the employee's time. Minor duties generally occupy a small portion of time, are not the primary purpose for which the position was established, and do not determine qualification requirements” SOURCE: https://www.opm.gov/policy-data- oversight/classification-qualifications/classifying-general-schedule-positions/positionclassificationintro.pdf • Tasks. “Activities an employee performs on a regular basis in order to carry out the functions of the job.” SOURCE: https://www.opm.gov/policy-data-oversight/assessment-and-selection/job-analysis/job_analysis_presentation.pdf 4 Key Definitions and Concepts (2 of 2) • What do you want to see on resumes that qualifies them to do this work? • Competency. -
The Λ Abroad a Functional Approach to Software Components
The ¸ Abroad A Functional Approach To Software Components Een functionele benadering van software componenten (met een samenvatting in het Nederlands) Proefschrift ter verkrijging van de graad van doctor aan de Universiteit Utrecht op gezag van de Rector Magni¯cus, Prof. dr W.H. Gispen, ingevolge het besluit van het College voor Promoties in het openbaar te verdedigen op dinsdag 4 november 2003 des middags te 12.45 uur door Daniel Johannes Pieter Leijen geboren op 7 Juli 1973, te Alkmaar promotor: Prof. dr S.D. Swierstra, Universiteit Utrecht. co-promotor: dr H.J.M. Meijer, Microsoft Research. The work in this thesis has been carried out under the auspices of the research school IPA (Institute for Programming research and Algorithmics), and has been ¯nanced by Ordina. Printed by Febodruk 2003. Cover illustration shows the heavily cratered surface of the planet Mercury, photographed by the mariner 10. ISBN 90-9017528-8 Contents Dankwoord ix 1 Overview 1 2 H/Direct: a binary language interface for Haskell 5 2.1 Introduction ................................ 5 2.2 Background ................................ 6 2.2.1 Using the host or foreign language ............... 7 2.2.2 Using an IDL ........................... 8 2.2.3 Overview ............................. 9 2.3 The Foreign Function Interface ..................... 12 2.3.1 Foreign static import and export ................ 12 2.3.2 Variations on the theme ..................... 13 2.3.3 Stable pointers and foreign objects ............... 14 2.3.4 Dynamic import ......................... 15 2.3.5 Dynamic export ......................... 15 2.3.6 Implementing dynamic export .................. 18 2.3.7 Related work ........................... 19 iv Contents 2.4 Translating IDL to Haskell ...................... -
Comparative Programming Languages CM20253
We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily -
Sequence Decision Repeation
การเขียนโปรแกรมเบื5องต ้น (Introduction to Programming) http://www.thaiall.com/article/teachpro.htm การเขียนโปรแกรมเบื้องตน (Introduction to Programming) เว็บเพจสํารอง (Backup Webpages) : thaiabc.com | thaiall.korattown.com | perlphpasp.com | thaiall.com ปรับปรุง : 2555-01-23 (ปรับแกตัวอยาง pyramid) เรียนเขียนโปรแกรมระดับเทพ expert-programming-tutor.com Android C C++ JavaC# DataStructure เรียนเป็นระบบโดยเน ้นลงมือจริงทําจริ สารบัญ (Contents) ถารักจะเป็นนักคอมพิวเตอร .. ตองพยายามแบบ .. 1. แนวคิดการสอนเขียนโปรแกรม 2. ความหมายของ Structure Programming ฝนทั่งใหเป็นเข็ม 3. การเริ่มตนเขียนโปรแกรม sharpen an anVil to create a pin # 4. การบานคือ บันไดสูประสบการณ 5. ตัวอยางปิรามิด คือแบบฝึกหัดที่ยาก (เพิ่ม 4 ต.ย. สค.46) .. นักศึกษาของผม .. เวลาสอบตก จะพูดวา ถาพยายามจริง ๆ คงทําไดดีกวานีคงทําไดดีกวานี้้้้ 6. ตัวอยางโปรแกรมภาษา Pascal ผมก็จะถามวา กั๊กความพยายมของตน .. ไวทําไม 7. ตัวอยางโปรแกรมภาษา JaVa Script ขัขัขั้ขันตอนการเรียนรู้้้นตอนการเรียนรู เพื่เพื่่อเป็น่อเป็น Programmer 8. แบงระดับการเขียนโปรแกรม 4 ระดับ 1. เขียนโปรแกรมเบื้องตน 1 ภาษา ( Programming Language ) 9. แบบฝึกหัดสําหรับสอนการเขียนโปรแกรม (60 โจทย มค.47) 2. โครงสรางขอมูล ( Data Structures ) 10. โปรแกรมเมอรคนแรกของโลก (Augusta LoVelace Ada) 3. ระบบฐานขอมูล ( Database System ) 11. 143 ภาษาคอมพิวเตอร 4. การวิเคราะห และออกแบบระบบ ( System Analysis and Design ) 12. ภาษาคอมพิวเตอร (Time Line) 5. โครงงานนักศึกษา ( Student Project ) เพื่อฝึกปฏิบัติจริง เว็บเพจนี้ คือ ขั้นตอนที่ 1 สูการเป็น Programmer + ผูสนับสนุน ผูสนับสนุน + รับผูสนับสนุน 1. แนวคิดการสอนเขียนโปรแกรม หลายครั้งที่ผมตองเริ่มสอนเขียนโปรแกรม -
Oaklisp: an Object-Oriented Scheme with First Class Types
Oaklisp: an Object-Oriented Scheme with First Class Types Kevin J. l,ang and llarak A. Peaflmutter Department of Computer Science Carnegie-Mellon University Pittsburgh, PA 15213 Abstract several implications that are not immediately obvious. Because • The Scheme papers demonstrated that lisp could be made simpler function can be applied at a point distant in time and space from ilz and more expressive by elevating functions to the level of first class point of origin, it must be able to remember the bindings of any objects. Oaklisp shows that a message based language can derive variables that were visible when it was made. This additional similar benefits from having first class types. complexity is offset by the ability to write many previously primitive control structures at the user level and by the fact that the special Introduction mechanisms that lisp ordinarily uses for defining and applying Oaklisp is a message based, multiple inheritence dialect of lisp. functions can be dispensed with. Programs are written using lisp syntax, and traditional lisp data types In lisp, the car position of a function call is treated as the name of a coexist with a Smalltalk style class hierarchy. This paper assumes that function which is looked up in a special table and then applied to the the reader is familiar with one of the many object-oriented lisp dialects values obtained by evaluating the arguments of the call. In Scheme, the of this sort. and will therefore concentrate on the unique aspects of car of a call is an evaluated position. Although any expression can Oaklisp which are mostly due to the influence of Scheme. -
An Overview of Eulisp
LISP AND SYMBOLIC COMPUTATION An International Journal c Kluwer Academic Publishers Manufactured in The Netherlands An overview of EuLisp JULIAN PADGET japmathsbathacuk University of Bath School of Mathematical Sciences Bath BA AY United Kingdom GREG NUYENS nuyensilogcom Ilog Inc Landings Drive Mountain View CA USA HARRY BRETTHAUER bretthauergmdde German National Research Centre for Computer Science GMD POBox W Sankt Augustin FRG Keywords Lisp mo dules concurrency ob jectoriented programming conditions re ection Abstract This pap er is an abstracted version of the EuLisp denition As such it emphasizes those parts of the language that we consider the most imp ortant or note worthy while we just mention without much detail the elements that are included for completeness This is reected in the structure of the pap er which describ es the mo dule scheme the ob ject system and supp ort for concurrent execution in the main part and consigns the ma jority of the datatyp es to an app endix Intro duction EuLisp is a dialect of Lisp and as such owes much to the great b o dy of work that has b een done on language design in the name of Lisp over the last thirty years The distinguishing features of EuLisp are i the integration of the classical Lisp typ e system and the ob ject system into a single class hierarchy ii the complementary abstraction facilities provided by the class and the mo dule mechanism iii supp ort for concurrent execution Here is a brief summary of the main features of the language Classes are rstclass ob jects The -
A Bibliography of Publications in ACM SIGPLAN Notices, 1980–1989
A Bibliography of Publications in ACM SIGPLAN Notices, 1980{1989 Nelson H. F. Beebe University of Utah Department of Mathematics, 110 LCB 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 E-mail: [email protected], [email protected], [email protected] (Internet) WWW URL: http://www.math.utah.edu/~beebe/ 20 June 2019 Version 3.26 Title word cross-reference 1 [1625, 1284, 1078]. 1/83 [509]. 100 [1190]. 11 [95, 390, 139, 393]. 11/780 [139]. 1100 [58]. 16-bit [1828]. 164 [721]. 1838 [1612]. 1978 [39]. 1980 [1943, 245]. 1980's [760]. 1981 [1946, 312, 311, 345, 354]. 1982 [1948]. #16G [797]. 1983 [1952, 1953]. 1984 [1955, 1956]. 1985 [1142]. 1986 [1960, 1961, 1962, 18, 19]. 1987 ∗ 3 + [1637]. 2 [1822]. = [328, 1637]. [1586]. [20, 25, 1239, 1357]. 1989 [39]. 198x TM 8 [1105]. [1827]. Ada [140]. [1850]. λ [39, 1388]. [1887]. n [1108]. N ≤ 8 [998, 1145, 1011]. ! 0 [1914]. [1637]. 2' [832, 1004, 941, 1383, 918, 1191, 1500, 1006, 1193, 919, 920, 949, 1007, 1145, 1196, * [918]. 950, 1376, 526, 843, 1158, 837, 1633, 800, 782, 913, 748, 1155, 1149, 791, 790, 1554, -calculus [1887]. -dimensional [1822]. 452, 634, 459, 1183, 966, 688, 842, 967]. 2000 -ively [1521]. [1833, 1844, 1847]. /information [195]. 3 [1924, 1477]. 32 [375, 371]. 32-bit [1828]. 370 [1203]. 0-201-17928-8 [1614]. 002R [1356]. 1 2 432 [650, 387]. 4381 [1269]. ACM-SIGPLAN [1943]. ACM/SIGPLAN [1971]. Acore [1645]. 6 [619]. 68 [513, 66, 107].