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.

1. Go/Ruby/Java
What’s next?
Hernán A. Wilkinson
@hernanwilkinson – www.10pines.com
agile software development & services

3. How do we analyze and compare a
Programming Language?

4. Accidents and Essence of … - Plato

5. Accident and Essence of Software - No Silver Bullet

6. Software

7. Set of instructions

8. Set of instructions?

9. Computable Model of a Problem Domain

10. Good Software = Good Model

11. Good Model – Three Axes
● Functional
● Declarative
● Implementative

12. Good Model – Three Axes
● Functional
● Declarative
● Implementative

13. Model

14. Newton - Einstein

15. How do we represent Feb/2018? (a month of year)

16. How do we represent Feb/2018? (a month of year)
(Java 1.8)

17. How do we represent Feb/2018? (a month of year)
(Smalltalk)

18. How do we represent Feb/2018? (a month of year)
Ruby - Go - Java pre 1.8
?

19. How do we represent Feb/2018? (a month of year)
Ruby - Go - Java pre 1.8

20. Problems…
● Lack of representation
● Reinvent the “flat tire” (Alan Kay)
● Ad-hoc solutions
● Communication errors
● …
● What about immutability?
* Immutability  Setters?  Encapsulation
* Heraclitus vs. Parmenides / Java vs. Haskell

21. What about the other way around?

22. Should we be able to represent Feb 31st, 2018?

23. Can we represent Feb 31st, 2018? - Java pre 1.8
03/03/2018 !!!

24. Can we represent Feb 31st, 2018? - Go
03/03/2018 !!!

25. Can we represent Feb 31st, 2018? - Java 1.8
Exception!

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?

28. What about this?

29. Account
...

30. Problems…
● Complexity... with all the problems it generates

31. What about this?

32. 1
1 $
1 gallon
1 BTC
What does 1 represent?

33. null
Var. not initialized?
Customer does not have
address?
Phone has not be entered?
What does “null” represent?

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

41. Conclusion

43. What does it have to do with
Programming Languages?

44. Programming ¿Language?

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

49. How does a Language affects “our
thinking”?

51. Aymara
Past (nayra) and Future (qhipa)
(https://www.theguardian.com/science/2005/feb/24/4)

52. How does a “Programming Language”
affects “our thinking”?

55. What is the problem?

56. Repeated Code!

57. Code != Text

58. Code != Text
Repeated Code = Repeated patterns of
collaboration

59. What does it mean to have
“repeated code”?

60. Repeated Code Means
● Lack of abstraction
● In OO terms: Lack of an Object

61. How do we remove it?

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 :-)

63. Contextual-Move

64. What changes?

65. How do we parameterize it?

66. Polymorphism

67. How do we parameterize it?

68. Generics

69. How do we parameterize it?

70. Lambda/Closure/Full Closure/Anonymous Func.

71. Name it!! – The most important step

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?

75. Go

77. hmm…

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!

79. What is the problem?

81. and now? What is the problem?

82. Repeated Code!

84. better, but...

85. Repeated Code!

87. Cool! No repeated code!
No way to forget to handle the error!

88. Much Nicer! – No doubt about it!

89. But… I don’t want to panic! I want to
stop execution and return the error!

91. Will stop execution?

92. Full Closure to the rescue!!

93. What will be printed?
Ruby

94. 15
10

95. Only if we could do this...

96. What are Exceptions?

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

98. Exceptions - Problems
● Misused
● More classes than necessary → Complexity
● Checked exceptions → NOOOO!
● Incorrectly handled

99. So… How do we analyze and compare a
Programming Language?
Accidents - Essence

100. Accidents
● Speed
● Space
● Scalability
● Tools?
● Environment? (git, cloud, etc)
● Deployment?
● Communication (immediate
feedback/etc)
● Change
● Modeling (Representation of ideas)
● Simplicity (or Complexity?)
● Augmentation (meta-circularity)
Essence

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

103. Where do we go from here?
What’s next?

104. Normal Science vs. Paradigm Shift

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?

106. 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

114. Thanks!
Hernán A. Wilkinson
@hernanwilkinson – www.10pines.com
agile software development & services