leah blogs: November 2006

18nov2006 · 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

05nov2006 · 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

04nov2006 · 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:

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

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

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

  4. Routing, since the routing code is just ugly (it seems to be JIT-compiling Ruby!) and actually contains quite some duplication.

  5. The Tests, since although it has a lot of tests they often are not clear (test_destroy_just_kidding??) or not complete.

  6. Fixtures, which make tests brittle, and keeping them coherent is difficult.

  7. Scaffolding, which seems to be “more useful for selling it on screencasts than for programming”…

  8. ActiveRecord, because it makes it easy to write unscalable code.

  9. That security incident, having the fix for a fix?

  10. JavaScript helpers, since they are very obtrusive.

  11. (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

03nov2006 · 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

Copyright © 2004–2022