Lambda the Ultimate

inactiveTopic Programming for the Web
started 1/29/2002; 7:22:52 AM - last post 2/3/2002; 8:04:53 AM
Dan Moniz - Programming for the Web  blueArrow
1/29/2002; 7:22:52 AM (reads: 1519, responses: 21)
Having had to spend the last month or so hacking PHP (and not necessarily hating the language [yet], but certainly not enthralled with it either), I thought I might ask LtU readers what they think is the preferred language of choice for "web apps" (defined as "applications that operate via a web-based interface") and why, as well as to spur some conversation on to what each of us would like to see in a ideal programming language for the web.

Dan Shappir - Re: Programming for the Web  blueArrow
1/29/2002; 8:33:26 AM (reads: 1578, responses: 1)

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.

Ehud Lamm - Re: Programming for the Web  blueArrow
1/29/2002; 9:35:41 AM (reads: 1615, responses: 0)
The PLT guys have some nice support the server side web programming. Haven't had the chance to use it myself, but what I saw looked impressive. Using one of the JVM based Schemes, you can also do client side Scheme coding.

Ehud Lamm - Re: Programming for the Web  blueArrow
1/29/2002; 10:13:55 AM (reads: 1534, responses: 0)
The choice of programming language depends on many parameters, so it is hard to say anything clear cut.

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.

Ehud Lamm - Re: Programming for the Web  blueArrow
1/29/2002; 12:24:13 PM (reads: 1561, responses: 0)
I was thinking about your question a bit, and it seems to me it may be interesting to explore the various programming paradigms that mayu be involved when building web apps, since they influence the choice of language.

  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?

Dan Shappir - Re: Programming for the Web  blueArrow
1/30/2002; 4:11:47 AM (reads: 1526, responses: 0)

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

Chris Rathman - Re: Programming for the Web  blueArrow
1/30/2002; 7:02:38 AM (reads: 1510, responses: 0)
Server-side DOM (with server-side events)
If you had infinite bandwidth, this solution might be palatible. As it stands, though, every event generates a page request and a page redraw. In my apps, the costs of server side handling of events is too expensive.

Dan Moniz - Re: Programming for the Web  blueArrow
1/30/2002; 8:01:41 AM (reads: 1515, responses: 0)
I think it's interesting to consider the paradigm soup that Ehud mentioned.

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.

steve - Re: Programming for the Web  blueArrow
1/30/2002; 8:36:20 PM (reads: 1504, responses: 1)
One of the problems and pleasures i have always found with developing web apps, is the lack of state. While it is easy enough to create some kind of state/session management into your pages. It seems to me kind of ridiculous to have to create and destroy your object/data/page with each response from the server. The alternate being some kind of object/code persistance mechanism (FastCGI, Java Servlets, etc) to me seems like an inefficient use of resources, while still not truely solving the problem. On the other side, it is kind of nice knowing that your code needs only to flush its guts to std_out and then quietly destory itself. It makes programming less about interaction and the collection of data over time in a closed environment, and more like a game of catch with an invisble partner with the occasional cryptic message smeared and scrawled on the ball that you are never quite sure will come back.

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.

Dan Shappir - Re: Programming for the Web  blueArrow
1/31/2002; 3:08:51 AM (reads: 1499, responses: 0)
You may find this stuff interesting: MSDN Web Applications Technology Map

steve - Re: Programming for the Web  blueArrow
1/31/2002; 4:37:17 PM (reads: 1499, responses: 1)
Dan,

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.

Noel Welsh - Re: Programming for the Web  blueArrow
2/1/2002; 12:15:23 AM (reads: 1543, responses: 0)
I like the ball analogy to stateful programming on the web. One of the problems with web dev is that you never known if the person you're throwing the ball to will throw it back to the right place. The PLT web server is designed to get around this problem. The idea is that throws capture the current continuation and catchs resume it. In this way you always get back to the right place. If the user hammers the back button the catcher is an earlier continuation.

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

Ehud Lamm - Re: Programming for the Web  blueArrow
2/1/2002; 5:46:53 AM (reads: 1544, responses: 0)
Overall I tend to sgree with your sentiments, Steve.

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.

steve - Re: Programming for the Web  blueArrow
2/1/2002; 8:14:56 AM (reads: 1477, responses: 1)
Ehud,

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.

steve - Re: Programming for the Web  blueArrow
2/1/2002; 8:46:04 AM (reads: 1477, responses: 1)
Noel,

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.

Ehud Lamm - Re: Programming for the Web  blueArrow
2/1/2002; 1:21:53 PM (reads: 1529, responses: 0)
I think we have different models in mind. I am thinking about loosely coupled components, that may be written in different languages. Think about components.

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.

Ehud Lamm - Re: Programming for the Web  blueArrow
2/1/2002; 1:23:49 PM (reads: 1514, responses: 0)
Notice that the technique described in the papers enables the transformation from regular program to distributed state program to be done automatically.

steve - Re: Programming for the Web  blueArrow
2/2/2002; 8:37:59 AM (reads: 1459, responses: 0)
Ehud,

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.

Dan Shappir - Re: Programming for the Web  blueArrow
2/3/2002; 2:07:14 AM (reads: 1458, responses: 2)
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.

Ehud Lamm - Re: Programming for the Web  blueArrow
2/3/2002; 4:08:39 AM (reads: 1512, responses: 1)
having a huge infrustructure is one of the penalties of using a layered approach to software

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.

Dan Shappir - Re: Programming for the Web  blueArrow
2/3/2002; 6:53:29 AM (reads: 1554, responses: 0)
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.

Ehud Lamm - Re: Programming for the Web  blueArrow
2/3/2002; 8:04:53 AM (reads: 1426, responses: 0)
Iím responsible for ASP.NET Web Services, XML Serialization, and other random stuff within the .NET Framework SDK.

Seems like a blog we should keep an eye on.