DOCSLIB.ORG

BETWEEN PROGRAMMING LANGUAGES Toward Solutions to Problems of Diversity

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
BETWEEN PROGRAMMING LANGUAGES Toward Solutions to Problems of Diversity BETWEEN PROGRAMMING LANGUAGES Toward Solutions to Problems of Diversity A thesis submitted in partial fulfilment of the requirements for the Degree of Doctor of Philosophy in Computer Science in the University of Canterbury by Robert Lewis Biddle University of Canterbury 1987 PHYSICAL SCIENCES LIBRARY THESIS Preface I began this project with a great deal of idealism, having decided that there wa~ a topic in Computer Science that interested me enough to spend considerable time in research. This topic, programming language diversity, has served me well- perhaps too well for the scope of the project. The aspects that interest me most have lead me away from programming languages, to the contexts of wider language and art. In those contexts, the problems of programming language diversity do not admit any straightforward solution, perhaps not any solution at all. This does not displease me, and I look forward to exploring this subject in general, free from concern with "solution". In practical computer programming, however, there do remain problems of incompatibility in the diversity of programming languages. Accordingly, I have studied the practical methods that have addressed these problems, and concluded that while most methods are successful in limited ways, there is a more general approach suggested. This new approach, "interprogramming", is a collaboration between programming languages, relying on operating systems support. I have described how this collaboration could work, and investigated its possibilities and implications with several programming languages and operating systems. I think it's a good idea: not startlingly dramatic, but a helpful integration of techniques from several areas. I end the project with idealism still, but weary. I believe the topic is an important one, though little directly discussed, and hope my surveying and exploration worthwhile. More work does need to be done: more theory, more development, more practice. But the topic is very large, and the directions to pursue are themselves divergent. I feel my perspective has become rather lost, atid I look forward very much to finding a new one. I would like to express my appreciation to those in whose companionship I have worked on this project: my supervisor, Bruce McKenzie, and all the staff and students of the Computer Science department at the University of Canterbury. I'd particularly like to thank the postgraduate students of the department for many stimulating discussions and shared explorations of computing, and for their general enthusiasm and devotion to the subject: I wish them well. I am also very grateful to those responsible for U1e Commonwealth Scholarship that brought me to New Zealand, now my home. Projects like this are sometimes dedicated to those personally close, but I have always found that inappropriate. I dedicate this project to other naive students interested in pursuing the same topic: I hope my work maps out the area, shows where many directions lead, and helps them understand the difficulties and opportunities concealed. · To my family, to Anthea, I dedicate: new time, new energy, new life. Robert ABSTRACT The success of programming language design is so great and diverse that the resulting incompatibilities have become an important practical problem. This is a study of possible solutions. J:he first part is a consideration of reasoning to convergence. An operational model of programming language is used, and both implementation and application aspects are examined, in application encompassing approaches of linguistic precedent, mathematical theory, psychological principle, and empirical analysis. Some progress seems evident in looking at language implementation, but in language application the difficulty of understanding the human factor seriously impedes further reasoning. The second part is a survey of practical methods for coping with programming language diversity, limiting the diversity or limiting the effects of the problem. Two general approaches are explored, compromise in new design and cooperation in accepting existing design, each comprising a variety of techniques. While no one method was seen completely successful, all had specific advantages and some, particularly cooperative methods, seemed open to further development The third part is a proposal for a collaborative strategy here called "interprogramming". In this approach it is suggested that programming language design include facilities here called "context openings" for general connection and communication beyond the language. Supporting environments such as operating systems would need to provide facilities realising such connection and communication. At the programming language level, this requires precise control over input/output and related concerns. At the operating system level, this requires multitasking with memory protection and message passing, or similar capabilities. Exploration of the approach is made involving several programming languages and two operating systems, and some related new software is presented. Most programming languages seem accepting, and operating systems design capable. The strategy should be practical and portable, adaptable with existing design and helpful in new design. As far as programming language diversity is seen as an technical problem, the interprogramming strategy is seen as a general and promising approach to solution. CONTENTS PART: CHAPTER Page INTRODUCTION I INTRODUCTION 1 I PERSONAL MOTIVATION 1 ll PERSPECTIVE 2 Ill PLAN 4 ONE: CONVERGING 6 II CAN WE REASON TO CONVERGENCE? 7 I INIMPLEMENTATION 8 ll IN APPLICATION 10 1 Linguistic Precedence 11 2 Mathematical Approach 13 3 Psychological Ap.Proach 17 4 Empirical Analys1s 21 Ill CONTEXT 24 1 From Programming Language to Natural Language 24 2 From Natural Language 27 IV CONCLUSION 35 TWO: COPING 36 III COPING BY COMPROMISING 37 I STANDARDISATION 37 II MINIMISATION 41 Ill MULTIPLICATION 45 IV EXTENSION 49 V ABSTRACTION 55 VI CONCLUSION 59 IV COPING BY COOPERATING 60 I TRANSLATION 60 II INCLUSION 63 Ill FLEXIBLE DEFINITION 67 IV COMMON IMPLEMENTATION 69 V PROGRAMME COORDINATION 75 VI CONCLUSION 79 THREE: COLLABORATING 80 V COLLABORATION COOPERATION BY DESIGN 81 I INTERPROGRAMMING 81 II CONNECTION 84 III COMMUNICATION 91 IV CONTEXT OPENING 96 V CONCLUSION 100 VI INTERPROGRAMMING: INSIDE PROGRAMMING LANGUAGES 103 I FORTRAN 104 II PASCAL 109 III C 116 IV ICON 119 V PROLOG 123 VI guASI PROGRAMMING LANGUAGE 126 . VII ONCLUSION 131 VII INTERPROGRAMMING: OUTSIDE PROGRAMMING LANGUAGES 134 II PRIMOS 136 lli UNIX 142 III PROGRAMMINGLANGUAGES BETWEEN PROGRAMMING LANGUAGES 160 III CONCLUSION 170 CONCLUSION 172 VIII CONCLUSION 173 REFERENCES 183 References For Frequently Mentioned Languages And Systems 199 APPENDICES 200 LIST OF FIGURES Figure Title Page 1.1.1 An altemati ve in Pascal data stmcture notation. 2 1.2.1 Structural relationships in the tenninology used. 3 2.3.1 An example of matching words and images. 28 2.3.2 Apparant hierarchy in colour tenns across languages. 29 3.2.1 Orthogonality in Algol 68 data. 42 3.3.1 Programme illustrating PL/I's heritage. 46 3.4.1 C preprocessor used to create Algol68like disguise. 51 3.4.3 How a case statement can he added to Smalltalk. 53 3.5.1 Jackson Structured Programming diagram. 56 3.5.2 Programme fragment written in Guarded Commands. 58 3.6.1 Summary of advantages and disadvantages of compromise. 59 4.2.1 Bossi et al. 's decomposition of Ada into a language hierarchy. 64 4.3.1 An Algol68 program in two different representations. 67 4.4.1 Communication between common levels of implementation. 71 4.5.1 Fragment of JCL/360. 76 4.5.2 Control structures of the Unix (Bourne) Shell. 76 4.6.1 Summary of advantages and disadvantages of cooperation. 79 5.1.1 Interprogramming through "context openings". 82 5.2.1 Levels of parallelism for coordination. 85 5.2.2 Different models for coordination. 88 5.3.1 Programmes in different languages linked via a third. 94 5.4.1 Most common openings in programming language design. 97 6.1.1 Fortran Interprogramming: CALL-EXTRINSIC-ANSWER. 106 6.2.1 Pascal Interprogramming: program header and extrinsics. 113 6.3.1 C Interprogramming: fcall and ffunc. 117 6.4.1 Icon Interprogramming: call and answer. 121 6.5.1 Prolog Interprogramming: t:request and treply. 124 6.6.1 Doris Interprogramming: .req and .rep. 127 6.6.2 Chef Interprogramming: XCandQF. 129 7.1.1 Primos process stack structure showing command levels. 137 7.1.2 Primos outside-process interprogramme structure. 138 7.1.3 Primos interprogramming through a coordinated file. 140 7.2.1 Unix process operations. 142 7.2.2 Unix process structure. 143 7.2.3 Unix shell pipeline between programmes. 145 7.2.4 Using a Unix pipe to process serial data. 146 7.2.5 Representations of a hierarchy of communicating processes. 149 7.2.6 Simple implementation of Unix "tagged" pipes. 150 7.2.7 Using tagged pipes to build interprogramming connections. 152 7.2.8 Unix process openings . 154 . 7.2.9 Generality of openings imitated via intennediate programme. 155 7.3.1 Rap programme for automatic file transfer. 161 7.3.2 Structure of Mux directives. 163 7.3.3 Fragments of Mux files of interprogrammed Icon and Fortran 163 7.3.4 Mux file with multiplexed C and documentation. 164 7.3.5 Lys programme for simple data translation. 167 7.3.6 Mux prefix file for Lys. 168 1 CHAPTER I INTRODUCTION Programming language design is generally thought to have proven a useful and successful pursuit in support of practical computing. While apparently easing some problems, however, continuing design has itself worsened others. In practice, design requires implementation, and the continuing variety in computing facilities has thus lead to interest in portability, both in implementation and in design. But beyond ti1is concern is another, for the diversity of programming language design is itself a practical problem. Programming language diversity is a problem when one language alone is restrictive. There arc problems of availability: when a necessary or useful programme or programme component already exists - but in an incompatible language.
Load more

Recommended publications
  • GNU/Linux AI & Alife HOWTO
    GNU/Linux AI & Alife HOWTO GNU/Linux AI & Alife HOWTO Table of Contents GNU/Linux AI & Alife HOWTO......................................................................................................................1 by John Eikenberry..................................................................................................................................1 1. Introduction..........................................................................................................................................1 2. Symbolic Systems (GOFAI)................................................................................................................1 3. Connectionism.....................................................................................................................................1 4. Evolutionary Computing......................................................................................................................1 5. Alife & Complex Systems...................................................................................................................1 6. Agents & Robotics...............................................................................................................................1 7. Statistical & Machine Learning...........................................................................................................2 8. Missing & Dead...................................................................................................................................2 1. Introduction.........................................................................................................................................2
    [Show full text]
  • Embedded Linux Systems with the Yocto Project™
    OPEN SOURCE SOFTWARE DEVELOPMENT SERIES Embedded Linux Systems with the Yocto Project" FREE SAMPLE CHAPTER SHARE WITH OTHERS �f, � � � � Embedded Linux Systems with the Yocto ProjectTM This page intentionally left blank Embedded Linux Systems with the Yocto ProjectTM Rudolf J. Streif Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales depart- ment at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. Visit us on the Web: informit.com Cataloging-in-Publication Data is on file with the Library of Congress.
    [Show full text]
  • X-Machines for Agent-Based Modeling FLAME Perspectives CHAPMAN & HALL/CRC COMPUTER and INFORMATION SCIENCE SERIES
    X-Machines for Agent-Based Modeling FLAME Perspectives CHAPMAN & HALL/CRC COMPUTER and INFORMATION SCIENCE SERIES Series Editor: Sartaj Sahni PUBLISHED TITLES ADVERSARIAL REASONING: COMPUTATIONAL APPROACHES TO READING THE OPPONENT’S MIND Alexander Kott and William M. McEneaney COMPUTER-AIDED GRAPHING AND SIMULATION TOOLS FOR AUTOCAD USERS P. A. Simionescu DELAUNAY MESH GENERATION Siu-Wing Cheng, Tamal Krishna Dey, and Jonathan Richard Shewchuk DISTRIBUTED SENSOR NETWORKS, SECOND EDITION S. Sitharama Iyengar and Richard R. Brooks DISTRIBUTED SYSTEMS: AN ALGORITHMIC APPROACH, SECOND EDITION Sukumar Ghosh ENERGY-AWARE MEMORY MANAGEMENT FOR EMBEDDED MULTIMEDIA SYSTEMS: A COMPUTER-AIDED DESIGN APPROACH Florin Balasa and Dhiraj K. Pradhan ENERGY EFFICIENT HARDWARE-SOFTWARE CO-SYNTHESIS USING RECONFIGURABLE HARDWARE Jingzhao Ou and Viktor K. Prasanna FROM ACTION SYSTEMS TO DISTRIBUTED SYSTEMS: THE REFINEMENT APPROACH Luigia Petre and Emil Sekerinski FUNDAMENTALS OF NATURAL COMPUTING: BASIC CONCEPTS, ALGORITHMS, AND APPLICATIONS Leandro Nunes de Castro HANDBOOK OF ALGORITHMS FOR WIRELESS NETWORKING AND MOBILE COMPUTING Azzedine Boukerche HANDBOOK OF APPROXIMATION ALGORITHMS AND METAHEURISTICS Teofilo F. Gonzalez HANDBOOK OF BIOINSPIRED ALGORITHMS AND APPLICATIONS Stephan Olariu and Albert Y. Zomaya HANDBOOK OF COMPUTATIONAL MOLECULAR BIOLOGY Srinivas Aluru HANDBOOK OF DATA STRUCTURES AND APPLICATIONS Dinesh P. Mehta and Sartaj Sahni PUBLISHED TITLES CONTINUED HANDBOOK OF DYNAMIC SYSTEM MODELING Paul A. Fishwick HANDBOOK OF ENERGY-AWARE AND GREEN COMPUTING Ishfaq Ahmad and Sanjay Ranka HANDBOOK OF GRAPH THEORY, COMBINATORIAL OPTIMIZATION, AND ALGORITHMS Krishnaiyan “KT” Thulasiraman, Subramanian Arumugam, Andreas Brandstädt, and Takao Nishizeki HANDBOOK OF PARALLEL COMPUTING: MODELS, ALGORITHMS AND APPLICATIONS Sanguthevar Rajasekaran and John Reif HANDBOOK OF REAL-TIME AND EMBEDDED SYSTEMS Insup Lee, Joseph Y-T.
    [Show full text]
  • Rmox: a Raw-Metal Occam Experiment
    Communicating Process Architectures – 2003 269 Jan F. Broenink and Gerald H. Hilderink (Eds.) IOS Press, 2003 RMoX: A Raw-Metal occam Experiment Fred BARNES†, Christian JACOBSEN† and Brian VINTER‡ † Computing Laboratory, University of Kent, Canterbury, Kent, CT2 7NF, England. {frmb2,clj3}@kent.ac.uk ‡ Department of Mathematics and Computer Science, University of Southern Denmark, Odense, Denmark. [email protected] Abstract. Operating-systems are the core software component of many modern com- puter systems, ranging from small specialised embedded systems through to large distributed operating-systems. This paper presents RMoX: a highly concurrent CSP- based operating-system written in occam. The motivation for this stems from the overwhelming need for reliable, secure and scalable operating-systems. The major- ity of operating-systems are written in C, a language that easily offers the level of flexibility required (for example, interfacing with assembly routines). C compilers, however, provide little or no mechanism to guard against race-hazard and aliasing er- rors, that can lead to catastrophic run-time failure (as well as to more subtle errors, such as security loop-holes). The RMoX operating-system presents a novel approach to operating-system design (although this is not the first CSP-based operating-system). Concurrency is utilised at all levels, resulting in a system design that is well defined, easily understood and scalable. The implementation, using the KRoC extended oc- cam, provides guarantees of freedom from race-hazard and aliasing errors, and makes extensive use of the recently added support for dynamic process creation and channel mobility. Whilst targeted at mainstream computing, the ideas and methods presented are equally applicable for small-scale embedded systems — where advantage can be made of the lightweight nature of RMoX (providing fast interrupt responses, for ex- ample).
    [Show full text]
  • Computational PHYSICS Shuai Dong
    Computational physiCs Shuai Dong Evolution: Is this our final end-result? Outline • Brief history of computers • Supercomputers • Brief introduction of computational science • Some basic concepts, tools, examples Birth of Computational Science (Physics) The first electronic general-purpose computer: Constructed in Moore School of Electrical Engineering, University of Pennsylvania, 1946 ENIAC: Electronic Numerical Integrator And Computer ENIAC Electronic Numerical Integrator And Computer • Design and construction was financed by the United States Army. • Designed to calculate artillery firing tables for the United States Army's Ballistic Research Laboratory. • It was heralded in the press as a "Giant Brain". • It had a speed of one thousand times that of electro- mechanical machines. • ENIAC was named an IEEE Milestone in 1987. Gaint Brain • ENIAC contained 17,468 vacuum tubes, 7,200 crystal diodes, 1,500 relays, 70,000 resistors, 10,000 capacitors and around 5 million hand-soldered joints. It weighed more than 27 tons, took up 167 m2, and consumed 150 kW of power. • This led to the rumor that whenever the computer was switched on, lights in Philadelphia dimmed. • Input was from an IBM card reader, and an IBM card punch was used for output. Development of micro-computers modern PC 1981 IBM PC 5150 CPU: Intel i3,i5,i7, CPU: 8088, 5 MHz 3 GHz Floppy disk or cassette Solid state disk 1984 Macintosh Steve Jobs modern iMac Supercomputers The CDC (Control Data Corporation) 6600, released in 1964, is generally considered the first supercomputer. Seymour Roger Cray (1925-1996) The father of supercomputing, Cray-1 who created the supercomputer industry. Cray Inc.
    [Show full text]
  • 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.
    [Show full text]
  • Creating Ipsec and SSL/TLS Tunnels in Linux What's New
    FACEBOOK | WEBGOAT | TOR | DNS | SLEUTHKIT | PACKETFENCE LINUX JOURNAL ™ UU Getting the Most Out of GCC UU Securing Open-Source Phones SECURITY UU How to Store Passwords Safely UU New Column: Hack and / Since 1994: The Original Magazine of the Linux Community JANUARY 2008 | ISSUE 165 Facebook | WebGoat | Tor | DNS | Sleuthkit | PacketFence | GCC Qtopia SXE VPNs | DNS Sleuthkit PacketFence | Tor | WebGoat Facebook SECURITY UU Learn the Path to a More Secure System UU Use Autopsy and Sleuthkit to Analyse Security Breaches UU Discover Dangerous Flaws in Your DNS Infrastructure JANUARY www.linuxjournal.com 2008 Creating IPsec and SSL/TLS $5.99US $6.99CAN 01 ISSUE + Tunnels in Linux 165 What’s New with Eric Raymond? 0 74470 03102 4 lj023:lj018.qxd 11/12/2007 5:36 PM Page 1 The Straight Talk People SM SINCE 1991 ABERDEEN TRUE QUAD-CORE SERVERS. UP TO 16 INDIVIDUAL CORES. ABERDEEN STONEHAVEN A135 ABERDEEN STONEHAVEN A151 ABERDEEN STONEHAVEN A284 Four Quad-Cores 1U 3TB Quad Quad-Core HPC Server 1U 4TB Dual Quad-Core Server 2U 8TB Dual Quad-Core Server • Up to four Quad-Core AMD Opteron™ 8000 Series processors • Up to two Quad-Core AMD Opteron 2000 Series processors • Up to two Quad-Core AMD Opteron 2000 Series processors • nVIDIA nForce Pro Chipset with 64-Bit Support • nVIDIA nForce Pro Chipset with 64-Bit Support • nVIDIA nForce Pro Chipset with 64-Bit Support • Up to 64GB 667MHz ECC Registered DDR2 SDRAM • Up to 32GB 667MHz ECC Registered DDR2 SDRAM • Up to 64GB 667MHz ECC Registered DDR2 SDRAM • Up to 3 x 1TB (3TB Total) Hot-Swap SATA Hard
    [Show full text]
  • Modernizing Applications with IBM CICS
    Front cover Modernizing Applications with IBM CICS Russell Bonner Sophie Green Ezriel Gross Jim Harrison Debra Scharfstein Will Yates Redpaper IBM Redbooks Modernizing Applications with IBM CICS December 2020 REDP-5628-00 Note: Before using this information and the product it supports, read the information in “Notices” on page v. First Edition (December 2020) © Copyright International Business Machines Corporation 2020. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . .v Trademarks . vi Preface . vii Accompanying education course . vii Authors. viii Now you can become a published author, too! . viii Comments welcome. viii Stay connected to IBM Redbooks . ix Chapter 1. Introduction. 1 1.1 CICS and the hybrid multi-cloud . 2 1.2 Migrating to the hybrid multi-cloud . 2 1.2.1 Maintaining the status quo . 2 1.2.2 Using cloud-native applications. 2 1.2.3 Modernizing existing applications . 3 1.3 CICS Hello World COBOL example . 3 Chapter 2. IBM CICS application development . 5 2.1 Application development in CICS . 6 2.1.1 Batch processing versus online transaction processing . 6 2.1.2 Programming paradigm. 6 2.1.3 Basic architecture of a CICS program. 7 2.1.4 CICS resources. 9 2.2 CICS sample application. 10 2.3 CICS modernization . 11 2.4 CICS built-in transactions . 12 2.4.1 CICS Execute Command Interpreter . 12 2.4.2 CICS Execution Diagnostic Facility. 13 Chapter 3. Coding applications to run in IBM CICS. 15 3.1 Introduction to the EXEC CICS application programming interface .
    [Show full text]
  • Dissertation Submitted in Partial Fulfillment of the Requirements for The
    ON THE HUMAN FACTORS IMPACT OF POLYGLOT PROGRAMMING ON PROGRAMMER PRODUCTIVITY by Phillip Merlin Uesbeck Master of Science - Computer Science University of Nevada, Las Vegas 2016 Bachelor of Science - Applied Computer Science Universit¨at Duisburg-Essen 2014 A dissertation submitted in partial fulfillment of the requirements for the Doctor of Philosophy { Computer Science Department of Computer Science Howard R. Hughes College of Engineering The Graduate College University of Nevada, Las Vegas December 2019 c Phillip Merlin Uesbeck, 2019 All Rights Reserved Dissertation Approval The Graduate College The University of Nevada, Las Vegas November 15, 2019 This dissertation prepared by Phillip Merlin Uesbeck entitled On The Human Factors Impact of Polyglot Programming on Programmer Productivity is approved in partial fulfillment of the requirements for the degree of Doctor of Philosophy – Computer Science Department of Computer Science Andreas Stefik, Ph.D. Kathryn Hausbeck Korgan, Ph.D. Examination Committee Chair Graduate College Dean Jan Pedersen, Ph.D. Examination Committee Member Evangelos Yfantis, Ph.D. Examination Committee Member Hal Berghel, Ph.D. Examination Committee Member Deborah Arteaga-Capen, Ph.D. Graduate College Faculty Representative ii Abstract Polyglot programming is a common practice in modern software development. This practice is often con- sidered useful to create software by allowing developers to use whichever language they consider most well suited for the different parts of their software. Despite this ubiquity of polyglot programming there is no empirical research into how this practice affects software developers and their productivity. In this disser- tation, after reviewing the state of the art in programming language and linguistic research pertaining to the topic, this matter is investigated by way of two empirical studies with 109 and 171 participants solving programming tasks.
    [Show full text]
  • A Port of the MINIX OS to the Powerpc Platform
    MinixPPC A port of the MINIX OS to the PowerPC platform Creating a programming model for architecture independency Master Thesis Computer Science Ingmar A. Alting September 15, 2006 First reader and supervisor: Andrew S. Tanenbaum Dept. of Computer Science Faculty of Sciences Vrije Universiteit De Boelelaan 1081A 1081 HV Amsterdam, the Netherlands e-mail: [email protected] Second reader: Herbert Bos Dept. of Computer Science Faculty of Sciences Vrije Universiteit Amsterdam De Boelelaan 1081A 1081 HV Amsterdam, the Netherlands e-mail: [email protected] Thesis by: Ingmar A. Alting Weth. W. de Boerstraat 18 1788AT Den Helder, the Netherlands email: [email protected] Abstract The main goal of this project is to indicate what it means to port an operating system from one architecture to another, and provide a programming paradigm that would make future ports easy and fast. The “natively” supported architecture of MINIX is the IBM PC compatible, that's built around the Intel architecture. This is a CISC architecture with hardware support for easy stack usage. The choice for the POWER architecture could not have been further away as this is a RISC architecture, and completely” different in many ways. This thesis will focuses on the model created for creating portable system code. Not to be confused with portable programs using a “standard” API. It will describe the changes made and problems faced porting the MINIX code base. The places where changes are made can be viewed as hotspots. For every new architecture compatibility problems are to be expected there. Some hotspots are used as example and the solution taken for MinixPPC is presented to the reader.
    [Show full text]
  • IT Acronyms.Docx
    List of computing and IT abbreviations /.—Slashdot 1GL—First-Generation Programming Language 1NF—First Normal Form 10B2—10BASE-2 10B5—10BASE-5 10B-F—10BASE-F 10B-FB—10BASE-FB 10B-FL—10BASE-FL 10B-FP—10BASE-FP 10B-T—10BASE-T 100B-FX—100BASE-FX 100B-T—100BASE-T 100B-TX—100BASE-TX 100BVG—100BASE-VG 286—Intel 80286 processor 2B1Q—2 Binary 1 Quaternary 2GL—Second-Generation Programming Language 2NF—Second Normal Form 3GL—Third-Generation Programming Language 3NF—Third Normal Form 386—Intel 80386 processor 1 486—Intel 80486 processor 4B5BLF—4 Byte 5 Byte Local Fiber 4GL—Fourth-Generation Programming Language 4NF—Fourth Normal Form 5GL—Fifth-Generation Programming Language 5NF—Fifth Normal Form 6NF—Sixth Normal Form 8B10BLF—8 Byte 10 Byte Local Fiber A AAT—Average Access Time AA—Anti-Aliasing AAA—Authentication Authorization, Accounting AABB—Axis Aligned Bounding Box AAC—Advanced Audio Coding AAL—ATM Adaptation Layer AALC—ATM Adaptation Layer Connection AARP—AppleTalk Address Resolution Protocol ABCL—Actor-Based Concurrent Language ABI—Application Binary Interface ABM—Asynchronous Balanced Mode ABR—Area Border Router ABR—Auto Baud-Rate detection ABR—Available Bitrate 2 ABR—Average Bitrate AC—Acoustic Coupler AC—Alternating Current ACD—Automatic Call Distributor ACE—Advanced Computing Environment ACF NCP—Advanced Communications Function—Network Control Program ACID—Atomicity Consistency Isolation Durability ACK—ACKnowledgement ACK—Amsterdam Compiler Kit ACL—Access Control List ACL—Active Current
    [Show full text]
  • Ofthe European Communities
    ISSN 0378-6978 Official Journal L 81 Volume 27 of the European Communities 24 March 1984 English edition Legislation Contents I Acts whose publication is obligatory II Acts whose publication is not obligatory Council 84/ 157/EEC : * Council Decision of 28 February 1984 adopting the 1984 work programme for a European programme for research and development in information technologies (ESPRIT) 2 Acts whose titles are printed in light type are those relating to day-to-day management of agricultural matters, and are generally valid for a limited period . The titles of all other Acts are printed in bold type and preceded by an asterisk . 24 . 3 . 84 Official Journal of the European Communities No L81 / 1 II (Acts whose publication is not obligatory) COUNCIL COUNCIL DECISION of 28 February 1984 adopting the 1984 work programme for a European programme for research and development in information technologies (ESPRIT) (84/ 157/EEC) THE COUNCIL OF THE EUROPEAN HAS DECIDED AS FOLLOWS : COMMUNITIES, Having regard to the Treaty establishing the Article 1 European Economic Community, J The ESPRIT work programme as set out in the Having regard to Council Decision 84/ 130/EEC of Annex is hereby adopted for 1984 . 28 February 1984 concerning a European pro­ gramme for research and development in informa­ tion technologies ( ESPRIT) ('), and in particular Article 2 Article 3 (2) thereof, This Decision shall take effect on the day of its Having regard to the draft work programme submit­ publication in the Official Journal of the European ted by the Commission , Communities . Whereas, at talks organized by the Commission ser­ vices , industry and the academic world have given Done at Brussels , 28 February 1984 .
    [Show full text]