The document compares programming languages like Ruby, Go and Java based on their accidents (implementation details) and essence (ability to model problems). It argues that languages should focus on essence - allowing better abstraction through full closures and generics to avoid repeated code, and enabling more human-oriented modeling through better representation and immutability. A paradigm shift is needed for languages that facilitate easier communication and feedback like Smalltalk, rather than treating the computer as a typewriter.
26. Can we represent Feb 31st, 2018? - Smalltalk
Exception!
(A point based model of the Gregorian Calendar – H. Wilkinson et al)
27. Problems…
● Invalid objects/data
● Unexpected behavior
● Hidden errors
● Difficult to find errors
● …
● Think about having only valid objects all the time… how would that change
the way you think about the program?
40. Problems…
● Loss of information
● Implementation errors
● …
● Is it possible not to have “null” in a programming language?
(Pony Lang)
● At least it is possible to avoid it … easier with full closures
● Design Tip: Do not use null/nil
45. Purpose of Language:
To provide a framework for communication.
(Design Principles Behind Smalltalk - Dan Ingalls)
46. “The design of a language for using computers must deal with internal models,
external media, and the interaction between these in both the human and the
computer”
(Design Principles Behind Smalltalk - Dan Ingalls)
47. Natural Language
● Spoken
● Gestural
● Multiple channels at the same time
● Bi-directional (immediate feedback)
● Meta-Circular (defined by itself)
● Contextual
● Ambiguous
● Written
● No gestures
● One channel of communication
● Almost no one with immediate
feedback
● Most of them are not meta-circular
(but Lisp, Smalltalk, Self)
● Formal
Programming Language
Peter Naur: Programming Languages, Natural Languages and
Mathematics: https://dl.acm.org/citation.cfm?id=361229
62. Removing Repeated Code
1. Contextual-Move repeated code to some “place”
2. Parameterize what changes (including types)
3. NAME IT! The most important step
4. Use it :-)
74. Let’s do some reflexion
● Why do Java pre 1.8, C/C++ programmers
do not see the “repeated code”?
● What about Go programmers?
● What will happen with new programmers
whose first language will be Go?
78. Therefore...
● We end up having run-time errors, the same as Dynamic Languages!
● What about Generics?
● From the Type System pov, if we do not want repeated code:
○ Dynamic Languages or…
○ Static Typed Languages with Generics
● Else
○ Deal with it!
97. Exceptions
● Abstraction that removes “repeated code” from the “error code technique”
● Easy to implement with full closures
● A Fully Object-Oriented Exception Handling System (Christophe Dony)
● Implementing Exceptions with Ruby:
https://www.youtube.com/playlist?list=PLMkq_h36PcLAE5CPRGG5xd62KVJABPQdd
101. Accidents
Go Ruby Java
Speed Very Good Regular Very Good
Memory Very Good Good Good
Scalability Very Good Regular Very Good
Tools Regular Good Very Good
Environment Good Good Good
Deployment Very Good Good Good
102. Essence
Go Ruby Java
Communication Bad Very Good Good
Change Regular Very Good Good
Modeling Regular Very Good Good
Complexity Regular Good Bad
Augmentation Bad Very Good Bad
105. Normal Science vs. Paradigm Shift
● Ruby, Normal Science or Paradigm Shift?
● Java, Normal Science or Paradigm Shift?
● Go, Normal Science or Paradigm Shift?
● Rust, Normal Science or Paradigm Shift?
● Better type systems, more performance, better IDEs, etc., Normal Science or
Paradigm Shift?
112. Paradigm Shift
● Stop using the computer as “type writer”
● New ways of communication - Today kids do not type, they “touch”
● Easier and better feedback - A la Smalltalk but better
● Better Modeling – More ”people oriented” than “machine oriented”
● …
113. LET’S TOAST FOR LANGUAGES WERE THE LIMIT IS OUR
IMAGINATION AND NOT THE PROGRAMING LANGUAGE