complete, i.e. you can do everything that can be done with a computer in any of them. The book (and this presentation) are by no means an exhaustive exploration of the programming languages. Think of them as food for thought.
to explain what composes a language and how the same problem is handled by different languages – I expect to show you that a characterization such as “it is function” or “it is object oriented” is insufficient and most of the times inappropriate – I expect you to be convinced that mutable state can be avoided and that this is key to enabling efficient and sane concurrent programming
Extremely simple and consistent syntax – Heavy emphasis on message passing, not method call. (actually, “method” is a message that returns an object that can receive the message “call”) – Easy to create DSLs – Excellent concurrency primitives – Crazy amount of reflective power
Has a powerful type system – Offers advanced FP concepts such as monads and type classes. – You can emulate non-strict evaluation with “call by name” vs “call by value“ paramater passing strategies – Suffers from the Java legacy to a certain extent
language still actively used. – FP, supports OOP, strongly typed, dynamically typed. – Lisp on the JVM with modern constructs and libraries. – Allows meta-programming with macros. – Not so Lispy: no custom reader macros and no automatic tail call optimization. (schemers be mad)
can simulate non-strictness using macros. – It's possible to define the language on-the-fly, i.e., the language is internally reprogramable (heavy influence in ruby and smalltalk) – <code @ clojure-koans/src/koans/17_macros.clj:29>
and no mutable state (at least the way we are used to) – Extremely powerful type system with parametric types, type class, algebraic data types and type inference. – Offers the full pack of FP crazyness: Monads, Monoids, Functors, Applicatives, Foldables are common language for Haskell programmers. – Much more close to Math, simplifying the way we represent abstract and symbolic constructs.
no classes. – OOP is about “messages and objects”, not “classes and methods”. – You can dispatch using more than one type. – Class based and prototype based object systems are actually equivalent, and you can represent one in the other.
sucks. – Different paradigms will influence heavily the way you compose the behaviors in your program – Class based OOP lends itself nicely to program organization (one class, one file, internal classes in directories) – There is no such parallel in FP
takes its toll – With a little bit of effort, you can simulate mutable state where its absolutely necessary. – Functional purity brings referential transparency, lazy evaluation, easy concurrency and makes it easier to reason and compose programs. … but – The density of the languages tend to be higher, and the intellectual load is surely higher too. Not that you can't get used to it, but still...
– Actually a pretty complex topic to discuss here – There is a lot of ways you can work around mutable state, and each one has its idiosyncrasies – The level of isolation impacts heavily the shape of your program organization and architecture