Differences
This shows you the differences between two versions of the page.
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. |
- | However, there are **many different ways** for implementing reversal, and each makes perfect sense in some setting. Moreover, some of these ways are: **subtle**, **conceptually challenging**, and require **higher skill/knowledge** in operating the programming language at hand. | + | Our point is that, apart 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 cases, these concepts may be subtle (e.g. programming with Monads in Haskell) and may supersede the algorithm at hand in complexity. However, they 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: |