Lambda the Ultimate

Don't think it should surprise anyone that I'll say JavaScript (time for me to plug Beyond again.) JavaScript is mostly used for client-side Web programming, but then I'm a client-side kind of guy :) Also, I am aware of several shops that program the server-side (ASP) using JavaScript, if only to use the same language on both sides. Also, in .NET JavaScript is a first class citizen, with support for compilation.

JavaScript used to be problematic for server-side programming because of the lack of error handling, but this has been fixed with the inclusion of try/catch. JavaScript is also fully object-oriented with built-in support for regular expressions and easy string manipulation. And using Beyond you can do functional programming.

The downsides: script language so slower, untyped variables (some like this, some don't), variables don't have to be declared (my main peeve), scoping rules less than ideal, etc.

I was quite impressed with Swiki, which is Squeak based.

It is something of a cliche to say that server side programming allows you to choose whatever language you want, and allows you to switch languages easily.

Client side programming is much more problematic.

1. Server side programs. These are basically things that operate via the CGI protocol etc.
2. Client side. (1) Broswer enabled languages (VBScript, JavaScript) (2) Languages that need to use plugins of various sorts (Curl?)
3. Web services. (and SOAP, XML-RPC etc.) May brings us back to the WSDL debate.
4. Mobile code. Leads to more interesting issues (trust, PCC, using VMs etc.)

What did I forget to mention?

Although it's not a programming language, rather a development platform, I would like mention that I'm rather impressed with the features of ASP.NET (at least on paper, as I haven't used it to build anything of real substance yet.) Features that I like:

1. Server-side DOM (with server-side events)
2. Web controls - can "drag and drop" like VB but generate HTML that works for most any browser.
3. Data binding

Server-side DOM (with server-side events)

1. Server side programs. These are basically things that operate via the CGI protocol etc.

2. Client side. (1) Broswer enabled languages (VBScript, JavaScript) (2) Languages that need to use plugins of various sorts (Curl?)

3. Web services. (and SOAP, XML-RPC etc.) May brings us back to the WSDL debate.

4. Mobile code. Leads to more interesting issues (trust, PCC, using VMs etc.)

One other thing that interests me that may be an intersection of these points: how state is handled. One of the things I simultaneously love and hate about the web is state. For one, it's a stateless protocol (HTTP) built atop a protocol with state (TCP). This means I can do things like close my browser after reading mail but I don't have to worry about the mail disappearing. But it also means that passing variables between pages and/or scripts/programs is made more difficult than it might be otherwise.

This is just a random thought, but I wonder what Milner's action calculi and mobility work would look like in the context of a maze of twisty little web apps, all alike. ;]. That might be an interesting "web service".

Plus, there's the ongoing dichotomy between presentation and logic on the web. Sure, there's XML and XHTML and what not, but let's be real: things like Slashdot, Kuro5hin, and the web app I'm building now with PHP are a mix of code and HTML, and it uses all the ugly stuff like nested tables in order to work across browsers (including Netscape 4, which makes a complete mess of CSS). To some extent, in the servlet template engine community (WebMacro, Velocity, Tea, etc.), there's a lot of attention paid to writing web apps in a MVC fashion. Indeed, you can do this in PHP too, but the language certainly is constructed with it in mind, it merely supports it. I've heard from some of the top Zend people that PHP supports OO but is not an OO language. Remind you of any other C-esque languages you know?

There's some work with Scheme and other Lispy tools & methods that view web pages and web apps in the framework of continuations which sounds complex on one hand, but interesting and very well suited on the other. I remember reading something to this effect on LL1, maybe from one of the PLT crew. Paul Graham is focusing on web apps for Arc, so that too should be interesting.

I am begining to think (after about 5+ years of heavy web-development work with all sorts of platforms and languages) that maybe what is needed is a whole new way of approaching the concepts of applications and programming.

Of course, what that new approach is, i dont know exactly yet.

I am curious about the whole .NET/Web Services thing. But i am sceptical because it seems less like a "concept" and more like a peice-of-shrinkwraped-software-with-the-empty-marketing-promise-of-making-developers-lives-easier.

I have recently been looking at the Plan 9 Operating System (http://www.vitanuova.com/plan9/main.html) from AT&T/BellLabs/Lucent/whatever. And i am intrigued by the ideas they are utilizing in an OS environment (distributed OS actually). Its supposed to be a kind of replacement for UNIX. The idea (if i understand correctly) is that each user lives in their own process space, which is seen/viewed/percieved to be a heirachy of files. All things from network services to actual files are viewed as this same heirachial file structure. There is something both nice, and boring about that kind of uniformity.

Thanks for the link,.. i have been looking for a good summary of the whole ASP.NET thing. It is much like what i expected (with a few nice surprises).

In the end though, .NET is more an example of the problem in my mind, rather than the solution. Now i am not an anti-Microsoft type, or anything like that. What i am is anti-bloat, it seems to that the whole .NET platform is just another HUGE peice of software that runs on top of other HUGE peices of software. It is completely tied to the microsoft way of doing this as well. Again,.. i am not anti-redmond or anything,.. i just dont always agree with their way of doing things.

The JIT compilation might add a slight performance edge but its still the same old paradigm. Common Language Runtime is going to do more harm than good on large projects, while on really providing convience on smaller ones (if anything at all). I mean, it seems kinda like the old PERL idea of "more than one way to do things" gone too far. And the idea of Web Forms is nothing new, and i very highly doubt that it produces quality cross brower code (not many HTML WYSIWYGs do). The whole idea of Web Forms reminds me of Apple's (formally NeXT's) Web Objects, which uses a web-ified version of the Cocoa API to get the same effect in a more intuitive and time-tested way (and its only $800 bucks and is 100% Java 2 (not J2EE cause they dont need beans,. they already have a data-access/store component in the framework)).

All in all, it is a welcome change from the old ASP, but how much of a paradigm shift it will cause remains to be seen.

I think the real goal is to move beyond the idea that a GUI app is a collection of widgets each connected to some kind of data-object. To build on top of that. Onto a higher level of abstraction. To a certain degree i am talking more about human-computer interaction than i am about programming paradigms, but i beleive that they are very muched linked together. If you think of the way that programming has evolved in the past 10 or so years, things like OOP and GUIs go hand in hand. Now think of what the web has already done to the world of computer programming, and i belive that this is really just the begin of that.

If you look at what is going on with small internet accessable hand-helds. The whole Client-Request/Server-Response paradigm is not really working in the same way it does on PCs. On devices with smaller displays HCI/Usability becomes a bigger issue, and a faster response time is critical. You could offload to client-side processing, but then you run into issues like processor speed & battery drain. This is one example where totally new thinking might be the way to go.

Bell Labs (again) has a distributed OS/Platform/System/Swiss Army Knife called Inferno, that seems promising. I have only just skimmed the documentation at this point. (http://www.vitanuova.com/inferno/index.html) It takes on what .NET, JINI only scratch the surface of in terms of making things talk to one another.

Some tasty papers on this can be found at

http://www.ccs.neu.edu/scheme/pubs/index.html#papers

See

Automatically Restructuring Programs for the Web and

Programming the Web with High-Level Programming Languages

But I am not sure I am with you in your objection to cross language runtimes. I think this is interesting approach. One thing that it entails is the reification of interesting language constructs. There is still plenty of room for interesting research here (maybe I'll take a look at it myself). Why is this reification important? Not just for inter-language communication: it will also allow better support for distribution, persistence etc.

Maybe the VVM approach mentioned here recently can prove worthwhile, and allow CLR-like VM architectures with less overhead.

My objection to cross language runtime is mostly from a project management point of view. I can see it as powerful way to "optimize" certain areas of your application, by using languages that are most suitable to the task at hand. But in terms of future maintainence of the project, it is a nightmare. It would require the maintainer to be fluent and capable in all the different langauges. From a research pov, its interesting. From a real-world project pov, it is impractical.

Thanks for the link. Very intersting stuff. I have actually used the continuation passing technique described in the "Automatically Restructuring Programs for the Web" paper many times, although never calling it continuation passing. I have always tried to make my pages more like objects (capable of holding state and performing functions on that state). It has helped in keeping the code clean, and reusable.

The "Programming the Web with High-Level Programming Languages" paper has some very interesting ideas in it as well. Although i think that implementing ones own web server is a larger undertaking than most projects can handle. But i do like the idea of viewing the web as an OS.

One of the things that i have been working on lately is a library of HTML/DHTML widgets, that are generated (HTML/Javascript/CSS and all) on-the-fly on the server (or as static HTML pages if there is no dynamic content in them). The next step is to make these widgets be capable of holding their state over the course of Request/Response cycle in a CGI environment. The idea is to create an API (of sorts) that looks more like your standard GUI API, and when you "run" a program that uses this API, it then creates all the HTML and handles all the state for you. For instance, to create a list box you would only have to create a new ListBox object instance in your server-side program, define its attributes and fill it with a list. The HTML/Javascript/CSS and state support code would then be created for you when the program was run on the server. Anything like gui event callbacks can either be handled as a form submission to the server or as a javascript function on the client side. The idea is to take away the need to create all that state & HTML support code, and really treat the HTML GUI more like a regular GUI. This project is really just an attempt to generalize what i have been doing all this time on a project-by-project basis.

Now from a project management pov, 95% of the time you write code in one language, that uses pre-built components that may be written in other languages. But you don't care, since you program to well defined failry static interfaces.

I wasnt really thinking about it in a component way. In that way, it does make more sense, and should make component dev much easier. But a multi-language project is still a pain in the *ss to manage/maintain (assuming you are maitaining all the code, where with a vendor supplied component you are not).

I wonder though if there are any performance gains in using a more traditionally static language like C/C++ with the CLR as opposed to a more dynamic (usually interpreted language) like Javascript? Does the CLR make all languages equal in terms of speed of execution? Obviously some language "features" in the more dynamic languages will require more machine instructions to be performed, but without the interpreter overhead will the actual runtime speed be the same?

Also, regarding the regular program -> distributed state program idea. I was very impressed with this, but it seemed (and i haven't gotten a chance to _really_ look at it) that this is a technique that is only useable with a LISP-ish language and is certainly NOT possible with a GUI based program.

Does the CLR make all languages equal in terms of speed of execution? Obviously some language "features" in the more dynamic languages will require more machine instructions to be performed, but without the interpreter overhead will the actual runtime speed be the same?

When you call a CLR function execution time will be the same regardless of the calling language. I think you may be surprised at how little time the CPU spends inside your code as opposed to library/system code. For example, if you are developing a DB app, optimizing the SQL query is way more important than the performance of the language that hosts it (and this is also an example of cross-language development you can't get away from).

Though it's nice that ASP.NET compiles the code, unlike ASP, that IMO is not its main feature. Its just a nice selling point.

Now i am not an anti-Microsoft type, or anything like that. What i am is anti-bloat

I suggest you take a look at this article by Joel Spolsky. Though I'm not a fan of bloatware myself, having a huge infrustructure is one of the penalties of using a layered approach to software development, which I am a fan of.

A a general claim this is not true. It may be true when the layered design comes from using industry standard frameworks, that carry a lot of bagage. A layered architecutre can be lean and mean: You just have to using parameterization techniques (i.e., generic programming etc.) found in modern languages.

A layered architecutre can be lean and mean: You just have to using parameterization techniques (i.e., generic programming etc.) found in modern languages.

I was looking at it from a OS/components viewpoint rather than a language/library viewpoint. I'm not familiar with any component framework that uses generic programming (I'm guessing you'll give me some reference on LtU ;) The sizes of various frameworks have been discussed here in the past.

BTW, just because the infrustructure is huge doesn't meen that the app is bloated. A big OS is not by definition a bad thing. Having lots of features to choose from and ready made code is good, at least as long as you can find what you need.

Seems like a blog we should keep an eye on.