A brief look at learnability of a few modern programming languages, drawing a lot from Bret Victor's Learnable Programming.

1. Are Modern Programming
Languages Easier to
Learn?
Ray Toal, Loyola Marymount University
@rtoal

2. What will this talk be about?
● "Anyone Can Program"
(really?)
● What does it mean to learn
or understand
programming?
● How are modern
languages helping (or not)?

3. I was asked to first talk about myself

4. … and about LMU CS

5. But enough about me

6. Really, Michael?
A noble gesture to garner the NYC tech
community vote, for sure, but if the mayor
of New York City actually needs to sling
JavaScript code to do his job, something
is deeply, horribly, terribly wrong with
politics in the state of New York. --- Jeff
Atwood

7. Who's going to teach everyone?

8. At least it is not as hard as this

9. Because of this visionary
"But Grace,
then anyone
will be able to
write
programs!"

10. But alas, not everyone can
All images from theDailyWTF.com

11. Seriously, it can't be this hard?

12. And it's just not about "mistakes"
What is WRONG
with you people?

13. We need to ask
How do we get people
to understand
programming?

14. This guy knows

15. He wrote a really great essay

16. With this answer
"We change programming.
We turn it into something
that's understandable by
people."

17. Why did he write this essay?
In Inventing on Principle (2011), Bret Victor
demonstrated a remarkable live coding
environment.
Inspired, Khan Academy
implemented it in their
programming section.
But KA missed the point: he
was talking about creating,
not learning.

18. What does he say?
A system should
● support and encourage powerful ways of
thinking
● allow people to see and understand the
execution of their code.

19. What's wrong with KA's approach?
"A live-coding Processing environment addresses
neither of these goals. JavaScript and Processing are
poorly-designed languages that support weak ways of
thinking, and ignore decades of learning about
learning. And live coding, as a standalone feature, is
worthless."

20. Bret Victor's Nine Principles:
The learner should be able to...
E1. See labeled code (not consult manuals)
E2. Follow the flow
E3. See the state
E4. Start somewhere, then sculpt
E5. Start somewhere, then generalize
L1. Work with sensible metaphors
L2. Decompose thoughts
L3. Glue thoughts together
L4. Know what the code means just by reading

21. Languages and Learning
What can the language do for
the learner?

22. It's been done right before!

23. What did they do right?
● Concepts are directly related to the
programmer's world (metaphor)
● Elements decompose into things people
can think about independently
● Program elements can be composed from
other programs and molded to new uses
● State is minimized, or at least explicit
● Syntax (It matters!)
● Names (they matter!)

24. Metaphor
GOOD
● Turtle
● Objects and messages
● Stack of cards
● Movable players
POOR
● Shuffling bits
● Memory cell
LACK OF
● rect(0,0,10,10)

25. Decomposition
NICE THINGS
modules
objects
functions
BARRIERS
Top level event
handlers
Without objects how
do you make
animations, multiple
copies, vary
behavior?

26. Recomposition
BAD STUFF:
● mutable state
● invisible state
● global variables
● lack of encapsulation
● "leakiness"

27. Syntax
draw_circle(center=(2,5), radius=10)
drawCircleCenteredAt: (2,5) withRadius: 10
[3, 5, 9]
{name: "Rex", breed: "G-SHEP", age: 5}
drawCircle(2,5,10)
… however you make arrays in C or Java
… however you make maps in C or Java

28. Names
vectorFromStartAndEndPoint(start, end)
// you can tell this is constructing and returning
// a new vector
vectorFrom:To:
fill(...) // to set a fill color
// why not at least set_fill_color?
rectangle(....) // should be draw_rectangle
concat(a, b) // ambiguous if b is an array, no?

29. So, the BIG things to look for are
Primary metaphors
Identifiable objects
Independent modules
Streamlined syntax (no clutter)
No ambiguity (almost)
Language support for modelessness
Parts of speech used properly in keywords and
libraries
Parameter names in calls
Nice environments (IDEs, Playgrounds)

30. How about some new languages?

31. They're all adopting nice features
● Loop through structures without "for i"
● "for k,v in map" and other destructurings
● Ways to avoid loops (higher order functions)
● String interpolation
● Multiline strings
● x,y = y,x
● a[3..5]
● Patterns
● Optional or inferential typing, for the
statically typed languages

32. Explain some of those, please
for dog in kennel:
dog.bark()
sum(n*n for n in numbers if n % 2 == 0)
sum(map(square, filter(odd, numbers)))
numbers | filter odd | map square | sum

33. CoffeeScript
number = -42 if opposite
square = (x) -> x * x
list = [1, 2, 3, 4, 5]
math =
root: Math.sqrt
square: square
cube: (x) -> x * square x
race = (winner, runners...) ->
print winner, runners
alert "I knew it!" if elvis?
cubes = (math.cube num for num in list)
These examples
are from
coffeescript.org

34. Clojure
"A general-purpose language, combining the
approachability and interactive development of a scripting
language with an efficient and robust infrastructure for
multithreaded programming."
Lots of statelessness, powerful combining forms
(defn scramble [s]
(if (empty? s) "" (-> s seq shuffle join)))
See Rich Hickey's Simple Made Easy

35. Go
"Did the C++ committee really believe that was
wrong with C++ was that it didn't have
enough features? Surely … it would be a
greater achievement to simplify the language
rather than to add to it." -- Rob Pike
In one of his talks, Pike identifies 35
"significant simplifications in Go over C
and C++".

36. Rust
Rust is a systems programming language that runs blazingly fast,
prevents almost all crashes*, and eliminates data races.
So…. what are the chances it is easy to learn?
"Rust's pointers are one of its more unique and compelling features.
Pointers are also one of the more confusing topics for newcomers to
Rust. They can also be confusing for people coming from other
languages that support pointers"
But it's pretty clean, with
 pattern matching
 closures
 type inference

37. Julia
The Julia programming language fills this
role: it is a flexible dynamic language,
appropriate for scientific and numerical
computing, with performance comparable
to traditional statically-typed languages.
x = [1,2,3]
y = [1 2 3]
A = [1 2 3 4; 5 6 7 8; 9 10 11 12]
A[2,1] = 0
u, v = (15.03, 1.2e-27)
f(x) = 3x
x -> 3x
x[2:12]
x[2:end]
A[5,1:3]
A[5,:]
for animal in ["dog", "cat", "mouse"]
println("$animal is a mammal")
end
map(x -> x^2 + 2x - 1, [1,3,-1])
[add_10(i) for i in [1, 2, 3]]
... and keyword args too

38. Swift
I think Apple did a good job here:
● Named Parameters
o counter.incrementBy(5, numberOfTimes: 3)
● Closures
● Tuples and multiple return values
● Fast and concise iteration over a range or collection
● map and filter
● Eliminates much unsafe code: Variables are always
initialized before use, arrays and integers are checked
for overflow, and memory is managed automatically.
● Option chaining! (e.g., p.car?.color)
● Great interactive playground (within XCode)
● Uses the readable Cocoa API

39. So…?
● All have REPLs or Playgrounds and great
online examples.
● All adopt nice features to make programming
a little more pleasant
● But all are industrial strength - do we expect
the learner to quickly master all 7 types of
Rust pointers?
● And none really have the turtle metaphor!

40. Takeaways
● We have decades of research on teaching
and learning that is often ignored
● Learning and understanding programming
requires more than just live coding
● Language should expose metaphor, allow
decomposition and recomposition, and make
meaning transparent
● We saw some modern languages and saw
they did a few things right

41. Okay that's it
Questions?
Discussion.
Thanks!