Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
pp:intro [2019/02/14 18:06]
pdmatei
pp:intro [2019/02/14 18:19] (current)
pdmatei
Line 203: Line 203:
 ==== Why so many reversals? ==== ==== Why so many reversals? ====
  
-The reason for choosing ​reversal ​as a running example is that the task is algorithmically trivial: take the sequence of elements of the collection at hand, be it array of list (or anything else), in their **reverse** order.+Note that **reversal** is an algorithmically trivial ​task: take the sequence of elements of the collection at hand, be it array of list (or anything else), in their **reverse** order.
  
-Howeverthere are **many different ways** for implementing reversal, and each makes perfect sense in some settingMoreoversome of these ways are**subtle**, **conceptually challenging**and require ​**higher skill/​knowledge** in operating the programming language at hand+Our point is thatapart from mastering algorithms, a skilled programmer needs **solid knowledge** on programming concepts and on the way programming languages (and the hardware they employ) are designed. In some casesthese concepts may be subtle (e.g. programming with Monads in Haskell) ​and may supersede the algorithm at hand in complexityHoweverthey are crucial in developing a **efficient**, **secure** and **correct** applications.
  
-Our point, and one of the major objectives of this lecture, is to emphasise that, apart from developing fast and correct algorithms, a task of equal challenge and importance is **writing ​down the code**, in the **suitable ​programming ​language**.+This lecture ​will focus on different ways of **writing code** ​for specific algorithms, in different ​programming ​languages, with an emphasis on Functional Languages (Haskell) and Logic-based Languages (Prolog).
  
 We have clear metrics for choosing algorithms. Do we also have metrics for **code writing**? For instance: We have clear metrics for choosing algorithms. Do we also have metrics for **code writing**? For instance:
Line 220: Line 220:
 ==== How many other ways? ==== ==== How many other ways? ====
  
-There are many possible variations to our three examples, but a few elements do stand out: +There are many possible variations ​(and combinations) ​to our examples, but a few elements do stand out: 
-  * the functional style for **representing a list** ​in the second example ​- very akin to Abstract Datatypes +  * the functional style for **representing a list** - very akin to Abstract Datatypes 
-  * the functional style for reversal - relying on recursion, ​in the same example+  * the functional style for reversal - relying on recursion, ​relying on folding
   * the Object Oriented style for **traversing a list** in the third example - which although is tightly linked to Java Collections,​ can be migrated to any other object-oriented language.   * the Object Oriented style for **traversing a list** in the third example - which although is tightly linked to Java Collections,​ can be migrated to any other object-oriented language.
  
-These **elements of style** are frequently ​called **design patterns** ​generic ways of writing code, which can be deployed for different implementations. ​+Such **elements of style** are may be called **design patterns**, i.e. generic ways of writing code, which can be deployed for different implementations. ​
  
-Some elements of style may have some common ground, or rely on certain traits ​of the programming language. These latter are called programming **paradigms**. For instance, writing programs as recursive functions ​as well as representing data as ADTs (recall that constructors //are// functions) are both styles of the **functional** paradigm.+Some elements of style may have some common ground, or require ​certain traits ​from the programming language. These latter are called programming **paradigms**. For instance, writing programs as recursive functions, using higher-order functions and representing data as ADTs (recall that constructors //are// functions) are both styles of the **functional** paradigm.
  
 In this lecture, we shall go over the following paradigms: In this lecture, we shall go over the following paradigms: