Slashdot Mirror
Tcl Announces NaTcl: Native Client Tcl
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 !
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
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.
I'm not a fan of IE, but WSH let you use other language in html pages like perlscript since a long time.
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!
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.
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 actually had the first in-browser applets, before Java. You can still get a mozilla plugin that I think works in firefox.
I am trolling
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...
"When information is power, privacy is freedom" - Jah-Wren Ryel
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.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Yeah, Chrome attempts to bring ActiveX back!
I just wonder when will M$ get consumed by Google and they turn "evil".
Tcl is nice I used it on a standalone barcode scanner. But for it to shine it needs the Tk library and a GUI builder like vtk. Then half the application, the visual part, is nearly written for you.
I <3 Tcl/Tk
Comment removed based on user account deletion
I thought the point of NaCl was to have fast, compiled, architecture dependent code running on the host machine.
If you use another scripting language to generate this code, then how is that any different than JavaScript JIT? Using a scripting language sort of defeats the purpose. The original point was to run, basically C/C++ code, because of the speed enhancements. We already HAVE a scripting language.
only for people who want to restrict their website to Chrome users.
Well, uh, not necessarily.
HTML standard itself has never required specific scripting language. That's why it's a requirement 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 has an opensource implementation and no known patent limitation, so it's freely usable by anyone. Thus if this thing catches on, it could be used by most browsers (except maybe by Microsoft Internet Explorer which, as usual, would probably lag behind in implementing open standards).
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Tcl generally lacks a lot of OOP features that might make it more supportable, but one thing in its favor - it has a very regular syntax. Parsers for Tcl will be easy to write, FWIW.
I miss doing web work with Tcl, but I don't want to support yet another does-this-client-support-this testing and special casing nightmare.
is competition good, or is duplication of effort bad?
Saltty!
Tcl 8.6 has full native OO.
"There are four boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order." Ed Howdershelt
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, 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.
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 recompiled from a language that lacks static type hints.
In fact Apple has been quite clear they prefer web apps to be based on independent standards
Then why do bookmarked web sites on iOS run in UIWebView, whose interpretive JavaScript engine is several times slower than the JIT JavaScript engine introduced in Mobile Safari 4.3?
It's a good thing.
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, 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.
This is familiar to the TCL plugin for Netscape way back in the '90s.
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 they could have gone with this instead.
One of the original ideas behind TCL/TK by Ousterhout was the concept of "active data". One of his early examples was a coded email message that was interactive while you were reading it. Unregulated, the concept is a security nightmare, but the Safe TCL work was ahead of its time in pushing the idea that active data required security (this was before the MS Macro viruses).
All that said, I think it might be too little too late with regards to the native client. Might be good for niche applications, but the strength of the browser is good cross platform applications without having to do anything.
I thought that one of the samples included with NaCl was a Lua interpreter, meaning that TCL is far from being first.
... April 1st was almost two weeks ago.
I'll be really impressed when they embed a pure functional language like Haskell, and make it interoperate with the DOM.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
For that matter, what does iPad matter?
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.
Python would be much better suited for browser scripting. Its string-based also, and would wrap DOM like a womb.
The XTHML documentation (I think?) was full of references to scripts in Ruby (instead of JavaScript). Whatever happened to that?
Media that can be recorded and distributed can be recorded and distributed.
-kfg
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 little hazy as to whether it is a context-sensitive language or recursively enumerable, though I suspect the latter.) The simplest possible practical full Tcl parser is a Tcl interpreter, though the language is compilable under some simplifying assumptions (e.g., no runtime redefinition of syntax; addition of new syntax – a fairly common habit of Tcl programmers – is much simpler by comparison).
"Little does he know, but there is no 'I' in 'Idiot'!"
This is never going to work for one reason: ARM. There are tens of millions (if not hundreds of millions worldwide) of ARM devices on the Web today. The only chance that x86 bytecode had on the web was that window between Macs going x86 and smartphones appearing in great numbers. Besides, what binary format will it be in? Windows PE? Linux ELF/ELF64? OSX Mach-O? Flat DOS COM binaries? This is worse than Java.
In closing:
Yo dawg, we heard you like interpreted languages so we put your bytecode in the wrong format so you can interpret while you interpret.
1. It's Turing complete. 2. Umm...