1 Chapter 7: High-level Language Programming Algorithmic Foundations Hardware Virtual Machine Software Applications Social Issues Outline Where we are HLL Programming Software life cycle

2 Where We Are In the early 1950s: Writers of programs were very technical folks. They had background in engineering, understood the internal functioning of computers. They “ wanted ” to use assembly language in order to understand what the machine does under the hood. They wanted to optimize their programs and the use of resources: Example: LOADX -- X  R ADDONE -- R+1  R STOREX -- R  X … ONE:.DATA1  Equivalent to: INCREMENTX -- X+1  X

3 Where We Are This “ fine-tuning ” of programs was easy at the assembly language level. It saves few milliseconds to few seconds of processing time Saving processing time was important since the machines were extremely slow In later decades computers disseminated in society so that even the “ nontechie ” types needed to be able to write programs  High-level languages were born This was a mutual process: New programmers demanded better languages, which in their turn opened the way for new programmers Also technological improvement made it possible to overcome the overhead of high-level language programming

4 Where We Are Consider adding two numbers (B and C, result is A): LOADB-- B  R ADDC-- C+R  R STOREA-- R  A … A:.DATA0 B:.DATA0 C:.DATA0 In order to perform such a simple operation (addition) we had to deal with data movement – from and to register R – for each number and for the result!  More expressive instructions, like A = B + C, are highly desired Recall each assembly language instruction corresponds to one machine language statement  assembly language is as expressive as machine language Moreover, assembly language programs are machine-dependent

5 Where We Are Assembly language program that runs on machine X does not (necessarily) run on machine Y, due to the difference in data formats and instruction codes Another problem is that even if the symbolic notation of assembly language is a good step forwards (compared with binary notation), there is still a gap between the language and the notation we usually use and that of the mnemonic notation All in all, there are four major drawbacks of assembly language: Data movement is done under program control Programmers should have a microscopic view of their tasks Assembly language programs are machine specific No English-like statements are possible

6 Where We Are High-level language (HLL) were created to overcome these deficiencies: Programmers need not to manage data movement Programmers have a macroscopic view of tasks Programs in HLL are potable (not machine specific) Statements in a HLL are closer to standard English and usual notations HLLs are often called third generation languages (machine language  assembly language  HLL)

7 HLL Programming in LOGO 1 st Generation – Machine Language  had to type in all 0’s and 1’s  very hard and error prone 2 nd Generation – Assembly Language  Rather than 0’s and 1’s, uses op codes like Load, Add, Store, etc 3 rd Generation – High level languages like BASIC, LOGO, COBOL, Pascal, C++

8 HLL Programming in LOGO HLL Programming languages (just like algorithms) have three main types of commands/operations/statements: Sequential do something once Conditional do something if a condition is true Iterative keep doing something until some condition becomes false We will learn how to write programs using these types of statements in LOGO.

9 HLL Programming in LOGO Some features of LOGO interactivity  user/programmer gets immediate feedback modularity  huge programs can be well structured to cope with complexity extensibility  programs are easy to extend flexibility of data types  not strongly typed, which gives more flexibility for beginners, also programs can be changed easily.

10 HLL Programming in LOGO Why LOGO? is easy to learn. The syntax (i.e. the rules of writing) is fairly intuitive and the format is not too restrictive and fussy. gives immediate visual feedback. You can see what you programmed immediately. a “real” programming language. Although we will be using a small subset of commands that deal almost exclusively with drawing, do not get the impression that this is all LOGO can do.

11 HLL Programming in LOGO A subset of logo commands you will learn allow one to draw on the screen. The commands control a turtle carrying a pen. Positions on the screen are given by Cartesian coordinates.  e.g. Center (origin) is (0,0) The direction the turtle is facing is given by the number of degrees clockwise from facing the top of the page.  I.e.: a right turn is a turn to the turtle’s right not the right side of the screen. All commands are followed from the turtle’s point of view.

12 HLL Programming in LOGO Sequential Commands: Forward dist - fd dist - move the turtle dist pixels forward  Example: fd 20 moves turtle 20 pixels forward Backward dist - bk dist - move the turtle dist pixels backward  Example: bk 20 moves turtle 20 pixels backward Right degrees - rt deg - turn the turtle deg degrees to its right (clockwise)  Example: rt 45 turns turtle 45 degrees to its right Left degrees - lt deg - turn the turtle deg degrees to its left (counter- clockwise)  Example: lt 90 turns turtle 90 degrees to its left

13 HLL Programming in LOGO Sequential Commands: Setxy x y - move the turtle to position (x,y) direction faced will not change  Example: Setxy turtle is moved to position (10, 10) Setx x - move the turtle to the right or left so that it’s new position is (x,?) direction faced will not change  Example: Setx 5 turtle is moved to position (5, y) Sety y - move the turtle to the up or down so that it’s new position is (?,y) direction faced will not change  Example: Sety 20 turtle is moved to position (x, 20) Setheading degrees - change the direction faced to degrees clockwise from facing the top of the screen, position will not change  Example: Setheading 180 turns turtle back

14 HLL Programming in LOGO Sequential Commands: Home – move turtle back to (0,0) direction 0 Clean – erase all drawing from the screen Showturtle – show the arrow mean to represent the turtle Hideturtle – hide the arrow mean to represent the turtle Penup – the turtle lifts the pen so that no drawing will appear when the turtle moves Pendown – the turtle puts the pen down so that drawing will appear when the turtle moves Wrap – change the way the turtle moves when it gets to the edge of the window it jumps to the opposite side of the window. Window - change the way the turtle moves when it gets to the edge of the window it keeps going into non visible space of the edge of the screen Fence - change the way the turtle moves when it gets to the edge of the window it stops and an error message is generated

15 HLL Programming in LOGO Example 1 : Draw a U graphics: fd 30 rt 90 fd 30 rt 90 fd 30 X turtle

16 HLL Programming in LOGO Example 2: A LOGO program that draws a square: Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Ht X

17 HLL Programming in LOGO Saving the program: Put commands in a file called name.lgo Before the first command put to name (for example: to mySquare) After the last command put end Load the program in the logo program then enter the name to run it. You have created a procedure called name.

18 HLL Programming in LOGO The final program: To mySquare Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Ht end

19 HLL Programming in LOGO Conditional Statements: If condition [instruction list]  if then (no else) Ifelse condition [instruction list] [instruction list]  if then else Pendown? – true if the pen is down, false if it is up Shown? – true if the turtle is showing, false if it is hidden x = y or query = x – true if they’re equal x < y or query < x – true if the inequality is correct x > y or query > x – true if the inequality is correct Not (condition) – true if the condition is false And c1 c2 c3 … true only when all conditions are true Or c1 c2 c3 … false only when all conditions are false

20 HLL Programming in LOGO Queries: Queries are commands that give you information: Pendown? and Shown? Are both queries. Xcor - Outputs a number, the turtle's X coordinate. Ycor - Outputs a number, the turtle's Y coordinate. Heading - Outputs an angle, the turtle's heading in degrees. Angle going clockwise from top of the page. Towards - Outputs an angle, the heading in degrees, at which the turtle should be headed so that it would point from its current position towards the position given as the argument. Distance - Outputs a number, the distance the turtle must travel along a straight line to reach the position given as the argument.

21 HLL Programming in LOGO Example: Draw a shape To drawShape ifelse heading = 0 [mySquare] [fd 200 rt 90 fd 100 rt 90 fd 200 rt 90 fd 100 ht] end Draws a square if the heading is 0 otherwise it draws a rectangle In the real program the entire ifelse command must appear on one line

22 HLL Programming in LOGO Iterative commands: Loops do a set of steps repeatedly. Repeat (number) [(instruction list)] This is a counting loop, it does all the steps in the instruction list “number” times, you can use the repcount query to determine which number time through the loop you are at, the counting starts at zero and goes up to and includes the given value for number. While (condition) [(instruction list)] Does all the instructions in the list repeatedly until the condition becomes false. This is a “true” loop and may therefore lead to an endless loop, if condition never becomes false. (There are many other types of loops in LOGO)

23 HLL Programming in LOGO Main data types: Numbers: A combination of digits and potentially some further symbols for the representation of negative and floating point numbers Examples: E10 Words: A combination of letters and digits that begins with a quote. Examples: “adam“OTTO“item14

24 HLL Programming in LOGO Main data types (continued): Lists: An ordered sequence of objects enclosed in brackets. In particular, a list may include other lists as elements. Examples: [adamOTTOitem14] [[adam 1] [OTTO 30]] [] (empty list)

25 HLL Programming in LOGO Simple functions: Arithmetic operations: Examples: SUM 2 4  6 2*4  8 List operations: FIRST: Get the first element of a list. BUTFIRST: Get the list without the first element. Examples: FIRST [adamOTTOitem14]  adam FIRST [[adam 1] [OTTO 30]]  [adam 1] BUTFIRST [adam OTTO item14]  [OTTO item14]

26 HLL Programming in LOGO Variables: A variable is a named placeholder for some value.  Definition of a variable called number: MAKE “number 20  Get the value stored in the variable using THING: THING “number  20 Example: The following commands print the value 25 on the screen: MAKE “number 20 MAKE “result SUM THING “number 5 PRINT THING “result

27 HLL Programming in LOGO Definition of functions/procedures: Function: A named part of a program that returns a result. Procedure: A named part of a program that does not return a result. Example for a function in LOGO: to second :list output FIRST BUTFIRST :list end  :list is a parameter for the function named second  output is a command for returning a result  This function returns the second element of a list

28 HLL Programming in LOGO Example for the use of function second: second [adamOTTOitem14]  OTTO second [adam[OTTOitem14]]  [OTTO item14] :list is a parameter and may vary Do not forget the “:” Meaning of “:” is “value of” Another Example: to length :list If EQUALP :list [] [output 0] [output 1 + length BUTFIRST :list] end

29 HLL Programming in LOGO Our new function has the name length. It uses the EQUALP to test the equality. The function computes and returns the length of a given list. It checks first whether or not the list is empty, if so 0 is returned. If the list is not empty, it proceeds with calculating the length of the list without the first element and adds 1 to the returned value. Examples for the use of length: length [adam OTTOitem14]  3 length []  0 length [adam [OTTO item14]]  2

30 HLL Programming in LOGO Functions and procedures can be nested:  A function/procedure can call another function/procedure  A function/procedure can call itself (see function length) Example: The following procedure draws a V to V lt 45 fd 20 bk 20 rt 90 fd 20 bk 20 lt 45 end

31 HLL Programming in LOGO The following procedure draws a branch and uses the procedure V: to branch fd 30 V fd 30 V fd 15 bk 75 end

32 HLL Programming in LOGO The following procedure draws a scrub and uses the procedure branch: to scrub left 80 repeat 7 [right 20 branch] left 60 end

33 Program Translation HLL price is that we need a translator Unlike the Assembler, which translates from assembly to machine language, we now need a compiler that translates from HLL, for example, LOGO to machine language In fact the compiler can also translate from HLL to assembly language, and the Assembler can be used for further translation to machine language Compiler More complicated than an Assembler No 1-to-1 relationship between HLL instruction and machine level ones as in assembly language! In order to use LOGO on a computer, the computer should have a LOGO compiler In fact, one needs a compiler for each pair of (HLL, machine) For example: LOGO compilers/interpreters for IBM PCs, for VAX machines, for Macs, etc.

34 Sample Translation Steps Program e.g. branch Compiler interpreter Intermediate Assembly Language Code Assembler Object Code (in a file) Loader Object code in memory Hardware Results

35 Modularity (Or Top-Down Design) Suppose you (perhaps with others) are asked to write a program that was estimated to have 100,000 lines !!! Spontaneous questions: How to begin? Where to begin? How can I understand what I programmed 6 months ago? How can I understand code that others (working with me) wrote? Main principle: divide and conquer Divide your complex problem into distinct parts, called modules, which are manageable and compact Top down: begin with most abstract module first Bottom up: begin with most concrete module first

36 How LOGO Supports Modules Two types of modules in LOGO: procedures and functions For example, the scrub program has been divided into 3 modules: V branch scrub In general top down design is preferred:  this means begin with scrub in our example and not with V (what we did is bottom up design)  If module 1 uses modules 1.2 … 1.N then begin with module 1

37 Software Life Cycle Main phases: Feasibility Study Problem Specification Program Design Development and analysis Coding Debugging Testing/Verification and Benchmarking Documentation Maintenance

38 Software Life Cycle Feasibility study Is a software solution worth for user? Perhaps it is better not automate … Cost estimates for e.g. Machines including I/O (e.g. printers) Software packages Salaries for developers Training costs for users  Costs often higher than expected! Result: Feasibility document that recommends whether or not to start project

39 Software Life Cycle Problem specification (The What): Clear, concise, and unambiguous statement of the exact problem to be solved is needed Original specification (used in feasibility study) is usually in natural language (e.g. English) and often comprises unclear, incomplete, or even contradictory statements Thus, software designers (computer scientist) and user (?) need to hammer out any gap or inconsistency in the problem statement Why?  Changes are easier in this phase than in later ones (e.g. after program is developed)  It is like changing your mind when looking at the blueprints of your new home rather than after the foundation has been dug and the walls have started to go up!

40 Software Life Cycle Result of problem specification is a document specifying exactly how the program will behave in all circumstances (also under unusual conditions). Examples are expected data input, computed results, ways of how results are displayed … Program design (The How) Divide and conquer: e.g 100, 000 lines = 1000 x 100 lines Thus, problem is subdivided in modules of small size Each module needs to be specified: What does the module do? What information is needed from other modules? (input) What information is provided to other modules? (output) Module specification should be sufficiently detailed that a programmer could immediately write program using it. This phase is the most creative phase; compare designing an airplane to riveting its wing!

41 Software Life Cycle Algorithm selection (or development) and analysis For each specified module an algorithm should be identified to carry out it functionality Example: A module may be assigned the task of searching some particular number in a list of numbers  What algorithms are convenient (e.g. sequential or binary search) Also, it may be the case that a new algorithm has to be developed, also a very creative task. The documentation of this phase includes the description of used algorithms (in e.g. pseudo-code) and rationales for their use. Coding (sometimes also called development) (  e.g. in Pascal, C, … ) Each module is to be written in a programming language (which one?  is part of early decisions in the feasibility study) Coding is a relatively routine job, reusable code can be also used This step usually comes to mind when people think of software, but in fact this step is preceded by more important ones that facilitate it Result of the coding is a document, namely, the code itself with comments and description of implementation decisions

42 Software Life Cycle Debugging This is the process of finding and removing program errors Can be very time-consuming (even more than coding time) Types of errors: Syntax errors Violation of the rules of form (syntax) in the respective programming language Detected by the compiler Examples:  missing names  semicolon is missing  curly brace is missing  no semicolon is needed

43 Software Life Cycle Run-time errors Occur when program is running using certain data that result in an illegal operation E.g. dividing by zero System software can help detect this kind of errors Logic errors The program compiles well and runs well but does not produce the expected results. Problem may be in coding the module, in the algorithm of the module, or even a step earlier in the development process No tools that help pinpoint this problem Poorly done design results in a structural mess with convoluted and hard- to-understand logic Documentation of debugging process includes notes on found problems and how code was changed to solve them, this prevents later changes from re-introducing older errors.

44 Software Life Cycle Testing, verification, and benchmarking Even though the program produces correct answers for 1, 5, or even 1000 data sets, how can we be sure that it is indeed 100% correct? Three methods can help Empirical Testing: Design a special set of test cases and run the program using them Test data that is carefully chosen to exercise all different logic paths of a program can help uncover errors For example: if(a = b) then a = a+1 else b = b+1;  Data set {(1, 1), (1, 0)} let the condition be true and false thus executing the two possible paths Problem: data sets that cover ALL paths are in most cases unfeasible

45 Software Life Cycle Program verification Rigorous mathematical proof that the program will produce the correct results when certain conditions are satisfied  Good for small modules (perhaps critical ones)  Bad in general since programs tend to be very complex and large Hence, testing is used more often than verification in practice Benchmarking Addresses primarily efficiency and not reliability Run program on many different data sets to be sure that performance requirements are met (e.g. amount of computation time) At the end of this phase  Program should produce: a) correct results (e.g. thoroughly tested) b) within the prescribed performance limits (e.g. well-benchmarked)

46 Software Life Cycle Documentation Written material that makes program understandable and useable Internal documentation: Part of the code; meaningful names, comments, modules External documentation: Accompanying each step of the software life cycle Final documentation Technical documentation For programmers that may modify the program User documentation For users that use the program (how to run it, on-line tutorial … )

47 Software Life Cycle Maintenance Software is used for a very long time Maybe longer than ever expected  Year 2k Problem A medium-to-large software cycle may include 2 to 3 years of development (from feasibility to testing) and 5 to 15 years in the marketplace During this long period of use some new needs can arise: New errors may be uncovered User preferences may change New hardware may be used The whims of the marketplace fluctuate  Original program has to be modified Maintenance is the process of adapting an existing software product due to any of above reasons. Maintenance is not a genuine separate step in the software life cycle, since it mainly involves repetitions of other phases.