---
# System prepended metadata

title: SPO - Lecture 2

---

# SPO - Lecture 2



## exercise 6 - Make an educated guess as to the most common syntax error in Lisp programs.
- Missing parenthesis or adding too many parentheses.
## exercise 7 - Lisp began as a pure functional language but gradually acquired more and more imperative features. Why?

- Lisp began as a pure functional language, but over time, the language evolved to include more imperative features to meet the changing needs of its users. The addition of imperative features allowed developers to write more efficient and expressive code, which improved the overall utility of the language. Additionally, the imperative features made Lisp more accessible to programmers who were already familiar with imperative programming paradigms, making it easier for them to adopt the language. Furthermore, the popularity of the language also played a role, as users requested new features that would make it easier for them to solve problems with Lisp. In conclusion, the inclusion of imperative features in Lisp was a natural evolution of the language in response to the changing needs of its users and the broader programming community. The result was a more versatile and powerful tool that could be used to solve a wider range of problems.

## exercise 14 - What are the arguments both for and against the idea of a typeless language?
- The argument for a typeless language is that it allows for greater flexibility and ease of use for the programmer. In a typeless language, variables can take on any value, allowing for more dynamic and adaptive programming. This can reduce the amount of time and effort required to write code, as the programmer does not need to worry about specifying the type of a variable, which can be a time-consuming and error-prone process. On the other hand, the argument against a typeless language is that it can lead to reduced reliability and maintainability of the code. In a typeless language, there is no guarantee that a variable will always have the type of value that is expected, which can lead to unexpected behavior and bugs. This can make it more difficult to debug and fix code, and can also make it more challenging to maintain code over time as the requirements of the system change. Additionally, a typeless language can make it more difficult to catch type errors early in the development process, which can result in problems that are more difficult to diagnose and fix later on. This can also lead to reduced performance, as the compiler or interpreter must dynamically check the type of values at runtime, which can slow down execution. In conclusion, the choice between a typeless and a typed language is a trade-off between flexibility and reliability. Typeless languages are often more flexible and easier to use, but can result in reduced reliability and maintainability. On the other hand, typed languages can provide greater reliability and maintainability, but can be more rigid and harder to use. The choice between the two depends on the specific needs and requirements of the project at hand.
## exercise 16 - What is your opinion of the argument that languages that are too complex are too dangerous to use, and we should therefore keep all languages small and simple?

- Some languages need complexity to obtain the speeds needed for their job to run on simple hardware while retaining the access to potentially unsafe features.
- Programmes in complex languages can be difficult for newcomers to the language to make secure programmes. 
## exercise 17 - Do you think language design by committee is a good idea? Support your opinion.
- Slow process, when it has to be approved by the commitee 
## exercise 18 - Languages continually evolve. What sort of restrictions do you think are appropriate for changes in programming languages? Compare your answers with the evolution of Fortran.
- Things that make legacy code unable to run. (Backwards compatibility)
- Syntax and sematnics changes that makes it possible to write ambiguous code.
## exercise 21 - In recent years data structures have evolved within scripting languages to replace traditional arrays. Explain the chronological sequence of these developments.
- It started with direct memory management. Now we have static sized arrays, linked lists and other array types.
## exercise 22 - Explain two reasons why pure interpretation is an acceptable implementation method for several recent scripting languages.
- 1. Pure interpretation does not require a translation
- 2. It is easier to find and correct errors, because errors are immediately displayed.
- 3. Recently machines have much better hardware, and therefore execution speed/efficiency is not as big of a priority.
## exercise 23 - Why, in your opinion, do new scripting languages appear more frequently than new compiled languages?
- People are learning-retards this is true fax but false fox.
- Unpopular view: because people like to make quick changes and see their changes faster instead of waiting the compile time.
