Marcello - looks interesting... how does it compare with PHP (as far as core functionality goes)?

Kent: it is in firefox 1.5+ with the <canvas> thing.

BAF: Depends how you look at it. It can load any java library, so technically its "core" functionality is quite broad. I haven't played enough with it to really say. I suppose it depends what functionality in PHP you use. All the standard stuff is there (get, post, cookies, sessions, email, image handling, ftp, file access, database access), and it uses OO rather than a c-style api.

As far as I can tell all or most of the core API is actually written in JavaScript itself, to give you an idea how versatile it is.

I haven't used it enough as of yet to give a full report, though.

edit: I think JavaScript on the server-side makes a lot of sense if you're going to be heavily using JavaScript on the client side, you can share code and modules (form validation, server/client based template engine, anyone?).

It's worth noting that Helma does provide a number of framework features for you off the bat, such as database abstraction (which I don't plan on using myself, since I'm using SQueaL as an alternative), template support, and a certain level of hiearchy control (which again I'm not using, thanks to SQueaL).

Marcello

What do you mean,

For the record, a number isn't an object in JavaScript either. It's a value, and gets passed by value, not by reference, as objects are.

I find the amount of syntax in a language is a good indicator of how good it is. More is not better. The fact that PHP has $ in front of every variable isn't a good thing, the fact that you can refer to variables in literal strings isn't a good thing. The fact that you have to use -> for class membership isn't a good thing. Hell, even c++ doesn't use -> unless it's a pointer (but shouldn't you be using references anyway?).

The array thing is what really started to bug me though, take, for example:

And my original code in PHP:

They both actually generate the exact same thing, and never mind on the generating part, but once you've created them, it's a hell of a lot easier to do xml.children[0].attributes.name than $xml->output['children'][0]['attributes']['name']

I also ported my SQL Schema class from PHP to JavaScript and it was just kind of a 'wow, what have I been missing' thing.

Marcello

I find it extremely helpful and it makes the code easier to write, and shorter. Certainly not a necessary feature though.
Just as I find having a string concat operator extremely helpful. I mean:
String(value_x) + String(value_y)
is just fine and dandy, but it's much simplier to write:
value_x . value_y

Ya know, it's things like that that make a language "fun" to use, as opposed to a bore/pain to use. On the string concat thing, if you didn't have that, you'd hit that age old problem of trying to concat two values and ending up adding them instead. Of course what one finds nice is entirely a personal thing, which I guess raises the question; could a language contain all the things 90% of people need? Or are we forever split between PHP/JS, C++/Java? It's kind of hard to say considering that nobody ever improves these languages like they improve other opensource applications.

Personally, I've been thinking about modding a new version of GCC, because I'm getting sick and tired of some things in C++. A static constructor or static class would be wonderful. Truth is, though, I'm scared of GCC! I have no idea how easy it would be to modify. And then of course nobody would be able to compile my code unless they had my version of GCC.
And I think that's the reason why a lot of languages suck. Nobody wants/can get in there and modify it to suit their tastes and therefore improve the language. Maybe not all mods get thrown into the official language, but at least languages would evolve faster.

I wasn't referring to JavaScript. I don't mind working with it at all. The problem with JS is that most people use it when having to deal with browser incompatibilities, so they stay clear away.

Well, you are using PHP4's dated XML handler. There are two better alternatives with SimpleXML and DOM. The latter is very similar to JS's, as it's based on the W3C standards.

The other direction is more common.

var x = document.getElementById('foo').value; // 42
var y = document.getElementById('bar').value; //  1
var z = x + y;
// z should be 43!
alert(z); // 421 :O

Of course you can avoid the problem with casting, but PHP has the edge here with the . operator. But, then it can no longer be used with objects.

Someone wrote a patch to optionally change . to _ and -> to . but it was rejected. I'm actually tempted to see if a "zend extension" shared object could do just that, because I use classes extensively now...

That along with the $this pointer are the two most fundamental annoyances with PHP. When PHP was less about classes, it wasn't a big deal. But it is annoying now.

Perl:

$x = $document->getElementById('foo')->value; // 42
$y = $document->getElementById('bar')->value; //  1
$z = $x + $y;
// z should be 43!
alert($z); // 43 :O

No inherent problem there, except if course some people's dislike for excess "operators".

If you love Java and want to get fancy, you could always use Echo. It's a Swing like GUI and the only GUI that I know of which runs mostly with JavaScripts, thus saving bandwidth. But it's mostly for web based applications, though.

What scares me about Perl is I find it impossible to read or understand anyone else's code. That's a bad sign right there. It's not exactly an accessible language.

Marcello

Actually, I would argue that it is the language's fault. There's too much syntax and too many 'unique' ways of doing things. While that's very fine and well for art or poetry, it's not so useful with coding.

The fact that 95% of Perl is impossible to read or understand tells me that the language is at fault.

Marcello