So, here's the thing. If you go into working with JavaScript thinking "wow, it will be like Java, only scripty" you are in for a world of disappointment. I think this is the reason people's immediate reaction to the comment "I'm learning JavaScript" is to shake their head sadly and respond with "I'm sorry. Broken language."
This is a mistake. First off, I know broken languages. Hell, I've invented one. JavaScript, has its problems, but the largest one is due to the rocket scientists who decided to name it, well, JavaScript. It was, of course, originally known as LiveScript, but for marketing reasons the name was changed.
And hilarity ensued.
Instead, try this mental shift: think of the language as cScript. You know, c, only scripty. I know, you're thinking this is crazy, but work with me for a moment.
The syntax is very c-like, down to the ?: ternary operator, braces, and naming conventions. Now, unlike c, it isn't typed, but that's what makes it scripty. Plus, everything we do to work around c's typed nature -- void *, memcpy, function pointers, etc - just causes memory leaks, architecture dependence, and pain, so isn't it nice to have a language that does that for you? Even the method of extending JavaScript objects -- by creating functions and adding parameters in -- looks a lot like what happens when you apply OOP principles to c.
Now, it is dog slow -- hello, why the hell isn't it JIT-ed? -- and shows quirks from having evolved amidst the browser wars. But with the canvas tag and other sexiness looming on the horizon -- not to mention the uber-fast ActionScript engine in Flash -- I'm having a blast. This weekend I get to start working on my first test app, which will be fun.
For JavaScript, I worked through O'Reilly's "Learning JavaScript." The reviews are correct -- there are a lot of typos -- but thanks to Firebug I turned most of those into learning experiences. I also am most of the way through "Learning PHP and MySQL." Same problem -- lots of typos -- but I thought it did a pretty good job of filling in gaps. However, in comparing how it used PHP to the "Head Rush Ajax," I thought the Head Rush book's approach of writing simple HTML, using AJAX to fill in the dynamic data, and applying PHP as the server language to generate JSON and XML data fits my brain better than the Learning PHP book, which is all about using PHP to generate HTML directly. That way seemed really awkward, required Smarty templates, and just looked like a lot of work.
Current plan of record, for those following at home, is to do first pass of test app in PHP, then recreate it in Rails. I figure the compare and contrast should be enjoyable.
Thursday, January 17, 2008
"JavaScript".replace(/Java/, "c");
Subscribe to:
Post Comments (Atom)
5 comments:
Actually your language "LSL", in spite of some issues, is essentially brilliant. Excluding some unusual twists to Simula 67, it is the best, most practical finite state machine language I have used. More importantly the insight you had in choosing a FSM architecture with concurrently executing scripts linked by object based messaging is simply a stroke of genius. I agree that the course of time in SL has revealed a number of weaknesses in the language, including the cumbersomeness of messaging, lack of conventional arrays, weak string handling, cumbersome list management, lack of a case/switch statement, inconsistency inter-object/inter-script messaging design, restriction to call by value evaluation in parameter parsing, lack of interupts and a few other issues...but the number of fundamental ideas you got right for an agent based environment overrides these weaknesses - including the fact that you thought to use states in the first place. The real problem is that very few scripters understand how to programme in it properly.
Yet, there are an amazing range of diverse and effective applications written in it. Considering the quality/training of most SL scripters, this fact alone is a testament to the language.
What I would like to see is you revisit LSL, preserving what is right and rethinking what is wrong, to create the "ideal" virtual world / MMOG language.
Describing it as "broken", is I think, unfair. It is a brilliant first draft (even second or third draft).
Now JavaScript, that is a different story. I admit to a holding a soft spot for JS, but it is a language that begs bugs, and inefficient code design - like most web/html languages. It has some wonderful features, but is essentially verbose, and the confusion between object and function definition in a language is unforgivable.
As a computer scientist, it is a constant point of embarrasment to me that in a profession that by the 80's had established a very strong foundation in language design and provability for efficient, low bug coding with prime examples of Pascal, Modula, Simula, Lisp, C++, Sequel/Predicat Calculus and Eifel - the languages most of the world ended up programming in as the high point of our art is the abortion of the CSS + DHTML + JS and Java. Examples of practically everything one could do wrong in langauage design. Even Basic has more to commend it than that retarded mess.
Your language, inspite of its faults fits the need of it's environment, and more importantly shows a fundamental, irreplaceable insight into what is needed for effective control of agent environments.
I admire the Netscape people for choosing a prototype language. It just took 10 years for the world to learn how to use it correctly. Today I really wonder why we (me included) programmed such a crappy JS style for years, when everything was already there, just because we did not understand it. On the other hand, despite its beauty, it may be a mistake to design a language such that the world needs an eon to grok it. Slow interpreters mean only that no one put a billion $ into it, as they did for Java and C#. JS could be JITed as well.
I am a fan of PHP and I hate it. I am using PHP for large projects an I love its deterministic nature. Even on 100 web servers with memcache and mysql I understand completely what happens. A Java app server of this size produces more surprises.
The funny thing with Smarty templates is that everyone uses them, although they do not need them. Yes, you need a template engine. Separation of code and design, etc., but PHP IS A TEMPLATE ENGINE. Before you start learning Smarty-script, give this a try: http://phpsavant.com/yawiki/. Savant engine is not another template engine. It is just a wrapper for PHP's native template engine. You can easily build your own engine in a few hours, but the Savant wiki explains it well. Smarty is only useful in the rare case that you do not trust your template writers. If you are the template writer, then you better use PHP as template script rather than learn another, that will be "compiled" into PHP. Speed: Smarty caching ends where PHP starts. That said, my C++ programmer heart cries comparing PHP/Apache/Linux to a C++ server. PHP speed ends where Java/C# start and they both end where C/C++ start.
There were lots of rumours about a super fast JavaScript engine at ooPSLA and also about running JavaScript on the CLR, so the JavaScript speed issue is likely to go away soon.
It's interesting that in the short term concurrency seems likely to be dealt with using similar techniques to backbone and the uthread injector.
I agree that while LSL isn't a great language it is a great runtime environment and we'll soon see how that environment plus mainstream languages work out in SL.
if i remember correctly, javascript is decended from "self", which among others sired "newtonscript".
so, not a shabby foundation. not at all.
Cory, while you are teaching yourself JavaScript you might want to take a look at DOMApi, which is a javascript "advanced" cross browser DOM / Ajax implementation/wrapper thingy. You kind of have to look at the examples and read the tutorial to understand why you even want to know about it, but once you do, you will think, I believe, it is was 15 minutes well spent.
The introduction and 'about' parts of the site are kind of under-welming; leaving you with more questions than answers. Once you look at the tutorial however, it will rapidly become clear what the thing is doing and why it is so incredibly useful.
Website:
http://www.domapi.com/
(..And before anyone asks: No, I have absolutely no affiliation with them).
Post a Comment