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.
Archive for the ‘Uncategorized’ Category
Posted by Peter on May 22, 2006
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.
Posted by Peter on May 14, 2006
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.
Posted by Peter on May 6, 2006
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.
Posted by Peter on May 1, 2006
I am applying for Google Summer of Code. The following is my application this year (submitted to LispNYC and Google):
One Sentence Summary:
I would like to develop a new Lisp language/variant in order to experiment with various ideas that might be later used to improve any Lisp language, hopefully a mainstream one.
Why Another Lisp?
The purpose of this language wouldn’t be to complete with various Common Lisp or Scheme implementations, but to try out new language ideas. Hopefully by playing around with ideas in an actual language instead of on paper the good ones will be separated from the bad ones based on actual usefulness. There is a large list of features that I would like to explore, such as hygienic macros without define-syntax, a module system that supports nested modules and versioning, a transparent system for errors, threads, and multiple values, and probably other ideas that will occur to me later, or I run across in a research paper. The primary idea, which motivates me to write another Lisp from the ground up, instead of just adding macros to existing implementations, is to try out type inference. I want to see if strong type inference, as well as function overloading by type, would be useful to Lisp or simply a cumbersome burden. If you want to see a list of my complaints with Scheme in order to have a better sense of the “problems” that I want to tackle you can go here: https://pschombe.wordpress.com/2006/04/30/real-criticisms-of-scheme/.
Evidence that I can actually accomplish this:
Obviously implementing a Lisp language isn’t the easiest task in the universe, especially if you want that language to be able to compile to native code as I do. As proof that I know what I am doing, and that I can accomplish it in one summer I would direct you to Centum (http://centum.sourceforge.net), which is a language I designed and implemented two summers ago. Although I continued working on it (and published it publicly) during the year the majority of the work was accomplished over summer, despite the fact that I had a job and summer school. Centum was also a horrible hack of a language, and since Lisp can be written for the most part in Lisp it should be a much easier task. Finally, I have already begun to work on parts of the implementation, for example the asynchronous garbage collector (see here: https://pschombe.wordpress.com/2006/04/27/actual-code/).
This is going to be a Windows project, unless I find someone to help me port it that is. Although I have been interested on working on Linux for some time, because this project is closely tied to the operating system’s capabilities (especially when compiled) I think it is best to stick with what I know, for I fear that the time I would spend leaning how to do the things I want under Linux might take as long as the rest of the project. Also the code itself will be in C++, since once again I need to get close to the hardware in order to accomplish such feats as run-time compilation and asynchronous garbage collection. Of course the primary goal of this project is to experiment with ideas, not with code, and ideas are always cross-platform. I plan on releasing the source under a BSD license.
Plan of attack:
Now – June 17: Framework code written: garbage collector, types, parser
June 17: School Ends
June 17 – June 26: Get a running version working (just the basics)
June 27 – July 12: Implement type inference, enable compilation
July 13 – July 22: Work with modules, threads, macros
July 23 – Aug 2: Work with error handling, debugging options (i.e. step mode)
Aug 3 – Aug 12: This time is budgeted for unforeseen circumstances, documentation
Aug 13 – Aug 22: Work on libraries, such as GUI, add remaining primitive functions, more documentation
Aug 23 – Sept 2: Final week for debugging, more documentation
Sept 2 – Sept 18: Polish code, write examples, libraries, finish documentation
September 18: School Begins
Why you might want to give me money:
Since I have already started working on this project you may wonder why you would want to give me money, because it is obvious that I will continue working on this project without funding. First funding would allow me to focus the majority of my efforts on the project, instead of worrying about part-time jobs or other money making ventures. Secondly my fear of actual deadlines will cause me to work much faster than you would expect, leaving more time to polish the result and to eliminate bugs. Obviously the resulting product will not make you any money, nor is it likely become famous or well loved. The benefit to you is that ideas that could improve Lisp, or any language, are actually put to the test, so that when the next “serious” Lisp language is developed you will know which features to bother with and which to throw away. Obviously, since everyone needs programming languages to get work done improvements in this area benefit businesses and hobbyists alike. Extra bonus: if you want I’ll let you pick the language’s name.
Thanks for your consideration,