Posted
by
timothy
on Wednesday April 13, 2011 @07:39AM
from the wait-until-it-includes-a-browser dept.

Minix writes "Tcl has announced the first scripting language to be supported by NaCl (Google's native client,) giving Tcl programs direct access to Chrome's DOM and marking the first such scripting language alternative to JavaScript. A demonstration of direct Tcl access to HTML5's Canvas is given. A variant of Tk for Native Client will soon follow. Web applications can right now be written completely in Tcl, as the original HTML specifications intended :)"

Maybe this is just a newcomer's view of the middleware level of open source, but it seemed a lot of the connecting functionality of that ecosystem has odd names - I can almost see some semi-intelligent script framework being called Sodium or something. So this update would be "Sodium Tetrachloride" - Na Tcl !

HTML standard itself has never required specific scripting language. That's why it's a requirement [w3.org] to specify the language used. That's why you also have monstrosities as VBScript used on the web.

Also, the same source already cites Tcl as a possible language, with even the corresponding content type. So it's a recognized possibility for some time. It only happens that nobody used it before google.

Last but not least, unlike VBScript, Tcl is not proprietary, is well documented and ha

What you say about the standard agnosticism is true, and indeed the HTML spec mentions Tcl as a scripting language.<quote><p>What will stop adoption is not the language itself. It's the fact that, for 99.9% people out there, Javascript is more than enough.Python would probably have a better chance of ever being used - and even it doesn't stand much a chance against the js establishment.</p></quote>

One of the first arguments in favour of scripting languages is that they were measured

However, the quality of a lot of the JS is fairly low, and it may just be that the need for frameworks is driven to some extent by the Javascript language itself, not merely the need to cope with IE.

The framework business (at least in jQuery's case) is more to try to work around the monstrosity known as the DOM; I dare anyone to say that the DOM isn't a total trainwreck of misdesign and a total pain in the ass to work with.

The problem with Javascript isn't a problem with Javascript at all, but instead of how it is perpetually perceived: a toy language that isn't capable of doing anything. Javascript is no less capable than Ruby or Python. Check out of all the cool things people do with Node; they are

The problem with javascript on the web is that a ton of it has been written that may or may not deal with specific browsers' broken DOM implementations. Since javascript spreads by copying and pasting random snippets from random websites and thus passing on these flawed lumps of cruft from generation to generation, it has developed into what is essentially a cargo cult: "Well, I saw Site X do this 10 years ago to bring the rain, so we must do this too!"

What will stop adoption is not the language itself. It's the fact that, for 99.9% people out there, Javascript is more than enough.

Captain Obvious speaking here.What will stop adoption is the fact that it is not available on 99.999% of currently installed browsers, like Javascript is.Unless all major browsers support it and the vast majority users have actually installed the versions of those browsers that support it, it doesn't stand a chance in hell.As for VBScript; I know no site that supports it.Possibly MS is using it to show how "superior" IE is because the other browsers "don't support scripting", but that's probably it.

Can someone comment on ANY technical advantages that Tcl would have over Javascript (ignore the licensing stuff). I do not know Javascript (I started learning Java, but stopped once Oracle consumed Sun), but as a part of my job I am forced to use Tcl for some stuff -- and I hate it. PERL is much more powerful and easy to use than Tcl is. Tcl also is not object-oriented (but there are "add-ons" that do this).

So, I guess that I don't get what the purpose is, other than maybe for those people who know Tcl a

TCL is very easy to extend with native code. I have done this extensively with TCL. V8 can also be extended, although with less ease; V8 provides an extension API that must be learned whereas anyone that understands int(*)(int,char**) can extend TCL.

The Javascript engines found in contemporary browsers are faster than TCL's canonical engine. The ongoing competition between browser vendors has led to amazing performance, and this is only getting better.

| Can someone comment on ANY technical advantages that Tcl would have over JavascriptGood question. I'll have a bash at answering this, but of course it's just personal prejudice really, and it's all arguable:

* Tcl has unicode built in from the ground up - makes a difference if you're not an English speaker.* Tcl is string based, all values are strings, it's very good at string manipulation.* Tcl is event driven from the ground up - good at networking and interaction. Coroutines in the core.* Tcl isn't lo

* Tcl has Safe Interpreters - as someone else noted - you can selectively hide, block or emulate commands in a cascade privilege model, so you can have a sandbox within a sandbox, if you want to. You could write a safe interpreter which executed third party code in a completely untrusted environment. That was a big feature of the Tcl Plugin for FF too. Very advanced security model.

For what it's worth, Mozilla supported using python in addition to JavaScript to write extensions for a number of years. No one actually used this functionality; it's now being removed to simplify the code.

So you're completely right about Python being used on the web: if it didn't even get used in an environment where you could assume support, the chicken/egg problem on the web is insuperable.

The example doesn't work. Also even if it did it would be "marking the first such scripting language alternative to JavaScript" only for people who want to restrict their website to Chrome users.

Which is a shame, especially as it is totally avoidable: It is possible to compile Tcl to JavaScript (using Emscripten [emscripten.org]), which would allow you to script the web using Tcl on any web browser and on any platform.

Disclaimer: I wrote Emscripten, sorry to pimp my own project. But if you are a Tcl hacker and want to compile it to JavaScript, please get in touch, I'd love to help.

And it wouldn't be the first. There are ways to run Python and Ruby on the client - in other-words type="text/ruby" can work if the client has it set up correctly. You need to interact with the DOM to do useful things on the page though. There's also the issue of security but it doesn't look like NaTcl has handled that either yet.

Not sure about that, do you remember the standard proposal of SQL on the browser that Chrome implemented? It was shutdown because the spec required to implement the SQL dialect of an specific version of SQLIte, so in reality one implementation will rule over all browsers and that is bad for a browser technology to be used on the web. If there is no specification and multiple implementations of NaCl I think it does not belongs to the web

I remember suggesting at a dev meeting about 10 years ago that we consider languages other than ECMAScript for our SVG renderer.
It didn't go over well.
I still think it's a good idea, W3C does not specify a scripting language. I want Python.
Visual BASIC would be good too, so MicroSoft can have its own scripting language for us all to hate, YAY!

Pyjamas provides a python-to-javascript Compiler and a Web Widget set, the combination of which allows developers to easily write well-designed desktop-like Rich Media Applications in python classes and modules that will execute in all major web browsers. without having to write a single line of javascript. Pyjamas is a port of Google Web Toolkit.

Yes, I looked at pyjamas. It's a fine idea for smaller projects, but I have big projects and I need to work closer to the bone. So, if the interface has to be JavaScript, I'll bite the bullet and use it.
Actually I'm finding that JavaScript is a very powerful language once you develop a discipline.
I'm on old hand c coder, I've moved to Python because I get so much done. If Python were a native browser script though, wow and holy cow, that would rock hard.

Why is everybody so excited about canvas? There are a lot of great features in html5, but why is canvas the trendy thing to showcase? I've seen lots of people make up toy examples with canvas when SVG would have been the better choice.

SVG rocks, but it has a barrier to entry. Even with InkScape, building an interactive app with SVG is not easy.
If you can get past that, you can kick serious ass.

Tcl has libraries to parse, manipulate, and generate SVG. http://wiki.tcl.tk/TclSVG [wiki.tcl.tk]
We find Tcl easier than Javscript to write such utilities in. YMMV, of course. Being able to bring those facilities to bear for web applications is part of the motivation for NaTcl, so there's no implied choice or preference for Canvas over SVG, just that we haven't had time to adapt and write SVG generators... now we have that opportunity.

TCL is a great language written by Ousterhout at Berkeley, but if I recall correctly, its primary purpose was for hardware CAD applications with respect to electrical engineering.

It is a staple scripting language for most of the entire VLSI toolchain, but how the heck is TCL a good language for the web? Methinks it would be better to write integrated Ruby support (or, shudder, Perl..)...

TCL is a general purpose, interpreted, programming language. It can be used for any kind of application but is particularly suitable for web applications and text processing, because it's string oriented. It's also great for integrating different libraries (via the simple C API), prototyping (interpreted, dynamic typing) and GUI programming (Tk library).

Well, I'm not exactly a fan of TCL, I admit. However I wonder why you say "it can be used for any kind of application". Ok, technically you can use it for anything, sure. However it hardly strikes me as particularly suitable for many tasks. It's slow and a line's syntax is not checked before it's executed, so you don't even have minimal formal checks. IMO that alone should exclude TCL from anything but small projects.

In John Ousterhout's own words: This is the proposition that you should use *two* languag

Well, I'm not exactly a fan of TCL, I admit. However I wonder why you say "it can be used for any kind of application". Ok, technically you can use it for anything, sure. However it hardly strikes me as particularly suitable for many tasks.

While it's true that you wouldn't want to write everything in it — heavy-duty math is far better in C or Fortran — there's a substantial ecosystem of extension modules ("packages") that provide lots of useful functionality. There's also a strong habit of engineering for robustness; Tclers assume (with good reason) that anything can be used with anything. Mixing high-quality XML handling with high-quality database access with high-quality threading with high-quality asynchronous I/O? Sure. Not ev

Tcl was originally conceived as a glue language, that is, a scripting language featuring extensibility via a separate implementation language. For example, Tcl has a package called TLS which adds SSL/TLS capability to the standard socket operations using OpenSSL. With minimal code changes and rapid deployability, your plaintext connection can run over SSL/TLS.

What's especially good about the Tcl approach is that it doesn't reinvent the wheel. The OpenSSL libraries are there already. It's just a matte

Ioke and forth might be of interest to you, then. But please respect the wolf in sheeps clothes (replace with lisp and C where appropriate), because no other language like it exists on the mass market - don't look at the shackles called DOM. Try a nicer runtime env - like Qt bindings, or Node.js.

I love Tcl, but it's nothing like what Java is or should be. The Tcl syntax is vaguely reminiscent of SmallTalk (Java's true father), but it's actually simpler and far less powerful. Even with OO support from something like [incr Tcl] it's quite painful writing large applications in Tcl. Where it excels is as a glue language for code that relies on existing libraries written in C as the extension API is simple and elegant (something that can't be said of Perl's for example).

GC's awkward because of some nasty complex interactions. I think I know how to do it (I have some experimental code) but it's currently so incredibly limited that I suggest you don't want to try that particular code branch. (Crashes a lot too. It's truly not yet ready for even experimental use.)

All security arguments aside, it seems that we may be going from an architecture-independent web to an architecture-dependent one. Sad. Maybe the mid-2000s will seem like a golden age of openness in the future. Platform-independent web applications were the hot new thing, the iPhone hadn't come out so open mobile devices still existed, anybody who suggested running native code from websites, or producing a locked-down device would have been laughed out of the room...ah the good ol' days...

Er...ActiveX [wikipedia.org] was introduced in 1996 and continues to be used (though thankfully much less now). That's pretty much the quintessential example of an architecture-dependent web application.

You can run x86 code on any machine in a virtual machine... in that respect this effort may still be considered architecture-independent. Also, you can re-compile x86 code to any other architecture, of course (but that is what an efficient virtual machine would actually do, I suppose).

But that's what SCRIPTING LANGUAGES ARE FOR. By using emulation you've come full-circle, giving the poor performance of a scripting language with the non-portability and inconvenience of a native binary. The worst of both worlds.

It's not worth exposing a computer's CPU microcode vulnerabilities to the web for this.

Virtual machines have come a long way and do not give a big performance penalty. Internally, a virtual machine can recompile machine instructions (just like a compiler "recompiles" its intermediate language into final code).

The power of this lies in the fact that you can now use *any* language you like. This is really necessary, as web applications are becoming bigger and bigger, and need a more sophisticated language than javascript (for example, javascript lacks even basic type checking).

Then why not invent a more advanced scripting language instead of setting up this silly Rube Goldberg machine to get a little speed boost? And remember that when you emulate x86 code on something else, you lose the x86 CPU features that accelerate x86 virtualization. It's not going to be so fast.

You mean implement a new language beside javascript? Do you have any idea how many people/research groups are working on new languages every day? Many problem-domains requires different types of language.

Let's just give them all a chance to do something useful on the web.

And besides, it is not mandatory to use NaCl in your browser. You could just develop for javascript if you prefer.

I think the GPP meant some sort of language and platform independent bytecode and VM, like parrot, and then, if they so wish, every webstie could have their own language - it runs in the same vm. Though the way things are going, a defined JS subset might just do the trick.

Internally, a virtual machine can recompile machine instructions (just like a compiler "recompiles" its intermediate language into final code).

Unless the virtual machine is running on a platform with especially strong W^X [wikipedia.org], such as Apple iOS. This is why JavaScript in a UIWebView is so slow on iOS, even though Safari got faster on iOS 4.3: UIWebView doesn't have the special privileges to transform a writable page into an executable page that Safari has.

Tcl 8.6 has coroutines, which are also tremendously useful for interactive (and networking) programs. They function as green threads, very lightweight and fast.
Closures will come, but they're not so important when you have coroutines.

Are those full coroutines, or gimped ones like in CPython? I ask because Tcl 8.6 (like Lua, where I believe we pinched some implementation concepts from in this area) uses a non-recursive execution engine under the covers so that code doesn't have to know that it's running inside a coroutine context (i.e., if a procedure is running inside a coroutine context, the sub-procedures it calls can yield without the outer procedure having to know anything about it). This contrasts with coroutines as implemented in

You can run x86 code on any machine in a virtual machine... in that respect this effort may still be considered architecture-independent.

But that's what SCRIPTING LANGUAGES ARE FOR.

If I have an existing library of code written in standard C++, how do I automatically translate it into a scripting language for use on the web? Manual translation by an intern is unacceptable because if I check in a change to the standard C++ version, I want the web version to be updated as well. In addition, most scripting languages (such as Perl, Python, and JavaScript) use dynamic typing exclusively, and as I understand it, there are limits on the optimization that can be applied to native code recompil

There are limits, yes - but nothing some brute forcing with a genetic algorithm can't fix, reasonably. The issue with C++ is that it has a weak type system, more specifically, weak pointer types, that make it impossible to formally reason about it's execution, in a reasonable manner. Now, if you work in C++/CLI, writing a compiler to JavaScript would be a peace of cake.

All security arguments aside, it seems that we may be going from an architecture-independent web to an architecture-dependent one. Sad. Maybe the mid-2000s will seem like a golden age of openness in the future. Platform-independent web applications were the hot new thing, the iPhone hadn't come out so open mobile devices still existed, anybody who suggested running native code from websites, or producing a locked-down device would have been laughed out of the room...ah the good ol' days...

What does the iPhone have to do with it. If anything it promoted web applications for mobile devices by providing a full featured browser on a mobile device. In fact Apple has been quite clear they prefer web apps to be based on independent standards, excluding plugins such as Flash which run only on some systems. If you want native on iPhone you have to go through the SDK, hell will freeze over before Apple will allow native code to run from websites.

What does the iPhone have to do with it. If anything it promoted web applications for mobile devices by providing a full featured browser on a mobile device.

LOLWUT? The iPhone started the migration from web applications to client apps - their rejection of Flash actually played a large part in that - it would be ironic, except that was actually their intent.

The iPhone started the migration from web applications to client apps - their rejection of Flash actually played a large part in that - it would be ironic, except that was actually their intent.

You might remember the original iPhone was webapp only and there was a big kerfuffle about it: "No iPhone SDK Means No iPhone Killer Apps [slashdot.org]". It was marketed as "The internet in your pocket" [informationweek.com]. They did eventually release an SDK of course but even now they do not do what the OP accuses them of, namely mixing the two. They've always cleanly separated web and native, keeping the web part as based on common, universal standards as they keep the native part closed. If there has been a migration from web to na

"The real answer is about security. Perhaps the biggest reason for Nitro’s performance improvements over WebKit’s previous JavaScript engine is the use of a JIT — “Just-In-Time” compilation. A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does n

I was aware of everything you just mentioned. It's just that Apple could have made a new version of UIWebView that runs each web page in a separate Safari process in much the same way that Google Chrome for PC does. If this is corrected in iOS 4.4, then fine. But if not, it smacks of intentionally hampering web apps and other UIWebView apps in favor of native apps from the App Store.

iOS 4.3 was released as the iPad 2 came out so they were probably working towards a fixed release date with stuff that wasn't ready simply being delayed to the next release. I don't think stymieing webapps is in Apple's best interest as their best excuse for retaining full control over the content of native apps is that people can simply create a webapp with no such restrictions.

How is it different? You're still downloading code. There's already architecture dependence in practice (though it's on the Javascript pseudo-architecture). People have been turning up the heat on the frog for years. And yet, the web itself doesn't care. It's just your lame-ass browsers and lame-ass website designers that care.

If you download the LibreOffice.msi, that's not part of using the webpage. You're just downloading a file that happens to be software - it could have been an MP3 or or a Word 2007 document, that doesn't make the MP3 codec or MSXML part of using the webpage either. If Gmail replaces AJAX with this native stuff, that is part of using the webpage. That's how it's different.

Actually this would not be as bad as you think. By writing your web app in something like TCL and having that executing on NaCL, your code runs on anything NaCL does.

If Google decides not to be a dick and Mozilla adopted NaCL and they both provided a NaCL for each architecture they supply a browser on, it wouldn't be so bad. Just means you gotta cross-compile your native web app code (or TCL interpreter) for x86, ARM and maybe if you feel real nice MIPS and PowerPC to catch a lot of weird embedded devices

The JavaScript interpreter in iPad's UIWebView is ridiculously slow compared to a native app because it is in fact an interpreter as opposed to JIT recompilation. Any web site bookmarked on the home screen will use UIWebView instead of Safari. The strong W^X policy of iOS, which the system applies to everything but Safari 4.3, appears designed to discourage such "platform-independent web applications" in favor of native applications distributed through the App Store.

But it would be so much cooler if also the rendering engine could be implemented natively, with perhaps only the graphics part handled through some standard API like OpenGL. Web developers could then just link-in their favorite rendering engine, e.g., webkit or gecko, without being dependent on broken web standards.

Uh...the GUI builder is called HTML and the Tk library is called the DOM. Did you only ready the Tcl part of the headline?

Not quite. We have a Tk front-end which generates HTML and CSS sufficient to present a very nice GUI in browser-native look and feel.
At the moment, it runs on the server. We will be porting it to NaTcl next.
In my experience, it's much simpler and neater than DOM and HTML.

I was a big fan of the TCL plugin back then because it had greater capability (file access, rick user interface with the TK widgets available), but done with a mind to security given the Safe TCL work that had been done to run in a sandboxed environment. In terms of user interface, the plugin in 1997 was where javascript UI libraries and HTML5 are now. I always thought it was a shame that Javascript/Java was pushed into the browser, when t

Ditto. You can run Ruby in the browser though, just set script type="text/ruby" to be parsed by your native Ruby parser and you're off.... if you can find a way to efficiently interact with the DOM/page...

2. It's practical. Really. (We have full production webservers written in Tcl 8.6. We know from the logs that they get pretty heavily hammered by dumbass hackers wondering whether we use phpMyAdmin behind the scenes. Heh heh.)

The NaTcl balls demo runs here at 40fps, as fast as the original JS version, and respectable.

So, the point of using another scripting language is that you might prefer it to JS. You might find Tcl faster and better to develop in than JS. It seems to me to give you that choice, which otherwise you did not have.

Not when IE, Safari, Firefox, Opera, Mobile Safari, and Android's browser don't support the NaCl required for NaTcl. Firefox has explicitly rejected NaCl [dzone.com], and Apple would likely reject it as an end run around the App Store. And not when members of your site's audience on corporate computers have NaCl turned off for the same reason they have ActiveX turned off. For them, it'd be like turning JavaScript off, which makes a lot of web applications nearly unusable.

Tcl generally lacks a lot of OOP features that might make it more supportable,

Technically, it lacked a blessed one. There are several available as after-market extension modules. But in 8.6, there's a standard one (I wrote it; it's faster than the others and as dynamic as Tcl itself).

but one thing in its favor - it has a very regular syntax. Parsers for Tcl will be easy to write, FWIW.

Funnily enough, that's both true and false. Basic parsers are indeed ridiculously simple. Full parsers (i.e., ones that can extract similar levels of information to what you'd get from many other languages EBNF definitions) are much more complex because Tcl is actually not a context-free language. (I'm a