Archive for the ‘Educational’ Category

Programming and Scaling

August 7, 2011

Interesting talk by Alan Kay, the inventor of the term “object-oriented”: Programming and Scaling.

Grid Systems

July 22, 2011

I found a terrific read: Ordering Disorder: Grid Principles for Web Design by Khoi Vinh, former Design Director of the NYTimes, is exactly the book I was looking for to learn in depth about grid systems in UI design. I hope to be able to transfer some of my new found wisdom to the design of the Babel-17 UI support.

Lenses Suck Less

May 27, 2011

The day started well when I found an email with a link to the following video in my inbox:
Making Apps That Don’t Suck.

After watching and enjoying that video, I stumbled (via the scala-debate mailing list) onto the following talk:
Lenses: A Functional Imperative. This was when this day really started to rock.

I mean, how \emph{cool} are Lenses? They are such an obvious concept; maybe so obvious that people who used lenses before didn’t bother to give them an explicit name. But as it is, often sometimes becomes visible and tangible only once it has a name.

Lenses seem to be a must-have for Babel-17. I always wondered how to generalize the following shortcut update notation which is currently available in Babel-17:

val x = { a = 3, b = 2 }
x.b = 7

Here x.b = 7 is short for

x = { a = x.a, b = 7 }

I don’t think that lenses will make it into the Babel-17 v0.3 release, but expect them in Babel-17 v0.3.1 .

UX and lean startup

April 18, 2011

This talk is very interesting. Its main point is that now is the time where designers become one of the cornerstones of the lean startup methodology.

China

April 16, 2011

When fund-raising carries the death sentence.

Wow. Anyone going to China or making business with the Chinese is either a hero or totally mad.

WJP and Complexity Theory

January 21, 2011

This blog (which became famous during the last P != NP discussion) explains some of the work my former boss here in Saarbr├╝cken (Wolfgang Paul) has done 30 years ago in complexity theory.

How to Think about Parallel Programming: Not!

January 15, 2011

I just watched this very interesting talk by Guy Steele. He talks about how programming languages have to adapt from a sequential programming style to a style that enables automatic allocation of processor resources to computations. He identifies the “accumulator pattern” as a sequential programming tool that must be avoided and instead be replaced by various operators like “Sum”, “Product” etc. which come with algebraic properties like associativity, commutativity, idempotence and so on. The algebraic properties provide invariants that create “the wiggle room” for compilers to do proper automatic processor allocation.

Nothing in this talk is real news, but it is always interesting to hear directly the opinion of a guy like Steele. I especially like and agree with the emphasis he puts on accumulators as a bad design choice for parallel programming. But then how come that in Babel-17, accumulators are an integral and important part of the language?! Isn’t Babel-17 supposed to be great for parallel programming?

Actually, there is a difference between the accumulators in Babel-17 and the accumulators Steele frowns upon. In Babel-17, accumulators are explicitly marked as such! Although currently there is no way to associate accumulators with properties like associativity, but there is nothing stopping a future version of Babel-17 from providing such facilities.

To illustrate the two different coding styles, look at the following Babel-17 code below which defines two functions sqrsum1 and sqrsum2 and applies both of them to the vector (1, 3, 7). In both cases the result is 59, as the result of summing up the squares of all elements of the vector should be. The function sqrsum1 is written with an implicit accumulator (implicit for the compiler, explicit for the programmer!). The function sqrsum2 is written with an explicit accumulator (explicit for the compiler, implicit for the programmer!). The style used for sqrsum1 is the one Steele suggests to avoid, but the style used in sqrsum2 is already pretty close to the style Steele advocates. A problem with sqrsum2 is that the protocol for an accumulator in Babel-17 is essentially sequential: collector_add_ x returns a new accumulator by accumulating x into the current one, and collector_close_ projects the final result out of the accumulator. In a future version of Babel-17, there could be additional accumulator protocols, for example collector_inject_, collector_merge_, collector_project_ for a divide/conquer type of protocol. The sequential and the parallel protocols could be distinguished via the “with” construct by adding a qualifier: “with seq” and “with par” instead of just “with”.

Odersky, Armstrong, Syme

November 26, 2010

There is an interesting video with a discussion of Odersky, Armstrong and Syme about programming language. My favorite part is by Armstrong around 3 minutes before the end of the video:

  • There should be smart repositories / version control systems that know about the language
  • Instead of optimizing your code of a solution to a problem, making the code unreadable in the process, write the solution in a (possibly solution-specific) high-level language, and then write a compiler for this high-level language that emits optimized code.

The second suggestion is basically what I will be doing with my next Android phone project by implementing large parts of it in Babel-17, and tweaking the Babel-17 compiler / interpreter to yield acceptable performance. The first suggestion I already had a lengthy discussion about with a former colleague of mine who thought that for example “git” is good enough as it is. “Git” is definitely great, but I also can imagine specialized repositories. For example in interactive theorem proving, a repository that knows about the structure of proven lemmata and so on would be immensely helpful to the user, I think.

Where are programming languages going?

November 19, 2010

I found this talk of one of my all-time heroes, Anders Hejlsberg. Turbo Pascal was my second programming language after QBasic, and therefore it is great seeing him firing up Turbo Pascal in the beginning of this video ­čÖé Takes me back 17 years. Here is the link.

In this video, I especially like his conclusion that the evolution of PL lies in the intersection of declarative languages, concurrency, and dynamic languages. Actually, I hope that I can develop Babel-17 to conquer the very heart of this intersection. In the end he says, expect it to happen, but not too fast, because we programming language designers are a slow bunch. Yep, I totally agree. It will have taken me about 1.5 years to advance Babel-17 from the first prototype implementation in 2009 to the more refined language that Babel-17 will be at the end of 2010. A big part of this refinement is “purely functional structured programming”. Even Anders Hejlsberg distinguished between imperative and functional programming by the possibility of something like “x = x + 1” as opposed to “y = x + 1” in imperative languages. Clearly he should know better and must know in the back of his head that the only difference is shadowing. Spelling this out explicitly in my pfsp paper has helped me enormously to give Babel-17 a simple yet very powerful core that does not represent the end, but the beginning of the line of development of Babel-17.

Design without Designers

November 18, 2010

I just read this article, Design without Designers, and I totally agree with it.

And here is an interesting video about how you have to abandon crap in order to be creative. It is actually part two of a series of videos, which all seem to be interesting.

Well, and here is why you should go for purely functional whereever you can, at least if you care about simple and efficient parallel programming: Mindblowing Python GIL. It also is a partial answer to the question “What about Python?”, which regularly comes up when I start explaining why I need Babel-17.