1. Polyglot and Poly-paradigm
Programming
for Better Agility
Dean Wampler
dean@deanwampler.com
@deanwampler
1

2. 2
Co-author,
Programming
Scala
programmingscala.com

3. Polyglot:
many languages
Poly-paradigm:
many modularity
paradigms 3

4. Today’s
applications:
•Are networked,
•Have graphical
and “service”
interfaces,
flickr.com/photos/jerryjohn 4

5. Today’s
applications:
•Persist data,
•Must be resilient
and secure,
•Must scale,
flickr.com/photos/jerryjohn 5

6. Today’s
applications:
•… and must do
all that by Friday.
flickr.com/photos/jerryjohn 6

7. flickr.com/photos/deanwampler
Mono-
paradigm:
Object-Oriented
Programming:
right for all
problems?
7

8. twitter.com/photos/watchsmart
Is one language
best for all
domains?
Monolingual
8

9. Symptoms of
Monocultures
• Why is there so much XML in my Java?
• Why do I have similar persistence code scattered
all over my code base?
• How can I scale my application by a factor of
1000!
• My application is hard to extend!
• I can’t respond quickly when requirements change!
9

10. switch (elementItem)
{
case "header1:SearchBox" :
{
__doPostBack('header1:goSearch','');
break;
}
case "Text1":
{
window.event.returnValue=false;
window.event.cancel = true;
document.forms[0].elements[n+1].focus();
break;
} ...
thedailywtf.com
Pervasive IT problem:
Too much
code!
10

11. Solutions
The symptoms reflect
common problems
with similar solutions.
11

12. I need
extensibility
and agility.
Specific problem #1
flickr.com/photos/arrrika 12

13. Symptoms
•Features take too long to
implement.
•We can’t react fast enough
to change.
•Uses want to customize the
system themselves.13

14. Solution
Application
Kernel of Components
User Scripts Built-in Scripts
(C Components) + (Lisp scripts) = Emacs
14

15. Components + Scripts
=
Applications
see John Ousterhout, IEEE Computer, March ’98
15

16. Kernel Components
•Statically-typed language:
•C, C++, Java, C#, ...
•Compiled for speed, efficiency.
•Access OS services, 3rd-party
libraries.
•Lower developer productivity.
16

17. Scripts
•Dynamically-typed language:
•Ruby, Python, JavaScript, Lua, ...
•Interpreted for agility.
•Performance less important.
•Glue together components.
•Raise developer productivity.17

18. In practice,
the boundaries between
components and scripts
are not so distinct...
18

19. Ola Bini’s Three Layers
•Domain layer
•Internal and External DSLs.
•Dynamic layer
•e.g., JRuby, application code
•Stable layer
•JVM + generic libraries19

20. Other Examples
of This Approach
•UNIX/Linux + shells.
•Also find, make, grep, ...
•Have their own DSLs.
•Tektronix Oscilloscopes: C +
Smalltalk.
20

21. Other Examples...
• Adobe Lightroom: C++ + Lua.
• 40-50% written in Lua.
• NRAOTelescopes: C + Python.
• Google Android: Linux +
libraries (C) + Java.
21

22. <view-state id="displayResults" view="/searchResults.jsp">
<render-actions>
<bean-action bean="phonebook" method="search">
<method-arguments>
<argument expression="searchCriteria"/>
</method-arguments>
<method-result name="results" scope="flash"/>
</bean-action>
</render-actions>
<transition on="select" to="browseDetails"/>
<transition on="newSearch" to="enterCriteria"/>
</view-state>
</flow>
XML in Java
Why not replace XML
with JavaScript , Groovy
or JRuby??
22

23. Other Examples:
MultilingualVM’s
• On the JVM:
• JRuby, Groovy, Jython,
Scala.
• Ruby on Rails on JRuby.
23

24. Other Examples:
MultilingualVM’s
• Dynamic Language Runtime
(DLR).
• Ruby, Python, ... on
the .NET CLR.
24

25. Benefits
•Optimize performance where it matters.
•Optimize productivity, extensibility and agility
everywhere else.
Application
Kernel of Components
User Scripts Built-in Scripts
25

26. Disadvantages
Application
Kernel of Components
User Scripts Built-in Scripts
26
•More complexity with 2+ languages
(idioms, tools, ...).

27. An underutilized
architecture!
Application
Kernel of Components
User Scripts Built-in Scripts
27

28. Parting Thought...
Cell phone makers are
drowning in C++.
(One reason the IPhone
and Android are interesting.)
28

29. I don’t
know what
my code is
doing.
flickr.com/photos/dominic99
Specific problem #2

30. The intent
of our code
is lost
in the noise.30

31. Symptoms
•Business logic is obscure when I
read the code.
•The system breaks when we
change it.
•Translating requirements to code
is error prone.
31

32. Solution #1
Write
less code.
Profound statement.
32

33. Less Code
• Means problems are smaller:
• Maintenance
• Duplication (DRY)
• Testing
• Performance
• etc. 33

34. How to Write
Less Code
• Root out duplication.
• Use economical designs.
• Functional vs. Object-Oriented?
• Use economical languages.
34

35. Solution #2
Separate
implementation details
from business logic.
35

36. Domain Specific
Languages
Make the code read like
“structured” domain prose.
36

37. Example DSLinternal {
case extension
when 100...200
callee = User.find_by_extension extension
unless callee.busy? then dial callee
else
voicemail extension
when 111 then join 111
when 888
play weather_report('Dallas, Texas')
when 999
play %w(a-connect-charge-of 22
cents-per-minute will-apply)
sleep 2.seconds
play 'just-kidding-not-upset'
check_voicemail
end
}
Adhearsion
=
Ruby DSL
+
Asterisk
+
Jabber/XMPP
+
...
37

38. DSL Advantages
• Code looks like domain prose:
• Is easier to understand by
everyone,
• Is easier to align with the
requirements,
• Is more succinct.
38

39. DSL Disadvantages
• DSLs are hard to design, test
and debug.
• Some people are bad API
designers.
39

40. Brueghel the Elder
A DSL Tower of Babel?
40

41. Parting Thought...
Perfection is achieved,
not when there is nothing left to add,
but when there is nothing left to remove.
-- Antoine de Saint-Exupery
41

42. Parting Thought #2...
Everything should be made as simple
as possible, but not simpler.
-- Albert Einstein
42

43. Corollary:
Entia non sunt multiplicanda
praeter necessitatem.
-- Occam’s Razor
43

44. Corollary:
All other things being equal,
the simplest solution is the best.
-- Occam’s Razor
44

45. We have
code duplication
everywhere.
Specific
problem #3
deanwampler

46. Symptoms
• Persistence logic is embedded
in every “domain” class.
• Error handling and logging is
inconsistent.
Cross-Cutting Concerns.
46

47. Solution
Aspect-Oriented
Programming
47

48. Removing Duplication
• In order, use:
• Object or functional decomposition.
• DSLs.
• Aspects.
48

49. An Example...
49

50. class BankAccount
attr_reader :balance
def credit(amount)
@balance += amount
end
def debit(amount)
@balance -= amount
end
…
end
Clean Code
50

51. But, real applications need:
def BankAccount
attr_reader :balance
def credit(amount)
...
end
def debit(amount)
...
end
end
Transactions
Persistence
Security
51

52. def credit(amount)
raise “…” if unauthorized()
save_balance = @balance
begin
begin_transaction()
@balance += amount
persist_balance(@balance)
…
So credit becomes…
52

53. …
rescue => error
log(error)
@balance = saved_balance
ensure
end_transaction()
end
end
53

54. We’re mixing multiple domains,
Transactions
Persistence
Security
with fine-grained intersections.
“Problem Domain”
“tangled” code
“scattered” logic
54

55. Objects alone don’t
prevent tangling.
55

56. Aspect-Oriented
Programming:
restore modularity for
cross-cutting concerns.
56

57. Aspects restore modularity by
encapsulating the intersections.
Transactions
Persistence
Security
Transaction
Aspect
Persistence
Aspect
Security
Aspect
57

58. If you have used the
Spring Framework,
you have
used aspects.
58

59. • Ruby
• Aquarium
• Facets
• AspectR
Aspect-Oriented Tools
• Java
• AspectJ
• Spring AOP
• JBoss AOP
shameless plug
59

60. I would like to write…
Before returning the balance, read the
current value from the database.
Before accessing the BankAccount,
authenticate and authorize the user.
After setting the balance, write the
current value to the database.
60

61. I would like to write…
Before returning the balance, read the
current value from the database.
Before accessing the BankAccount,
authenticate and authorize the user.
After setting the balance, write the
current value to the database.
61

62. require ‘aquarium’
class BankAccount
…
after :writing => :balance
do |context, account, *args|
persist_balance account
end
…
reopen class
add new behavior
Aquarium
aquarium.rubyforge.org62

63. def credit(amount)
@balance += amount
end
Back to clean code
63

64. Parting Thought...
Metaprogramming can be used
for some aspect-like functionality.
DSLs can solve some
cross-cutting concerns.
(We’ll come back to that.)
64

65. Specific problem #4
flickr.com/photos/wolfro54
Our service
must be
available 24x7
and highly
scalable.

66. Symptoms
• Only one of our developers
really knows how to write
thread-safe code.
• The system freezes every few
weeks or so.
66

67. Solution
Functional
Programming
67

68. Functional Programming
•Works like mathematical functions.
Fibonacci Numbers:
F(n) = F(n-1) + F(n-2)
where: F(1) = 1 and F(2) = 1
68

69. Functional Programming
• Variables are assigned once.
• Functions are side-effect free.
• They don’t alter state.
y = sin(x)
69

70. Functional Programming
Makes Concurrency
Easier
• Nothing to synchronize.
• Hence no locks, semaphores,
mutexes...
70

71. Which fits your needs?
Object Oriented
71
Account
deposit(...)
withdraw(...)
CheckingAccount
deposit(...)
withdraw(...)
SavingsAccount
deposit(...)
withdraw(...)
??
deposit(...)
withdraw(...)

72. list map
fold/
reduce
filter
Which fits your needs?
Functional
72

73. flickr.com/photos/deanwampler
What if
you’re
doing cloud
computing?
73 deanwampler
Is it object-oriented
or functional?

74. FP Code is
declarative
rather than
imperative.
F(n) = F(n-1) + F(n-2)
where: F(1) = 1 and F(2) = 1
74

75. … and so are DSLs.
class Customer < ActiveRecord::Base
has_many :accounts
validates_uniqueness_of :name,
:on => create,
:message => ‘Evil twin!’
end
75

76. A Few
Functional Languages
76

77. Erlang
• Ericsson Functional Language.
• For distributed, reliable, soft real-time,
highly concurrent systems.
• Used in telecom switches.
• 9-9’s reliability for AXD301 switch.
77

78. Erlang
• No mutable variables and side effects.
• All IPC is optimized message passing.
• Very lightweight and fast processes.
• Lighter than most OS threads.
• Let it fail philosophy.
78

79. Scala
• Hybrid: object and functional.
• Targets the JVM and .NET.
• “Endorsed” by James Gosling at JavaOne.
• Used at Twitter, Linkedin, ...
• Could be the most popular
replacement for Java.
79

80. Clojure
• Functional, with principled support for
mutability.
• Targets the JVM and .NET.
• Best buzz?
• Too many good ideas to name here...
80

81. Functional Languages in
Production
• Erlang
• CouchDB
• GitHub
• Jabber/XMPP server ejabberd.
• Amazon’s Simple DB.
81

82. Functional Languages in
Production
• OCaml
• Jane Street Capital
• Scala
• Twitter
• LinkedIn
82

83. Parting Thought...
Is a hybrid object-functional language
better than using an object language
with a functional language??
e.g., Scala vs. Java + Erlang??
83

84. Polyglot and Poly-paradigm
Programming (PPP)
for Better Agility
Recap:
84

85. Disadvantages of PPP
• N tool chains, languages, libraries,
“ecosystems”, ...
• Impedance mismatch between tools.
• Different meta-models.
• Overhead of calls between languages.
85

86. Advantages of PPP
• Can use the best tool for a particular job.
• Can minimize the amount of code
required.
• Can keep code closer to the domain.
• Encourages thinking about architectures.
• E.g., decoupling between “components”.
86

87. Everything old
is new again.
• Functional Programming Comes of Age.
• Dr. Dobbs, 1994
• Scripting: Higher Level Programming for
the 21st Century.
• IEEE Computer, 1998
• In Praise of Scripting: Real Programming
Pragmatism.
• IEEE Computer, 2008

88. Why go mainstream now?
•Rapidly increasing pace of development,
➔ Scripting (dynamic languages), DSLs.
•Pervasive concurrency (e.g., Multicore CPUs)
➔ Functional programming.
•Cross-cutting concerns
➔ Aspect-oriented programming.
88

89. Common Themes
• Less code is more.
• Keep the code close to the domain:
DSLs.
• Be declarative rather than imperative.
• Minimize side effects and mutable data.
89

90. ThankYou!
• dean@deanwampler.com
• Watch for the IEEE Software
special issue, Sept/Oct 2010.
• polyglotprogramming.com
90