Lambda the Ultimate

A decent native (W32) compiler would be nice - maybe they exist now, but when I tried some out a while back, they were too flakey and/or didn't support the GUI/latest language version.

Boooooring.

Well, actually, it's not always boring. I've had a lot of fun co-writing a side project in Python, a project that has absolutely nothing to do with money. But now that the back-end is as good as it needs to be the thought of working on it is... you guessed it... boring.

There are some client-side programs I've been meaning to write, mostly for my own personal use. I'd like to write them in Python (current language of choice) but up until a week ago I didn't know any good widget libraries.

Then I found wxPython. Pretty slick, and it even wraps up the rich controls that TK doesn't come anywhere near. I mean really, all my projects require tree controls, and the only tree controls I've found for TK crash.

If I had to write my client-side stuff in C++ (maybe with MFC?) or even Java it would have blahed me to tears by now.

What interesting client side programming tasks are you fond of?

The part about Swing being too slow for "Internet" clients--areyou talking about what I call "Web" clients (browsers), or ... well,I'm confused. I quite agree that Swing is heavy, too much so formost of what I do. I don't get the connection to networking you'remaking, though.

My emotional response to this topic is that the current client-sideWIMP is good enough. I don't see a model for user-machine interactionthat I think will be more successful. Flash, for example, is exciting,but only to people who already understand it. I think in terms of end userswho are largely afraid to push the wrong button.

It involves talking to the server (probably through some XML-RPC, an excuse to play with it), and present a simple UI.

Sure I can always check the site through the browser, but it's just more fun to have this dinky little notifier that pops up a list.

A big part of it all is that I'm tired of rendering everything into HTML, and having to come up with page-click-page interactions for everything.

This is, of course, not a programming language issue. But I agree that this is a bad paradigm, both for users and for programmers.

I have kicked around ideas for an open "server controled GUI language" or semi-language where GUI definitions are sent to the client, but the logic is on the server. IOW, *no* IF or WHILE loops, etc. on the client side. Putting an exucutable language on the client opens up all kinds of worm-cans.

It would basically be commands to display and undisplay widgets and send their content when asked.

Existing stuff seems to want to send every fricken keystroke back-and-forth. I would rather see smarter widgets on the client side that only send stuff when explicitly asked to, or told to ahead of time, IOW, a syncronous and asynchronous mode.

However, based on the discussion, I will have to produce a prototype before anybody takes the idea seriously.

That way we can get back to regular GUI's and IDE's for web stuff and forget about HTML forms.

I went to an MS developer conference a while back and one of the tools they demoed sounded very much like what people here are asking for. It supported web desing using high-level components which were implemented by the underlying system in a manner appropriate for the client. This included automatic handling of state. So, for example, you could define instantiate a form method with constraints, and call a method something like "interact with user" and the read the form values back from the method. The underlying system would generate pages in HTML, do verification using Javascript or post or whatever most suitable for the client, etc.

Cleints included HTML (different browsers, support for Javascript or not etc) and XML (WAP?).

Can't remember the name of the product.