Clarification for list of FP languages

[klieret]

Btw, common lisp also has excellent support for OOP via the common lisp object system (CLOS). It's quite powerful, e.g. has multiple dispatch (if you want to see that in a modern language, try Julia). Also, Common Lisp variables are mutable by default. So I'd argue for putting it into the "emphasis on FP" category. Clojure is definetly more strict. Lisp-dialects in the scheme family are inbetween.

@meliache

[meliache]

That's a misconception and as someone who had done some Common Lisp programming in the past for fun I wanted to point that out.

So you say here:

Languages made for FP

As I explained, Common Lisp is multi-paradigm and has built-in support classes (see CLOS), loops, mutables states etc. The classes were only later added to the standard, but it had been multi-paradigm from the beginning. However, when the first Lisp's appeared, they were among the first languages with higher order functions, recursion support etc. And Lisp programs tended to be much more divided into many small functions than e.g. early Fortran programs were [citation needed]. So this is why early on Lisp-languages were often to referred as functional, in the sense that functions are first-class objects and are used a lot in structuring the code, but not in the modern sense of "no side effects and no state".

In conclusion, Lisp languages were made for FP in the sense that they were made with function-heavy programming in mind and allowed for functional programming, after all Lisp is inspired from Lambda calculus. But Common Lisp was not made for functional-only programming in the modern sense. Clojure was (though it allows for some state I think, it's not as strict as haskell).

[meliache]

I just checked the wikipedia article on FP and it states:

Lisp first introduced many paradigmatic features of functional programming, though early Lisps were multi-paradigm languages, and incorporated support for numerous programming styles as new paradigms evolved. Later dialects, such as Scheme and Clojure, and offshoots such as Dylan and Julia, sought to simplify and rationalise Lisp around a cleanly functional core, while Common Lisp was designed to preserve and update the paradigmatic features of the numerous older dialects it replaced.[34]

[34] Guy L. Steele; Richard P. Gabriel (February 1996). The Evolution of Lisp (PDF). In ACM/SIGPLAN Second History of Programming Languages. pp. 233–330. doi:10.1145/234286.1057818. ISBN 978-0-201-89502-5. S2CID 47047140.

Btw, Wikipedia has a list of functional languages divided by pure/impure: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages

Here, Common Lisp is among the impure functional languages, but so is C++. The list is not exclusive and multi-paradigm programming languages appear in multiple categories. By the way, Clojure is among the impure functional languages because though it strongly discourages them, it allows for mutable objects (though the defaults are all immutable). But I'd still call clojure "made for FP"

[ldeniau]

Btw, common lisp also has excellent support for OOP via the common lisp object system (CLOS). It's quite powerful, e.g. has multiple-dispatch (if you want to see that in a modern language, try Julia). Also, Common Lisp variables are mutable by default.

Since you are interested in the programming language paradigms, you might be interested in the C Object System (COS), a similar CLOS for C that I implemented 16 years ago using the C99 preprocessor to parse the DSL of COS and generate C89 code by the C compiler itself during the translation phase 4. https://github.com/CObjectSystem/COS In the doc subdirectory, you will find papers and slides, including one on design patterns and concepts ;-) You can also compare multiple-dispatch in C++ vs COS in Wikipedia https://en.wikipedia.org/wiki/Multiple_dispatch#C

Concerning your slides, well done! One point about FP is that they aren't necessarily immutable (your slides seemed to be Haskell oriented, that like too). They need high order functions (+ syntactic sugar for composition), a multiple-instances single-type data type (e.g. list, C++ vector), and a single-instance multiple-types data type (e.g. tuples for the cartesian product of types) to build all algebraic data types.

Cheers, Laurent.

[klieret]

Thanks a lot for your comments @meliache @ldeniau, very helpful. In the long run this training might be ported to fit in here, so suggestions are very welcome.