Summer of Code Results

And the result is: I wasn’t accepted. Not that that surprises me horribly, but I had decided some time ago that I would let whether I was accepted or not determine what I would be doing with my personal time, because unfortunately there are only so many hours in the day. Yes, that means that this blog will basically be dead for some time. I do plan on working on my project for a new Scheme variant at some point in the future, but without someone paying for it I doubt it will be completed this summer. Another reason for this hiatus is that taking an active interest in the Lisp community has somewhat disheartened me with regards to computer science in general. For example comp.lang.lisp was recently embroiled in a flame war recently about whether Lisp-1 or Lisp-2 was better. What made this discussion especially sad was that never once did someone try to prove the benefits of one system over the other based on some criteria for evaluating languages; instead the discussion was carried forwards by opinion. In my heart I want computer science to be based on science (and math) and not who can yell loudest and longest. This realization made me look at my own project and see that it was motivated more by practical concerns than an expression of a new theory of programming. To make significant progress it is probably necessary to base the language off of some theoretical development that promises to solve the hot problems in computer science (such as the pi-calculus). But I digress, so good night and good bye.

Summer of Code Tomorrow

We will see if my project is approved for Google’s summer of code tomorrow. I applied both to Google and LispNYC. According to the student page I am still in the running for LispNYC, although Google rejected my proposal.

What Java Did Right

If you read my blog you probably know that I am no fan of Java. However, Java is a popular language, and because I believe that people are rational that means that it must have some advantages. Obviously Java is not a hacker’s language, nor is it wonderful for quick solutions, or elegant solutions for that matter. What Java does do right is team programming, i.e. any project with three or more people working on it.

First let’s consider Java’s use of types, specifically the fact that they are everywhere. Not a single argument or variable declaration or exception may have its type omitted, even when the compiler could have inferred that information from other sources. This practice is highly cumbersome when you are programming on your own, after all you know what type of arguments your functions expect, because you wrote them, but when looking at someone else’s code it can be salvation itself. Sure your teammates may name their variables inscrutably, but at least knowing the type immediately gives you some hint of what they do. The same argument can be made about Java’s exception handling. Yes it seems silly for the single programmer to declare exactly which exceptions can be thrown, but once again this kind of information is necessary when using someone else’s code. You don’t want to examine the body of the function for throw statements, you want that information in the function declaration where you can see it, and Java gives you this.

Java’s excessive object orientation can also be seen as feature that aids the programming team work together. For example public and private are meaningless in a single programmer’s project, but when working with a team they let you notify your coworkers which functions should be called, and more importantly they provide an implicit promise that you won’t be changing the signature of the public functions. Object oriented programming as a whole also makes it easier to break up who is responsible for what functionality, since the notion of an object that can do certain things is fairly intuitive. Finally, objects, used properly (not singletons), allow programmers working on different parts of the project to both use your code without interfering with each other’s state. For example if you simply wrote a package that exported some methods then it is possible that when the code that programmer A wrote properly using your package and the code that programmer B wrote properly using your package happen to step on each other’s toes when put together (for example the package methods store data in some global variables). On the other hand if your code was an object then A and B would each create their own instances of the object, and there would be no need to worry about shared state.

Now here is the problem: while these features might be nice for teams we want a language that is friendly to the lone coder, so can a language be easy to use in a team project without saddling us with excessive typing and object orientation? Unfortunately I think that no language can, which leaves us with only two options: be able to document everything in the project plan (impossible), or create better IDEs. Ideally the IDE should be able to display visually all the information that Java makes you declare explicitly. For example if the compiler figures out types by inference the IDE should figure them out as well, and display that information where it is useful. Yes I know this doesn’t fix the need for published/public/private functions or objects, I am still thinking about those.

Feel free to chime in with your own ideas.

Type Systems and Scheme (Summary)

This is not really a new post, but merely a convenient place to gather my old posts on type systems and how they might improve Scheme. The 5 parts are:

Part 1: My first misguided type system
Part 2: A critique of type systems
Part 3: A second critique of type systems
Part 3.5: The criterions for a good type system
Part 4: My second proposal for a Scheme type system

I am sorry that I haven’t been working on Scheme much lately, but I have been busy with philosophy.

The Next Big Programming Idiom

Before I begin I would like to state, for the record, that I am not trying to incite a language flame war (at the moment). I’m not asking here which language will be the next popular language, but what programming style will be popular. Will functional programming make a comeback? Will OOP refuse to die? Or will it be something we haven’t seen before?

One thing I am sure it won’t be is natural language programming. Attempting to program using complete sentences is the opposite of what you want a programming language to be, namely concise and powerful. Have you ever heard someone tell you that the code is the documentation? This is because for the most complicated algorithms pseudo-code is a shorter and a more accurate description than words could ever be. As programmers we want our languages to be concise and precise, and natural language is neither.

The rise of a given programming style, historically, can be correlated with what kinds of problems were popular. For example when systems programming was the hot topic C (and the imperative style) became dominant. Functional programming had its heyday with AI researchers, because passing functions around makes algorithms in AI research much simpler. Most recently OOP has become popular with the rise of GUIs, because objects and messages are a natural fit for window controls.

So to predict what will be next we should look at the kinds of problems that programmers deal with most, and I think it is obvious that the “hot topic” in programming is distributed applications, specifically web services, AJAX applications, and collaboration software. From this list it seems likely that the next popular programming idiom will need to have concurrency, state, security, and errors as its strongest points. Concurrency means that the idiom needs a transparent way to deal with threads and synchronization. If you ever need to explicitly create a thread or lock a mutex then the idiom has not solved this problem. State means that the idiom must support the ability to maintain unique data for any number of clients in a natural way, and possibly the ability to unwind state when necessary (much like a continuation). Security means that stupid programmer mistakes, like passing the user name from a text field directly to an SQL query aren’t possible. Tainting is currently a way to “solve” this kind of problem, but I can’t say that it is a very good solution. Another way might be to do away with the ability to pass strings directly to library functions. Finally, errors mean that there must be a transparent way to deal with the unexpected, either by correcting the error in place or exiting from the part of the program that raised the exception. Once again, having an explicit try-catch construct is a sign that errors are a problem that hasn’t been solved as part of the idiom.

Web apps have been around for a while now, so you may be wondering why the next big thing hasn’t arrived already. I think the delay is because in this generation of problems we have several strengths required of new idiom that are at odds with each other, while in previous generations there was the real problems were closely related to each other, and thus easier to solve all at once. What I mean by all at once is that it can’t be simply be four solutions glued together, it needs to be one solution that solves all four problems, much like how OOP solved data encapsulation and message passing at the same time. And of course they must be transparent solutions, meaning that the best solutions with respect to these problems are also the easiest solutions, and require the least amount of programmer effort possible.

OOP enthusiasts will of course tell you how well OOP deals with these problems (try-catch, thread objects, synchronization objects, yadda yadda). These solutions are not transparent at all, and more tellingly the fact that you are expected to use a framework in many OO languages to create large scale web apps (java, ruby, ect) shows that the solutions provided by this idiom aren’t really up to solving all the problems. However, because its replacement hasn’t arrived on the scene yet programmers are stuck with OOP, resulting in buggy and insecure applications. Yes, you can make an OOP project thread safe, resistant to errors, and secure, but it is a radically different kind of task than throwing together a GUI, so why should programmers be using the same techniques? Unfortunately functional programming isn’t the solution either. Although functional programming handles concurrency well (assuming there are no side-effects), it suffers when you try to implement an error handling system, or synchronization when you absolutely must have side-effects.

A solution to the threading and state problems might be event based programming. In event based program the application is structured around a number of events, each of which is called asynchronously. Also each event is called in a “context” (local state). With respect to this context some events are exclusive, meaning that only one can be invoked at a time, while others can be running simultaneously with each other. Event based programming solves the state and concurrency problems, but not those of synchronization or error handling, meaning that it will not be the next idiom, since all of these problems must be solved in one fell swoop. I mention it simply to show that the idioms we currently work with aren’t the end of all language development.

The only conclusion I can provide unfortunately is that whatever the next idiom is that I haven’t seen it yet. If you think that you have feel free to leave a message here.