Abstraction cannot be taught
or: The Elegance of Programming
It is a funny thing I realized in German class that the school system,
CS education and teaching programming is doomed to fail. But all I
did was to ask my German teacher how we could learn to abstract.
She had no answer, and I couldn’t think of an effective way, either.
Today, I read in the papers that German students “learn nothing in
mathematics in tenth grade”. And I agree, it’s true: when you reach
grade ten (that’s about 16 years), you stop calculating and start
something that’s far more like “real math”: analysis, linear algebra,
a (far too small) bit of statistics. The whole point in learning this
at school is to learn how to abstract, in a mathematical sense. Sure,
few people may really need it later, but most will not. And don’t
even try to ask how it is useful: even teachers can’t figure out
real-world usages for all cases.
Accordingly, the students that can abstract usually don’t have much trouble
with this. The others do.
And it’s not only maths, that’s just where you notice it first. It’s
the same in languages. After you can read, write and speak, you now
need to prove you actually understand what you read. It’s not by
coincidence that you can (and must) analyze both texts and algebraic
terms.
Students that are bad abstracters (and this is not meant derogatorily,
see below) often are good in, say, German at the lower classes. They
write nice compositions about their holidays, can memorize the
spelling rules to pass the dictations, and so on.
Often, trouble starts when you begin interpreting poems. If you look closely,
you’ll notice an interesting change: students that used to be good at
German get quite a bit worse, and students that were not so good get
quite a bit better. At least, that’s what happened to me and some of
my friends.
Suddenly, I became a lot better in German class. At first, I couldn’t
figure out why. Maybe it was because of the new teacher we’ve got.
Three teachers later, I can tell you it likely wasn’t. The focus of
expectation just shifted: they don’t care as much that you can tell
about your holiday, but that you can understand and think about what
you’ve read.
And, in essence, that’s the thing you are supposed to learn in college
or the German Gymnasium. It happens in just about all classes: you
can’t stupidly learn by heart about birds and fish in Biology anymore,
you need to understand. You can’t simply paint nice pictures for art
classes anymore, you need to analyze famous works. You don’t just
translate Latin texts, you need to interpret them. You cannot
even simply run fast in physical education anymore, you need to understand how
you efficiently train (and grokking our PE handbook is far more
difficult than translating Latin texts, trust me). You can start
doing “computer science”, which maybe “only” is elementary Pascal
programming. But for all these things, you need to abstract.
Being able to abstract is the most important thing, because it
multiplies our brain power. Alexandre Borovik writes in the draft for
Mathematics under the
Microscope:
In our conscious and totally controlled reasoning we can process
about 16 bits per second. In activities related to mathematics this
miserable bit rate is further reduced to 12 bits per second in
addition of decimal numbers and to 3 bits in counting individual
objects.
It is completely obvious that we need to fit big ideas into these few
bits to be successful thinkers, by omitting what’s irrelevant.
Since one of the areas in which abstraction completely matters is CS,
Paolo Bucci, Timothy J. Long, Bruce W. Weide asked in 2001: Do We
Really Teach Abstraction?
They conclude:
It may seem that an approach based on mathematical modelling and
formal specification is premature in CS1/CS2. However, in our
experience after four years of teaching this approach, it is not.
They reason because of this that teaching a very mathematical and
formal CS helps the students to understand abstraction better.
However, that only works because of the former exposure of the
students to abstract mathematics. It does not really solve the problem,
but merely shift it: “If you are bad in CS, your math teacher failed.”
Except nobody I asked knows how to teach abstraction. One probably
can learn to abstract better on his own, but that is really hard
work. For example, I think I became a better programmer by learning
functional programming. And functional programming is far much more
mathematical than, say, imperative programming (or even the OO they
often teach). I was able to grasp FP quickly because I knew how to
apply my knowledge of mathematical abstraction—and people that
struggle with FP struggle with mathematical abstraction too. I think
math classes merely sieve the students by their ability, and don’t
enable them.
It turns out they can’t.
My German teacher said students are expected to know how to abstract
at the age of 16. I don’t think they’ll wake up on their 16th
birthday and suddenly know how to abstract. But the age seems right,
it’s probably one of the reasons young people (around the age of 12 to
16) often start programming in imperative languages. The ones they use
(like Basic) don’t allow for high abstraction and they can understand
them better.
Chaitin directly
related the elegance of an program to it’s
length. Given
abstraction as compression, that means the shortest program is the
most abstract. Or: the most abstract program should be the shortest.
By conclusion is every language, for which there is an obfuscated
program that is shorter, an inelegant (or sub-optimally elegant)
language. The mistake in this consideration is of course that the
definitions of abstraction make the program longer. Still, there is
something to be learned from this: the harder it is to compress a
program, the more abstract it is.
In order to judge persons that are unable to abstract well, a further
question needs to be answered: Does ability to abstract equal
intelligence? According to the Hutter
prize (in direct relation to Kolmogorov
complexity) it is: “If you can
compress the first 100MB of Wikipedia better than your predecessors,
your (de)compressor likely has to be smart(er).”
Personally, I think that being intelligent makes you able to abstract
well, but not necessarily vice-versa. I don’t think both are innate,
and only partly heritable. Neither can be taught, but both can be learned.
What’s left is the question of how to do it.
In his 2003 keynote, Abstraction – is it
teachable?,
Jeff Kramer provides a solution. He cites Jean Piaget that students
from seven to twelve years have “some ability for abstraction with
training”, however, with twelve years and more, “[o]nly 30% to 40% of
teenagers exhibit ability for abstract thought, some adults never
do!”. Jeff Kramer concludes that abstraction has to be taught
indirectly and, just like above, by use of mathematics, formal modelling
and analysis.
I think the age of 7–12 therefore is unbacked at our schools with
respect to abstraction. We need to start teaching it earlier
indirectly, when training still works. At later ages, these abilities
can only be exercised, but will not uprise.
NP: Pearl Jam—World Wide Suicide
Euruko 2006: Day Two
Continued from day one.
The first talk on Saturday was about
Ruby and JavaScript by Sven C. Koehler,
who noticed he used less and less Rails, but more and more JavaScript
when developing websites. He explained he likes using JavaScript,
since he can use DHTML (e.g. animations), AJAX and it also saves the
server CPU, since it works on the client side (I’m not really buying
that ;-)). He doesn’t want to use RHTML since it’s too obtrusive
(cf. JSP), difficult to separate mentally and he prefers prefers
CGI-like HTML generation. Also, he doesn’t like RJS because of the
“you don’t need to know JavaScript”-mentality and since JavaScript
code gets slow quickly with growing size. Before digging deeper, he
warned about a few caveats: JavaScript can be taken seriously, it’s a
lot unlike Java, it’s not class-based object-oriented, and it’s
difficult at times to combine libraries. He showed some idioms in
JavaScript (together with Prototype), about using the Ruby-like
enumerable or doing default parameters for methods. Next, he also
listed some bad features of JavaScript, notably the lack of
namespaces, having no nice debugger (it slowly gets better), and
having only a single thread in the browser. Then, he went to show
some Prototype niceties (Try.these, Builder.node and using JSON).
At the end, he presented a new “Web 2.0” web site he has been
developing called MySit.es, best quote during the demo: “It takes a
while, because it’s JavaScript”. The whole user-interface of the web
site is purely based on JavaScript.
Next in line was a talk about ebXML by Sacha Schlegl, which
started with the explanation of open standards and why they are
useful, about the work of OASIS, where ebXML is from, and that open
source and open standards are a good match. ebXML is an XML format
for the next generation of e-business, but I didn’t learn a lot more,
except that, according to him, it should be EBxml, since the
“electronic business”-part is the important one, not the XML.
After this, we got into Ruby code again in the talk
CodeGolfing with Ruby by Jannis Harder, which was written over-night,
but pretty good and interesting nevertheless. Jannis started by
showing off a golfed “paint my numbers” solver, and then tried to
justify code-golfing: his first point was to learn more about obscure
features of Ruby, then he stumbled, and, ehm, ehm, it’s to have fun!
He went on with the problem of adding numbers in a path traversing a
triangle, and polled the audience whether it was “shorter to code” if
he went from top-to-bottom or bottom-to-top. Top-to-bottom actually
turned out to be a lot shorted, especially since you can read the
input and compute at the same time. Then, he showed some golfing
tricks, e.g. using *x=1 instead of x=[1], using map instead of
each or Array#* instead of join. He also listed a few other
techniques, such as heavy use of side-effects, reuse of return values,
use of $...-variables and multiple assignments. After showing us
some more examples of golfed code, he ended his presentation referring
to http://codegolf.com, where one can participate in golfing
contests.
The next talk was about Transparent Archiving by Kero Van Gelder,
which is a kind of lightweight API for assignment that can keep more
than one timestamp of values and archive automatically to files (that
is, some light way of persistence). He wanted the archives to be
human readable, editable and not being too harsh on flash memory.
Following good manners as a software engineer, it’s of course
developed using TDD (he gave a quick introduction to it). After an
overview of its usage, he showed tests and how the implementation
worked.
After this, I presented Sublanguages. You actually can read the
presentation for yourself on my talks
page. Enjoy!
I had to leave Euruko early just after my presentation, so I missed
the talks on CRM and Rails, Patching Ruby, Pay4Code and
Mongrel, which I really would have liked to see… but then I
wouldn’t get the train home. I hope someone else
blogged
about it, else, you got to wait until the videos get uploaded.
Euruko 2006 was big fun for me, and I’d like to thank again the
organizers, Ruby Central, O’Reilly for the book each speaker got for
free, and everyone attending for the great time I had.
See you all next Euruko!
NP: Pearl Jam—Nothingman
Euruko 2006: Day One
This is the first part of
two
blog posts about Euruko 2006, the European Ruby
Conference that took place on November 4th and 5th 2006 in Munich.
Arriving in Munich late Friday afternoon, we soon headed to the
pre-conference dinner at “Augustiner am Dom”, together with some dozen
other Rubyists that were attending (and organizing) the conference, too.
After the dinner, various discussion started, and I learned lots about
making Apple pies in a Sandwich maker, having sex in zero gravity
with help of a rubber-band and about “Creating Passionate Boozers”. It
really was a nice dinner, but we had reserved far too much space for
the people that actually came.
On Saturday morning, we went to Hotel Europe, our conference place.
For the first time this year, we had “theater seating”, so you had no
table to place your notebook, which, I think, would have encouraged
more people to hack together in the presentation-free time. As usual,
power sockets were a rare resource, and the WLAN there was so freaking
expensive (4.50€ for 30 minutes!) that no one I know of bought it. It
provided a nice atmosphere for the speakers, and had a big enough
screen for the projector, too, so giving a talk there still was pretty
nice, and probably better than it used to be in previous years.
The first “presentation” was a skype’d video message of Matz’ Keynote,
which started with “Hello Ruby!”, that we were going to hear a lot of times
due to technical problems. He essentially summarized his RubyConf
2006 talk recognizing Ruby has gained popularity and everyone is
excited about Ruby on Rails. Ruby’s goal is “happy programming”. He
went on with the return of the bike-shed, and explained he was going to
skip the “boring things from the last keynote” :-) According to him,
Ruby has good things (e.g. being a sweet language, having Rails, and
of course the community, said to be “one of the nicest”), but also
ugly (eval.c and parse.y) and bad things (mainly, Ruby 2 being
vaporware for a long time now). After listing a few bike-shed arguments
(inheriting Symbol from String or not, String#lines, removing
private and public or even adding static typing), he explained
Ruby 1.8 is “Good Enough”, so we don’t need to hurry. Still, he wants
to accelerate these bike-shed arguments, he calls it “Extreme
Arguing”. That created quite a few laughs. Before introducing the
future design process, he admitted RCRs didn’t work out. What’s sure
is that Ruby will stay Ruby and Matz will keep being the benevolent
dictator. All new RCRs should contain compatibility analysis and must
not contain vague ideas. PEPs for example seem to work out well.
Also, he wants to move all discussion on mailing lists, which seem
more appropriate than web-based things. Last, he explained why he
wants to have a (more) public design process: he wants to share the
fun of language design, is tired of the slow evolution of Ruby and
that we currently are using a three year old technology. Furthermore,
he fears that other languages will catch up. He also wants to educate
developers in the community. As a side-mark, he noted that if he dies,
we should keep 1.8 untouched forever, but he doesn’t care what we do
with 1.9. At the end of his presentation, he stated that Ruby 1.9.1 will
be out Christmas 2007.
The next talk was about Win32::AutoGui by Kingsley Hendrickse, who
has/had a job as a tester, where he mainly tested GUIs and Windows
applications. Win32::AutoGui is a pure Ruby rewrite of
Win32::TestGui, and according to him, “a library, a tool, it helps
automate things”. A big part of his presentation was done by
rewriting the texts of comic strips (mainly Garfield), which was
pretty amusing and lightened up the talk. He also exclaimed that the
interface is more important than the code, so we shouldn’t look at the
code yet. ;-) After a quick demonstration, he showed a few examples of
how to automate Notepad (by doing key presses and navigating menus),
how he likes to organize his test scripts (a big collection of small
methods, which allows reuse), how to automate the Windows Calculator,
this time using Test::Unit and using button clicks. There he also
managed to make his Ruby core-dump, probably due to the presentation
effect. ;-) He went on with an overview of available methods and
future features he already has planned. The project will be soon on
RubyForge, he stated.
After this, we had a talk about Ruby For Enterprising Testers by Mike Lee
which actually was split into two parts, the second one
described below. Mike has been using Ruby for one year now, but he
doesn’t use Ruby for the beauty of it, but because it works for him.
“It makes idiots like him capable”, he said. Mike works as a tester
for an enterprise, and explained that effective (or lazy!) testers
should automate their tests. After a quick overview of the testing
process, he concluded that reporting really matters for enterprise
usage, and it’s important to automate the testing incrementally so it
will never break for a longer period of time. To the enterprise, Ruby
is dark and dangerous witchcraft, so one needs to be careful on how to
sell Ruby. He said it was easier not to ask for permission, but come
up with ready-made solutions, which luckily are easy and quick to do
in Ruby. Minimizing disruption also is very important for real life
usage. Last but not the least, he said that if they want documents,
write them; it means they like what you are doing.
The second part of the presentation (they work together) was titled
“What I’ve learned since Euruko 2005” by Stefan Kaemper. He said
he learnt “so much”, and not only about testing, but also about
approaching learning languages. According to him, there are two
approaches towards learning languages: Either “start original, get
good”, which gets you going fast, or “start “good”, get original”,
which in the end results in more maintainable code. However, it also
needs more time: being fast and maintainable isn’t easily achieved,
especially since “Software Industry” isn’t really an industry, but
more like good craftsmanship. He went on with their obstacles in
writing a testing framework: they had to learn about the business,
architecture and design the framework, then implement it, deliver
executed test cases, and all that in less than three months and
without budget, or written requirements. He concluded his
presentation with an rough overview of the framework and the API they
use.
The next talk was Ruby on Rails for Java Developers by Mariano Kamp,
which actually was done really good, but somehow we were not really
the right audience. It started by dabbling into very basic Ruby and
later gave an again pretty skin-deep introduction to Rails, always
comparing it to Java. So, it was a really good talk for some Java
audience, but somehow at the wrong place for Euruko. That’s my
impression, at least.
After this, we had a talk on Specter, an ‘expect’ for Ruby by Hal Fulton,
who was probably the most prominent Rubyist in the audience this year.
(He came with help of a grant by Ruby Central, thank you guys!)
He started by explaining what expect is: a TCL-based tool for
manipulating text/console-based programs. He wrote a pure Ruby
implementation dubbed Specter, which works with any IO-like object.
Also, it understands regexps almost everywhere and uses blocks in a
Rubyish fashion. Of course, it’s also highly configurable.
Apparently, it has been around since 2004, but I have to admit I
hadn’t heard of it before.
Then, he went on with an explanation of the API used: #send sends
strings, there are various ways of delay and timeouts, #wait,
#wait_any, and #wait_do (that takes a hash to Procs) expect
strings. He showed a demonstration of it scripting colossal cave, an
old text adventure, and also showed how to connect two instances of
GNU chess so they’d play against each other. Since Specter is useful
for testing, too, he took some time and showed how to use it together
with Test::Unit as well. Although there still are a few bugs and TODO
items (mainly making it faster and having more examples), it has been
used by a friend of him to connect and script real mainframes.
The next talk, and probably the best one that day was
Ten Things I Hate About Rails by Paul Battley,
whose title slide already rocked: He reused the style of the movie
“Ten Things I Hate About You”,
which he of course adapted appropriately.
The purpose of his talk was to take “an opinionated look at some
opinionated software”, and though he doesn’t deny that Rails is great
(It made Ruby popular, has a focused community and people now get paid
coding Ruby), there are quite some parts he considers bad stuff
(the high S/N ratio around Rails, some design decisions), so all in all,
Rails could be better!—Not at least because of the way people write
code for rails reflects on Ruby.
His points were:
HashWithIndifferentAccess, where he actually quoted me saying I
consider it a design smell, because using a lot of Symbols troubles
the memory and it’s really confusing sometimes, too.
That Symbol fetish, he wondered if it’s due to the color of them
in TextMate? He also complained about deprecation of find_first
which got replaced by find(:first), which really doesn’t make it
faster or serves any purpose.
Metaprogramming, which makes a lot of Rails code confusing.
Repetition can be helpful at times, especially if you are not
saving a lot with metaprogramming.
Routing, since the routing code is just ugly (it seems to be
JIT-compiling Ruby!) and actually contains quite some duplication.
The Tests, since although it has a lot of tests they often are not
clear (test_destroy_just_kidding??) or not complete.
Fixtures, which make tests brittle, and keeping them coherent is
difficult.
Scaffolding, which seems to be “more useful for selling it on screencasts than for programming”…
ActiveRecord, because it makes it easy to write unscalable code.
That security incident, having the fix for a fix?
JavaScript helpers, since they are very obtrusive.
(it goes to eleven!), acts_as_*, which are really poorly named
(Example: acts_as_ferret).
The last talk on Saturday was about
Generative Rule-based systems using an interactive Ruby DSL by Mark Rudolph,
who worked at SGI, but now works on image evaluation for the ISS.
He enjoys doing 3D-graphics, but doesn’t like to model, so he uses
rule-based systems, which consist of facts, rules and an inference
engine to apply these rules on facts. He is encoding style into a set
of rules, which then acts as a collective swarm. This way, one can
create complex behavior out of simple rules (kind of chaos effect).
The whole thing works as a generative process: start with an axiom,
apply rules to facts (or facts to rules), then the working memory
accumulates a growing structure of facts, and the rules act as a
collective swarm. He also added semantics to the rule engine, so he
can have fact inter-relations, ‘tags’ on facts, a means for
‘accumulation’ and ‘reinforcement’, for example to allow creating a
given shape and even dynamically alter the character of facts.
The talk ended with an detailed explanation of how it works internally
(He is using method_missing to create seeds, using the rules as
visitors over an object graph and finally flushing (or serializing)
the graph tree as VRML.) It was too bad the system is not yet ready
to actually serialize the objects, so he couldn’t show examples of
what his systems produced.
After this, we went to Kilian’s Irish Pub and I had some very nice
discussions after dinner, mostly with the members of #ruby-de, where
we started with some easy physical questions, moved on to math, group
theory, then category theory, later computability and got quite
philosophical in the end. It was a big fun.
That’s how day one of Euruko ended, move on to day
two.
NP: Dire Straits—On Every Street
Off to Euruko 2006
Last post before traveling to Munich for the European Ruby Conference
2006, where I’ll be talking about Sublanguages
this year.
I don’t know about the net situation in Munich at the conference place
so far, it looks like there will be WLAN, but… you know. :-) If I
get a chance, I’ll try to blog some things just-in-time.
I’m looking forward to meet everyone there.
Anarchaia will resume publishing on Monday, November 6.
NP: Bob Dylan—Disease Of Conceit
