DOCSLIB.ORG

Modern Fortran

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Modern Fortran Modern Fortran Support for new Fortran Language Elements by Intel® Fortran Composer XE Agenda • Introduction – Fortran History – Why Fortran • Modern Fortran – Some selected Features – Array Notation – Object-oriented programming – Do-Concurrent – Coarray Fortran • Intel Fortran Composer XE – Standard Support – Implementation of Coarrays • References/Summary Credit: Thanks to Mr. Reinhold Bader, LRZ Garching/Germany, who provided some of the slides used here Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Your Memory of Fortran ? IF (AA(J+L).EQ.0.0)GOTO42 TEST=TEST-1 THETA=ATAN(X,Y) GOTO30 42 TEST=TEST+1 THETA=ATAN(-X,Y) 30 CONTINUE “GOD is REAL (unless declared INTEGER)." Copyright© 2012, Intel Corporation. All rights reserved. 4 *Other brands and names are the property of their respective owners. FORTRAN Started 1954 as “ IBM Mathematical Formula Translation System” but abbreviated later to FORmula TRANslation • created by IBM developer John Backus and released to public in 1957 – Now called “Fortran I” • designed for scientific and engineering computation John Backus 1924-2007 • FORTRAN is the oldest programming language actively in use today • FORTRAN is still very popular for new software development in scientific applications • Many FORTRAN programs written +40 years ago are still in active use today! Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. IBM 704 Fortran manual, 1957 Copyright© 2012, Intel Corporation. All rights reserved. 6 *Other brands and names are the property of their respective owners. FORTRAN–History [1] • FORTRAN 1957 (“Fortran I”) • FORTRAN II, III – Clean up, separate module compilation • FORTRAN IV – IF statement, type declarations • FORTRAN 66 - ANSI Standard of 1966 – Clean up of FORTRAN IV • FORTRAN 77 - ANSI Standard released 1978 – CHARACTER data type, new DO-Loop semantic, IF-THEN-ELSE • FORTRAN 90 – ANSI Standard released 1992 – Free form, array section, dynamic memory allocation, derived types, modular programming • FORTRAN 95 – ANSI Standard released 1997 – Minor update of FORTRAN90; FORALL, PURE and ELEMENTAL routines Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. FORTRAN– History [2] • FORTRAN 2003 – ANSI Standard released 2003 – Object-oriented programming, C-interoperability, IEEE- arithmetic, parameterized derived types, ASSOCIATE, procedure pointers, … • FORTRAN 2008 – latest ANSI standard, released June 2010 – Coarrays, DO-CONCURRENT, bit manipulation intrinsics, sub-module concept Many dialects influenced FORTRAN standardization and all compilers support some non-standard extensions of these dialects – Cray Fortran (“Cray Pointers”) – DEC Fortran Some too progressive extensions like HPF-High Performance Fortran did not find much attention outside of academic research Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Why Fortran? A few Selected Arguments • Arrays are not only part of the language syntax but have representation in run-time environment – Different from C/C++ – Implies: – Easier programming (e.g. multi-dimensional array procedure arguments with variable bounds) – Better code generation (faster code) • Safer (more restrictive) semantic – POINTER much safer than for C/C++ – Aliasing of procedure arguments limited – Implies: More compiler optimizations, thus faster code • Module concept • Portability – 32 to 64 bit porting -> no changes needed ! – No problem to compile +40 year old programs • Existing code base Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Sample: Triade in Fortran and C C/C++ : void triade( int a[], int b[], int c[], int n) { Both vectorize int j; but C-version for (j=0; j<n; j++) requires run- a[j] = b[j] + 3.14 * c[j]; time alias } checking for ‘a’, ‘b’ and ‘a’, ’c’ Fortran: Fortran does subroutine triade(a, b, n) not allow 2 integer n arguments to integer, dimension (1:n) :: a,b,c do j = 1,n alias in case a(j) = b(j) + 3.14 * c(j) one is modified: end do Code is faster end subroutine triade Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Agenda • Introduction – Fortran History – Why Fortran • Modern Fortran – Some selected Features – Array Notation – Object-oriented programming – Do-Concurrent – Coarray Fortran • Intel® Fortran Composer XE – Standard Support – Implementation of Coarrays • References/Summary Credit: Thanks to Mr. Reinhold Bader, LRZ Garching/Germany, who provided some of the slides used here Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Array Sections • Introduced by FORTRAN90 • Similar to array notation of Intel® Cilk Plus introduced 20 years later as C/C++ extension – But syntax different: <lower bound>:<upper bound> [:<stride>] – And semantic for assignment different: LHS and RHS may overlap in Fortran, not in Cilk Plus !! A(1:10, 1:3) A(1:10:2, 1:10:2) 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 1 Example 2 2 3 3 REAL :: A(10, 10) 4 4 5 5 6 6 7 7 8 8 9 9 Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Modules in Fortran module mymodule ! My very own module use m1 ! import all objects of module m1 use m2, only : x, y ! import only x, y from module m2 implicit none !! Module variables go here real , dimension (20) :: x subroutine s1(a, b) ! An external procedure contains subroutine s2(foo , bar) ! An internal procedure end subroutine s2 end subroutine s2 end module mymodule Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Interoperation with C Portable, Standardized Interface Invoke C functions in a standard- Example C prototype defined way • Today (F2003) focusing on Fortran using C- void My_C_Subr(int, double *); objects • Future standard: Both directions program myprog use, intrinsic :: iso_c_binding • Invocation from Fortran: integer( c_int ) :: ic C intrinsic type matching: c_int, c_real … real( c_real ) :: rc4 real( c_double ), allocatable :: dc(:) character( c_char ) :: cc interface subroutine my_c_subr(i, d) bind(c, name=' My_C_Subr ') use, intrinsic :: iso_c_binding integer(c_int), value :: i • Suppress Fortran name mangling real(c_double) :: d(*) • Mixed case name resolution end subroutine my_c_subr end interface ic = … ; allocate(dc(ic)) • ic passed by value call my_c_subr(ic, dc) • address of first element of dc end program passed to subprogram Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Fortran 2003 OOP (1) Type extension Polymorphic entities • new kind of dynamic storage type :: body declared type body real :: mass : ! position, velocity class (body), & end type allocatable :: balloon type, extends (body) :: & typed allocation charged_body allocate(body :: balloon) charged_body real :: charge : ! send balloon on trip end type if (hit_by_lightning()) then : ! save balloon data type(charged_body) :: & deallocate(balloon) proton allocate( & must be an extension charged_body :: balloon) etc_body inherited balloon = … proton%mass = … ! balloon data + charge proton%charge = … end if : ! continue trip if possible change not only size, but also Single inheritance – always a DAG (dynamic) type of object during execution of program 15 Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. Fortran 2003 OOP (2) Associate procedures with type Run time type/class resolution • make components of dynamic type accessible type :: body object-bound procedure (pointer) : ! data components procedure(p), pointer :: print polymorphic entity contains select type (balloon) procedure :: dp type-bound type is (body) end type procedure (TBP) : ! balloon non-polymorphic here class is (rotating_body) subroutine dp(this, kick) : ! declared type lifted class (body), intent(inout) :: this class default real, intent(in) :: kick(3) : ! implementation incomplete? : ! give body a kick end select end subroutine • at most one block is executed • polymorphic dummy argument required for inheritance • same mechanism is used (internally) to resolve type-bound procedure calls • TBP can be overridden by extension (must specify essentially same interface, down to keywords) balloon%print => p_formatted call balloon%print() call balloon%dp(mykick) balloon matches this Copyright© 2012, Intel Corporation. All rights reserved. *Other brands and names are the property of their respective owners. F2008 DO CONCURRENT A new Parallel Loop Construct Syntax uses elements of Fortran 90 FORALL DO [,] CONCURRENT <forall-header> Semantically there is a key difference to FORALL however : A variable referenced can only be defined in the very same iteration or outside of the loop body • This excludes dependencies between different loop iterations The implementation in Intel® Compiler will execute the iterations in parallel using OpenMP* run-time system • requires compiler switch –parallel DO CONCURRENT (I = 1:N) ! Not conforming BLOCK REAL :: T DO CONCURRENT (I=1:N) T = A(I) + B(I) A(I+1) = A(I) + 3.145 C(I) = T + SQRT(T) END BLOCK END DO END
Load more

Recommended publications
  • Object-Oriented Programming in Scheme with First-Class Modules
    Ob jectOriented Programming in Scheme with FirstClass Mo dules and Op eratorBased Inheritance Guruduth Banavar Gary Lindstrom Department of Computer Science University of Utah Salt LakeCityUT Abstract Wecharacterize ob jectoriented programming as structuring and manipulating a uniform space of rstclass values representing modules a distillation of the notion of classes Op erators over mo dules individually achieve eects such as encapsulation sharing and static binding A variety of idioms of OO programming nd convenient expression within this mo del including several forms of single and multiple inheritance abstract classes class variables inheritance hierarchy combination and reection Weshow that this programming style simplies OO programming via enhanced uniformity and supp orts a exible mo del of ob jectorientation that provides an attractive alternative to metaprogramming Finallyweshow that these notions of OO programming are language indep endent by implementing a Mo dular Scheme prototyp e as a completion of a generic OO framework for mo dularity Pap er Category Research Topic Area Language design and implementation Intro duction Classbased ob jectoriented programming is usually thought of as creating a graph structured inher itance hierarchy of classes instantiating some of these classes and computing with these instances Instances are typically rstclass values in the language ie they can b e created stored accessed and passed into and out of functions Classes on the other hand are usually not rstclass values and inheritance is
    [Show full text]
  • Evaluation of the Coarray Fortran Programming Model on the Example of a Lattice Boltzmann Code
    Evaluation of the Coarray Fortran Programming Model on the Example of a Lattice Boltzmann Code Klaus Sembritzki Georg Hager Bettina Krammer Friedrich-Alexander University Friedrich-Alexander University Université de Versailles Erlangen-Nuremberg Erlangen-Nuremberg St-Quentin-en-Yvelines Erlangen Regional Computing Erlangen Regional Computing Exascale Computing Center (RRZE) Center (RRZE) Research (ECR) Martensstrasse 1 Martensstrasse 1 45 Avenue des Etats-Unis 91058 Erlangen, Germany 91058 Erlangen, Germany 78000 Versailles, France [email protected] [email protected] [email protected] Jan Treibig Gerhard Wellein Friedrich-Alexander University Friedrich-Alexander University Erlangen-Nuremberg Erlangen-Nuremberg Erlangen Regional Computing Erlangen Regional Computing Center (RRZE) Center (RRZE) Martensstrasse 1 Martensstrasse 1 91058 Erlangen, Germany 91058 Erlangen, Germany [email protected] [email protected] ABSTRACT easier to learn. The Lattice Boltzmann method is an explicit time-stepping sche- With the Fortran 2008 standard, coarrays became a native Fort- me for the numerical simulation of fluids. In recent years it has ran feature [2]. The “hybrid” nature of modern massively parallel gained popularity since it is straightforward to parallelize and well systems, which comprise shared-memory nodes built from multico- suited for modeling complex boundary conditions and multiphase re processor chips, can be addressed by the compiler and runtime flows. Starting from an MPI/OpenMP-parallel 3D prototype im- system by using shared memory for intra-node access to codimen- plementation of the algorithm in Fortran90, we construct several sions. Inter-node access may either by conducted using an existing coarray-based versions and compare their performance and requi- messaging layer such as MPI or SHMEM, or carried out natively red programming effort to the original code, demonstrating the per- using the primitives provided by the network infrastructure.
    [Show full text]
  • A Comparison of Coarray Fortran, Unified Parallel C and T
    Technical Report RAL-TR-2005-015 8 December 2005 Novel Parallel Languages for Scientific Computing ± a comparison of Co-Array Fortran, Unified Parallel C and Titanium J.V.Ashby Computational Science and Engineering Department CCLRC Rutherford Appleton Laboratory [email protected] Abstract With the increased use of parallel computers programming languages need to evolve to support parallelism. Three languages built on existing popular languages, are considered: Co-array Fortran, Universal Parallel C and Titanium. The features of each language which support paralleism are explained, a simple example is programmed and the current status and availability of the languages is reviewed. Finally we also review work on the performance of algorithms programmed in these languages. In most cases they perform favourably with the same algorithms programmed using message passing due to the much lower latency in their communication model. 1 1. Introduction As the use of parallel computers becomes increasingly prevalent there is an increased need for languages and programming methodologies which support parallelism. Ideally one would like an automatic parallelising compiler which could analyse a program written sequentially, identify opportunities for parallelisation and implement them without user knowledge or intervention. Attempts in the past to produce such compilers have largely failed (though automatic vectorising compilers, which may be regarded as one specific form of parallelism, have been successful, and the techniques are now a standard part of most optimising compilers for pipelined processors). As a result, interest in tools to support parallel programming has largely concentrated on two main areas: directive driven additions to existing languages and data-passing libraries.
    [Show full text]
  • Modular Programming with Functions
    CHAPTER 4 MODULAR PROGRAMMING WITH FUNCTIONS Copyright © 2013 Pearson Education, Inc. Modularity •A program may also contain other functions, and it may refer to functions in another file or in a library. These functions , or modules , are sets of statements that perform an operation or compute a value •To maintain simplicity and readability in long and complex programs, we use a short main, and other functions instead of using one long main function. •By separating a solution into a group of modules, each module is easier to understand, thus adhering to the basic guidelines of structured programming Copyright © 2013 Pearson Education, Inc. Modularity •Braking a problem into a set of modules has many advantages: 1. Every module can be written and tested separately from the rest of the program 2. A module is smaller than a complete program, so testing is easier 3. Once a module has been tested, it can be used in new program without having to retest it ( reusability ) 4. Use of modules ( modularity ) usually reduces the overall length of programs 5. Several programmers can work on the same project if it is separated into modules Copyright © 2013 Pearson Education, Inc. Modularity Main Modules Copyright © 2013 Pearson Education, Inc. Function Definition •A function consists of a definition statement followed by declarations and statements. The general form of a function is: return_type function_name(parameter_declarations) { declarations; statements; return expression; } •The parameter declarations represent the information passed to the function •Additional variables used by the function are defined in declarations statement •All functions should include a return statement Copyright © 2013 Pearson Education, Inc.
    [Show full text]
  • Scope in Fortran 90
    Scope in Fortran 90 The scope of objects (variables, named constants, subprograms) within a program is the portion of the program in which the object is visible (can be use and, if it is a variable, modified). It is important to understand the scope of objects not only so that we know where to define an object we wish to use, but also what portion of a program unit is effected when, for example, a variable is changed, and, what errors might occur when using identifiers declared in other program sections. Objects declared in a program unit (a main program section, module, or external subprogram) are visible throughout that program unit, including any internal subprograms it hosts. Such objects are said to be global. Objects are not visible between program units. This is illustrated in Figure 1. Figure 1: The figure shows three program units. Main program unit Main is a host to the internal function F1. The module program unit Mod is a host to internal function F2. The external subroutine Sub hosts internal function F3. Objects declared inside a program unit are global; they are visible anywhere in the program unit including in any internal subprograms that it hosts. Objects in one program unit are not visible in another program unit, for example variable X and function F3 are not visible to the module program unit Mod. Objects in the module Mod can be imported to the main program section via the USE statement, see later in this section. Data declared in an internal subprogram is only visible to that subprogram; i.e.
    [Show full text]
  • A Parallel Program Execution Model Supporting Modular Software Construction
    A Parallel Program Execution Model Supporting Modular Software Construction Jack B. Dennis Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139 U.S.A. [email protected] Abstract as a guide for computer system design—follows from basic requirements for supporting modular software construction. A watershed is near in the architecture of computer sys- The fundamental theme of this paper is: tems. There is overwhelming demand for systems that sup- port a universal format for computer programs and software The architecture of computer systems should components so users may benefit from their use on a wide reflect the requirements of the structure of pro- variety of computing platforms. At present this demand is grams. The programming interface provided being met by commodity microprocessors together with stan- should address software engineering issues, in dard operating system interfaces. However, current systems particular, the ability to practice the modular do not offer a standard API (application program interface) construction of software. for parallel programming, and the popular interfaces for parallel computing violate essential principles of modular The positions taken in this presentation are contrary to or component-based software construction. Moreover, mi- much conventional wisdom, so I have included a ques- croprocessor architecture is reaching the limit of what can tion/answer dialog at appropriate places to highlight points be done usefully within the framework of superscalar and of debate. We start with a discussion of the nature and VLIW processor models. The next step is to put several purpose of a program execution model. Our Parallelism processors (or the equivalent) on a single chip.
    [Show full text]
  • The Best of Both Worlds?
    The Best of Both Worlds? Reimplementing an Object-Oriented System with Functional Programming on the .NET Platform and Comparing the Two Paradigms Erik Bugge Thesis submitted for the degree of Master in Informatics: Programming and Networks 60 credits Department of Informatics Faculty of mathematics and natural sciences UNIVERSITY OF OSLO Autumn 2019 The Best of Both Worlds? Reimplementing an Object-Oriented System with Functional Programming on the .NET Platform and Comparing the Two Paradigms Erik Bugge © 2019 Erik Bugge The Best of Both Worlds? http://www.duo.uio.no/ Printed: Reprosentralen, University of Oslo Abstract Programming paradigms are categories that classify languages based on their features. Each paradigm category contains rules about how the program is built. Comparing programming paradigms and languages is important, because it lets developers make more informed decisions when it comes to choosing the right technology for a system. Making meaningful comparisons between paradigms and languages is challenging, because the subjects of comparison are often so dissimilar that the process is not always straightforward, or does not always yield particularly valuable results. Therefore, multiple avenues of comparison must be explored in order to get meaningful information about the pros and cons of these technologies. This thesis looks at the difference between the object-oriented and functional programming paradigms on a higher level, before delving in detail into a development process that consisted of reimplementing parts of an object- oriented system into functional code. Using results from major comparative studies, exploring high-level differences between the two paradigms’ tools for modular programming and general program decompositions, and looking at the development process described in detail in this thesis in light of the aforementioned findings, a comparison on multiple levels was done.
    [Show full text]
  • Cafe: Coarray Fortran Extensions for Heterogeneous Computing
    2016 IEEE International Parallel and Distributed Processing Symposium Workshops CAFe: Coarray Fortran Extensions for Heterogeneous Computing Craig Rasmussen∗, Matthew Sottile‡, Soren Rasmussen∗ Dan Nagle† and William Dumas∗ ∗ University of Oregon, Eugene, Oregon †NCAR, Boulder, Colorado ‡Galois, Portland, Oregon Abstract—Emerging hybrid accelerator architectures are often simple tuning if the architecture is fundamentally different than proposed for inclusion as components in an exascale machine, previous ones. not only for performance reasons but also to reduce total power A number of options are available to an HPC programmer consumption. Unfortunately, programmers of these architectures face a daunting and steep learning curve that frequently requires beyond just using a serial language with MPI or OpenMP. learning a new language (e.g., OpenCL) or adopting a new New parallel languages have been under development for programming model. Furthermore, the distributed (and fre- over a decade, for example, Chapel and the PGAS languages quently multi-level) nature of the memory organization of clusters including Coarray Fortran (CAF). Options for heterogeneous of these machines provides an additional level of complexity. computing include usage of OpenACC, CUDA, CUDA For- This paper presents preliminary work examining how Fortran coarray syntax can be extended to provide simpler access to tran, and OpenCL for programming attached accelerator de- accelerator architectures. This programming model integrates the vices. Each of these choices provides the programmer with Partitioned Global Address Space (PGAS) features of Fortran abstractions over parallel systems that expose different levels with some of the more task-oriented constructs in OpenMP of detail about the specific systems to compile to, and as 4.0 and OpenACC.
    [Show full text]
  • Coarray Fortran Runtime Implementation in Openuh
    COARRAY FORTRAN RUNTIME IMPLEMENTATION IN OPENUH A Thesis Presented to the Faculty of the Department of Computer Science University of Houston In Partial Fulfillment of the Requirements for the Degree Master of Science By Debjyoti Majumder December 2011 COARRAY FORTRAN RUNTIME IMPLEMENTATION IN OPENUH Debjyoti Majumder APPROVED: Dr. Barbara Chapman, Chairman Dept. of Computer Science Dr. Jaspal Subhlok Dept. of Computer Science Dr. Terrence Liao TOTAL E&P Research & Technology USA, LLC Dean, College of Natural Sciences and Mathematics ii Acknowledgements I would like to express my gratitude to Dr. Barbara Chapman for providing financial support and for creating an excellent environment for research. I would like to thank my mentor Deepak Eachempati. Without his guidance, this work would not have been possible. I sincerely thank TOTAL S.A. for funding this project and Dr. Terrence Liao for his valuable inputs and help in performing experiments on TOTAL's hardware. I also thank the interns at TOTAL, Asma Farjallah, and France Boillod-Cerneux for the applications that I used for performance evaluation. I thank Hyoungjoon Jun for his earlier work on the CAF runtime. I thank Tony Curtis for his suggestions and excellent work on maintaining the infrastructure on which I ran my experiments. I thank Dr.Edgar Gabriel for answering all my questions and his help with using the shark cluster. I also thank the Berkeley Lab and PNNL's ARMCI developers for their guidance in using GASNet and ARMCI. Lastly, I would like to thank the Department of Computer Science for giving me the opportunity to be in this great country of USA and all my lab-mates and friends.
    [Show full text]
  • Software Quality / Modularity
    Software quality EXTERNAL AND INTERNAL FACTORS External quality factors are properties such as speed or ease of use, whose presence or absence in a software product may be detected by its users. Other qualities applicable to a software product, such as being modular, or readable, are internal factors, perceptible only to computer professionals who have access to the actual software text. In the end, only external factors matter, but the key to achieving these external factors is in the internal ones: for the users to enjoy the visible qualities, the designers and implementers must have applied internal techniques that will ensure the hidden qualities. EXTERNAL FACTORS Correctness: The ability of software products to perform their tasks, as defined by their specification. Correctness is the prime quality. If a system does not do what it is supposed to do, everything else about it — whether it is fast, has a nice user interface¼ — matters little. But this is easier said than done. Even the first step to correctness is already difficult: we must be able to specify the system requirements in a precise form, by itself quite a challenging task. Robustness: The ability of software systems to react appropriately to abnormal conditions. Robustness complements correctness. Correctness addresses the behavior of a system in cases covered by its specification; robustness characterizes what happens outside of that specification. There will always be cases that the specification does not explicitly address. The role of the robustness requirement is to make sure that if such cases do arise, the system does not cause catastrophic events; it should produce appropriate error messages, terminate its execution cleanly, or enter a so-called “graceful degradation” mode.
    [Show full text]
  • Chapter-2 Object Oriented Programming Very Short/ Short Answer Questions 1
    CHAPTER-2 OBJECT ORIENTED PROGRAMMING VERY SHORT/ SHORT ANSWER QUESTIONS 1. Discuss major OOP concepts briefly. Ans. Following are the general OOP concepts: 1. Data Abstraction: Data abstraction means, providing only essential information to the outside word and hiding their background details i.e. to represent the needed information in program without presenting the details. 2. Data Encapsulation: The wrapping up of data and operations/functions (that operate o the data) into a single unit (called class) is known as Encapsulation. 3. Modularity: Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. 4. Inheritance: Inheritance is the capability of one class of things to inherit capabilities or properties from another class. 5. Polymorphism: Polymorphism is the ability for a message or data to be processed in more than one form. 2. What are programming paradigms? Give names of some popular programming paradigms. Ans. Programming Paradigm: A Programming Paradigm defines the methodology of designing and implementing programs using the key features and building blocks of a programming language. Following are the different programming paradigms: (i) Procedural Programming (ii) Object Based Programming (iii) Object Oriented Programming 3. What are the shortcomings of procedural and modular programming approaches? Ans. Following are the various shortcomings of procedural and modular programming approaches: Procedural Programming is susceptible to design changes. Procedural Programming leads to increased time and cost overheads during design changes. Procedural and Modular programming both are unable to represent real world relationship that exists among objects. In modular programming, the arrangement of the data can’t be changed without modifying all the functions that access it.
    [Show full text]
  • Modular Programming
    Modular Programming Prof. Clarkson Fall 2016 Today’s music: "Giorgio By Moroder" by Daft Punk Te Moog modular synthesizer Review Previously in 3110: • Functions, data • lots of language features • how to build small programs Today: • language features for building large programs: structures, signatures, modules Question What’s the largest program you’ve ever worked on, by yourself or as part of a team? A. 10-100 LoC B. 100-1,000 LoC C. 1,000-10,000 LoC D. 10,000-100,000 LoC E. 100,000 LoC or bigger Scale • My solution to A1: 100 LoC • My solution to A2: 300 LoC • OCaml: 200,000 LoC • Unreal engine 3: 2,000,000 LoC • Windows Vista: 50,000,000 LoC http://www.informationisbeautiful.net/visualizations/million-lines-of-code/ ...can’t be done by one person ...no individual programmer can understand all the details ...too complex to build with subset of OCaml we’ve seen so far Modularity Modular programming: code comprises independent modules – developed separately – understand behavior of module in isolation – reason locally, not globally Java features for modularity • classes, packages: organize identifiers (classes, methods, fields, etc.) into namespaces • interfaces: describe related classes • public, protected, private: control what is visible outside a namespace • subtyping, inheritance: enables code reuse OCaml features for modularity • structures: organize identifiers (functions, values, etc.) into namespaces • signatures: describe related modules • abstract types: control what is visible outside a namespace • functors, includes: enable
    [Show full text]