Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Tcl Announces NaTcl: Native Client Tcl

timothy posted more than 3 years ago | from the wait-until-it-includes-a-browser dept.

Chrome 124

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 :)"

cancel ×

124 comments

Sorry! There are no comments related to the filter you selected.

Na Tcl (1)

TaoPhoenix (980487) | more than 3 years ago | (#35806338)

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 !

The example doesn't work (1)

Chrisq (894406) | more than 3 years ago | (#35806354)

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.

Re:The example doesn't work (1)

Minix (15971) | more than 3 years ago | (#35806382)

Yeah it does. There are a few things you need to do on chrome invocation, detailed in the wiki page.

Re:The example doesn't work (0)

Anonymous Coward | more than 3 years ago | (#35806564)

Link please...

Re:The example doesn't work (0)

Anonymous Coward | more than 3 years ago | (#35806676)

I didn't read TFA but I can guess what it does say: go to about:flags and enable Native Client.

Re:The example doesn't work (1)

Minix (15971) | more than 3 years ago | (#35806732)

http://wiki.tcl.tk/NaTcl

Excerpt:

Try it out :

Get chrome (we use 10.0.648.204)

Kill all currently running chrome instances.

chrome, google-chrome --no-sandbox
      on OSX use /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --no-sandbox

navigate to about:flags and enable native client, save it.
      on OSX (at least) you will need to restart Chrome after enabling native client

Try http://wiki.tcl.tk/_natcl/balls.html

Problems?

If you get missing so file error on the console, it's a know issue with chrome rpms and debs not including the NaTcl plugin. http://code.google.com/p/nativeclient/issues/detail?id=1416

Can you run these non-tcl demos? http://code.google.com/chrome/nativeclient/docs/examples.html ... if not, there's something wrong with your chrome installation.

Re:The example doesn't work (1)

Chrisq (894406) | more than 3 years ago | (#35806916)

Can you run these non-tcl demos? http://code.google.com/chrome/nativeclient/docs/examples.html [google.com] ... if not, there's something wrong with your chrome installation.

There's something wrong with my chrome installation then (or more likely my company's firewall is blocking some essential component)

Re:The example doesn't work (1)

Minix (15971) | more than 3 years ago | (#35807048)

That's possible - the browser has to be able to download the .nexe (executable) from the server. A corporate firewall could presumably object to that.

Re:The example doesn't work (0)

Anonymous Coward | more than 3 years ago | (#35807434)

As a non-programmer I'm not sure why programmers feel so threatened by a new TCL. I loved playing with TCL on my IRC Bots, it's such an easy to understand language.

It's almost like programmers want to be restricted to their self-walled garden of prestige. Sorry, you aren't special, we can all learn to use tools that aren't 4GLs.

Re:The example doesn't work (0)

Anonymous Coward | more than 3 years ago | (#35806612)

NaCl is nearly guaranteed to be supported on Firefox and maybe Opera in the future (i.e. 1+ years). IE and Safari... not by Apple or MS.

Re:The example doesn't work (1)

robmv (855035) | more than 3 years ago | (#35806998)

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

Half standard (2)

DrYak (748999) | more than 3 years ago | (#35806850)

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 [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 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.

Re:Half standard (2)

Minix (15971) | more than 3 years ago | (#35806960)

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 to be five times faster to develop in than C.

It may be that JavaScript has inherited some of those impediments to code writing from C.

You state, quite correctly, that there are a lot of JavaScript fragments out there, and an 'establishment' of frameworks.

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.

I think this experiment in alternatives to javascript may yield very interesting results. We have found, for example, that Tk is a very good language and framework for laying out Web GUIs.

Re:Half standard (1)

zoips (576749) | more than 3 years ago | (#35809166)

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 an excellent example of what can be done if you actually have a good runtime environment that isn't married to a browser (Spidermonkey was never a very good environment on its own, and Rhino was a basically a never-was despite having promise).

Re:Half standard (1)

mwvdlee (775178) | more than 3 years ago | (#35807220)

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.

Re:Half standard (1)

harrkev (623093) | more than 3 years ago | (#35808722)

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 and do not want to learn Javascript.

Re:Half standard (1)

Anonymous Coward | more than 3 years ago | (#35809402)

No, I can't. I am experienced in both.

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.

TCL folks claim TCL's syntax is more regular and easier to learn than other languages. While it is nice, I'm not sure TCL really has anything on Javascript; Javascript has the usual collection of infix operators and other syntactic conveniences that TCL hides in various commands (i.e. expr, binary, regsub, etc.) I doubt the net amount of actual syntax that must be understood is actually less. JSON demonstrates the power of unadorned Javascript syntax and has more parsers written in more languages than TCL has ever had.

TCL interfaces with the system (file system, IPC, etc.) easily and has excellent documentation for it's standard library. The Javascript system interfaces is.... well, whatever.

You ask a good question. I don't think there is a strong technical argument for TCL over Javascript. I really don't understand your hate of TCL, however; there is nothing about TCL so offensive as to be worthy of hate. I use Perl when I'm in foreign environments due to its ubiquity; I spend just as much time crawling man pages figuring out Perl syntax and standard library as I must with TCL to learn commands.

Re:Half standard (1)

BZ (40346) | more than 3 years ago | (#35807670)

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.

Re:The example doesn't work (1)

kripkenstein (913150) | more than 3 years ago | (#35810178)

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.

WSH - perlscript (0)

Anonymous Coward | more than 3 years ago | (#35806378)

I'm not a fan of IE, but WSH let you use other language in html pages like perlscript since a long time.

Re:WSH - perlscript (0)

Anonymous Coward | more than 3 years ago | (#35806454)

http://docs.activestate.com/activeperl/5.10/Components/Windows/PerlScript.html

Between this and SPDY Google is the new EVIL (-1)

Anonymous Coward | more than 3 years ago | (#35806380)

Notice how they're promising SPDY sourcecode for the server-side only?

TCL is a horrid clusterfuck to work with and will never be supported in anything else. Whats next, SNOBOL? Give me a break.

A whole new breed of sites that only work on the crappiest browser available for windows. FANTASTIC.

Reminds me of something. What was that?

Oh yeah... IE6.

Re:Between this and SPDY Google is the new EVIL (1)

Darth Snowshoe (1434515) | more than 3 years ago | (#35807224)

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.

Re:Between this and SPDY Google is the new EVIL (1)

Minix (15971) | more than 3 years ago | (#35807382)

Tcl 8.6 has full native OO.

Re:Between this and SPDY Google is the new EVIL (1)

dkf (304284) | more than 3 years ago | (#35811472)

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).

Bring on Python! (1)

Tsingi (870990) | more than 3 years ago | (#35806388)

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!

Re:Bring on Python! (0)

Anonymous Coward | more than 3 years ago | (#35806424)

At one point I thought there was a project for python and dom in Mozilla but I don't think it got very far.

Re:Bring on Python! (0)

Anonymous Coward | more than 3 years ago | (#35808470)

That would be PyDOM [mozilla.org] / PyXPCOM. It got far enough to work, at which point it died because there was no way Mozilla was going to help distribute it or market it. The underlying work to make it possible has been removed recently.

Re:Bring on Python! (1)

Terrasque (796014) | more than 3 years ago | (#35806896)

Well.. Next best thing :

http://code.google.com/p/pyjamas/ [google.com]

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.

Re:Bring on Python! (0)

Anonymous Coward | more than 3 years ago | (#35807148)

Just because I'm lazy and am running out the door, do you know of Pyjamas has the same irritating problem GWT did of creating up to 4 different files of unnecessarily inflated size, then requiring a small bootstrapper to load the appropriate file after the page load? I love the concept of GWT, but I found that to be unacceptable. When a simple "alert" call gets boosted to 15kb, 4 different ways, and requires a loader, I have to question if the efficiency gains actually exist...

I'm genuinely interested to know. I like Python and would much rather write things in it than in JS, but I'm a bit wary of GWT because of my past experience with it.

Re:Bring on Python! (0)

BlitzTech (1386589) | more than 3 years ago | (#35807168)

Whoops, that was me not realizing I wasn't logged in. Not intentionally posting AC!

Re:Bring on Python! (0)

Anonymous Coward | more than 3 years ago | (#35811138)

Whoops, that was me not realizing I wasn't logged in. Not intentionally posting AC!

Seriously, who fucking cares?

What is with all of you idiots posting a bunch of "oops, I wasn't logged in", do you think we're going to mod you up for it?

Is this some new stupid slashdot meme, or are you guys just all become stupid?

Re:Bring on Python! (1)

Tsingi (870990) | more than 3 years ago | (#35807334)

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.

I don't understand the obsession with canvas (0)

Anonymous Coward | more than 3 years ago | (#35806400)

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.

Re:I don't understand the obsession with canvas (1)

kestasjk (933987) | more than 3 years ago | (#35806500)

I guess because it's so easy to get started with, and there is stuff you can't do with SVG that you can with Canvas (like Mario, or this [kuliukas.com] )

Re:I don't understand the obsession with canvas (1)

Tsingi (870990) | more than 3 years ago | (#35806716)

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.

Re:I don't understand the obsession with canvas (1)

Minix (15971) | more than 3 years ago | (#35808460)

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.

Why was TCL originally chosen for HTML? (1)

snotclot (836055) | more than 3 years ago | (#35806404)

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..) ...

Re:Why was TCL originally chosen for HTML? (0)

Anonymous Coward | more than 3 years ago | (#35806606)

It wasn't.

Re:Why was TCL originally chosen for HTML? (1)

kwikrick (755625) | more than 3 years ago | (#35806618)

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).

Re:Why was TCL originally chosen for HTML? (1)

Asic Eng (193332) | more than 3 years ago | (#35807888)

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* languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions.

That seems reasonable to me, and would fit to the concept of a scripting language. But maybe TCL has moved on by now and my opinion is out of date?

Re:Why was TCL originally chosen for HTML? (0)

Anonymous Coward | more than 3 years ago | (#35811094)

I think you'll find your opinion is very out of date :-)

Re:Why was TCL originally chosen for HTML? (0)

Anonymous Coward | more than 3 years ago | (#35807926)

TCL is a terrible language. For anything.

I'd rather have fucking LUA than TCL.

Re:Why was TCL originally chosen for HTML? (0)

Anonymous Coward | more than 3 years ago | (#35806844)

Holy fuck. Someone recommends Python earlier. Now it's Ruby. Can you possibly choose two slower languages (both at parsing and interpreter/JIT speed) for a web language? I mean, JavaScript is awful, but compared to those it's holy.

Re:Why was TCL originally chosen for HTML? (1)

andreev (1998552) | more than 3 years ago | (#35809160)

I'm actually surprised no one has mentioned PHP yet.

Re:Why was TCL originally chosen for HTML? (0)

Anonymous Coward | more than 3 years ago | (#35807810)

Tcl was mentioned as an example in the HTML 4.0 and 4.01 specifications, just an example, alongside JavaScript and VBScript. This was long after scripting was generally available in browsers; the author of this article implies that Tcl has a more elevated position in the specification than it really has.

On the other hand, Tcl is a great choice for browsers since it was designed to be an embedded runtime.

But long ago the entire world headed down the LiveScript/JavaScript/JScript/ECMAscript route and sadly hasn't looked around for serious alternatives. (I.E. languages that actually have a security model.)

Re:Why was TCL originally chosen for HTML? (0)

Anonymous Coward | more than 3 years ago | (#35807934)

I think someone from the Tcl/Tk community had enough experience, time, and energy to complete the project. If someone from the Ruby community (or Python community) did the same, we'd have another programming language for Chrome/HTML5.

That aside, Tcl is a great string manipulation language that has tons of native-code packages for all sorts of things webby. With Tcl (only) you can parse and modify the DOM easily (really important on a web page), as well as speak all sorts of different Internet protocols.

Additionally, Tcl natively supports sandboxing, with interpreters that are restricted to using only a minimal and externally extensible subset of the language.

Really, it's not a bad fit at all. I sense that Tcl has fallen out of favor for reasons entirely unrelated to its suitability as a web language.

Re:Why was TCL originally chosen for HTML? (1)

starfishsystems (834319) | more than 3 years ago | (#35809316)

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 matter of providing a framework to access them, and Tcl makes this part easy. Similarly, Tcl is very nice for accessing system facilities, even novel facilities such as might be found in embedded systems, or cell phones, or web browsers for that matter.

In principle, this is no different than JavaScript extensibility. The debate over which is preferable comes down to language design on one hand and interface support on the other. Both are hard to quantify. I find Tcl elegant as a language, JavaScript not. Also, Tcl has a strong support culture which historically has shown excellent consensus when developing new packages. JavaScript extensions seem to be all over the place. Quite possibly that's due to more widespread use, but it results in a more messy ecosystem, which in turn makes broad deployments such as web applications harder to support.

So I think that, if we imagine a Web 3.0 which provides integration over an essentially unbounded variety of mobile devices, the case could be made that Tcl might ultimately win the race over JavaScript. I don't know this. It remains to be seen. But NaCl demonstrates that it's a possibility, at least.

History repeating (1)

m50d (797211) | more than 3 years ago | (#35806408)

Tcl actually had the first in-browser applets, before Java. You can still get a mozilla plugin that I think works in firefox.

Re:History repeating (1)

ConceptJunkie (24823) | more than 3 years ago | (#35806702)

In my experience, Tcl was everything Java should have been.

Re:History repeating (1)

LizardKing (5245) | more than 3 years ago | (#35807458)

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).

Re:History repeating (0)

Anonymous Coward | more than 3 years ago | (#35808978)

Doing anything OO in Tcl is simply horrifying. [incr Tcl] doesn't even do garbage collection on objects.

I've maintained some fairly large Tcl codebases, and I have to say, Tcl has more warts than a cane toad. It's like someone bashed together the worst parts of smalltalk and lisp and came out with something slower than either. My real favorite is how event handlers in Tk have no concept of scope -- they only execute at global scope. Tk itself is its own vast repository of wrong though, so no sense in piling on.

Going backwards some more... (4, Insightful)

GameboyRMH (1153867) | more than 3 years ago | (#35806426)

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...

Re:Going backwards some more... (1)

CarsonChittom (2025388) | more than 3 years ago | (#35806646)

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.

Re:Going backwards some more... (1)

GameboyRMH (1153867) | more than 3 years ago | (#35806752)

Yes but we migrated away from it. When I was writing my post I actually considered pointing out the ridiculousness of the situation by calling it "bringing back ActiveX."

Re:Going backwards some more... (1)

StripedCow (776465) | more than 3 years ago | (#35806652)

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).

Re:Going backwards some more... (1)

GameboyRMH (1153867) | more than 3 years ago | (#35806784)

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.

Re:Going backwards some more... (1)

StripedCow (776465) | more than 3 years ago | (#35807276)

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).

On the other hand, I think Tcl is a step backwards w.r.t. javascript. At least javascript has closures, which are tremendously useful for interactive programs.

Re:Going backwards some more... (1)

GameboyRMH (1153867) | more than 3 years ago | (#35807404)

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.

Re:Going backwards some more... (1)

StripedCow (776465) | more than 3 years ago | (#35807486)

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.

Can't recompile with W^X (1)

tepples (727027) | more than 3 years ago | (#35807720)

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.

Re:Going backwards some more... (1)

Minix (15971) | more than 3 years ago | (#35807762)

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.

Translating existing code; dynamic typing (1)

tepples (727027) | more than 3 years ago | (#35807770)

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.

Re:Going backwards some more... (0)

Anonymous Coward | more than 3 years ago | (#35807110)

Native Client won't catch on until the LLVM support is there and it achieves full architecture independence. And "native code" as you used it is a term without meaning except in regards to the platform and environment it's on.

Re:Going backwards some more... (1)

tepples (727027) | more than 3 years ago | (#35807794)

And "native code" as you used it is a term without meaning except in regards to the platform and environment it's on.

What widespread brand of home or office PC made in the past five years and used with a keyboard and mouse doesn't use x86?

Re:Going backwards some more... (1)

h4rr4r (612664) | more than 3 years ago | (#35808508)

Why does that matter?
The Ipad is pretty popular and does not use x86.

What does iPad matter? (1)

tepples (727027) | more than 3 years ago | (#35808806)

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.

Re:What does iPad matter? (2)

h4rr4r (612664) | more than 3 years ago | (#35809286)

I never said it did, only that it was popular and not x86. I own lots of things that are not x86, some more popular than others. Breaking the web for my sparc workstation would be pretty annoying.

Re:Going backwards some more... (1)

CharlyFoxtrot (1607527) | more than 3 years ago | (#35807190)

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.

Re:Going backwards some more... (1)

GameboyRMH (1153867) | more than 3 years ago | (#35807266)

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.

Re:Going backwards some more... (2)

CharlyFoxtrot (1607527) | more than 3 years ago | (#35809140)

LOLWUT?

YA RLY

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 native don't blame Apple for giving people what they want.

Re:Going backwards some more... (0)

Anonymous Coward | more than 3 years ago | (#35811112)

Okay, to be fair, NaCl was nowhere near ready when the iPhone SDK was released. Apple did not have a good way to provide the full power of the phone to web sites. Especially for games, being able to run native is important, but there are probably a good number of other applications that need processing power.

On the other hand, Apple could have developed APIs for HTML/Javascript that would allow access to the phone's sensors and allowed web apps to be much more like native apps. They did not do that because (1) they needed to make the native SDK anyway and (2) such apps would not be tied to iOS and the large number of iPhone apps is one of their major marketing points.

UIWebView is slow (1)

tepples (727027) | more than 3 years ago | (#35807822)

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 [frontend.fi] than the JIT JavaScript engine introduced in Mobile Safari 4.3?

Re:UIWebView is slow (1)

CharlyFoxtrot (1607527) | more than 3 years ago | (#35808956)

The short answer is because Apple couldn't know they would get a JIT javascript engine when they implemented web apps the way they did in iOS 1.

The long answer from Daring Fireball [daringfireball.net] :

"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 not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android1. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.

It’s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently read-only first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.

[...]

Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control. (That’s why they show up individually in the task bar, just like apps from the App Store.) Home screen apps may well eventually get access to the Nitro JavaScript engine — Apple simply hasn’t yet done (or perhaps finished?) the security work to allow it."

Re:UIWebView is slow (1)

tepples (727027) | more than 3 years ago | (#35809290)

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.

Re:UIWebView is slow (1)

CharlyFoxtrot (1607527) | more than 3 years ago | (#35809620)

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.

Re:Going backwards some more... (1)

dkf (304284) | more than 3 years ago | (#35807196)

it seems that we may be going from an architecture-independent web to an architecture-dependent one

There's nothing wrong in principle with the architecture-independent web supporting the downloading of architecture-dependent pieces. It's been happening a lot for ages (I remember downloading Linux distributions onto floppy disk back in 1993).

The main-line Tcl development is not going to be coupled to NaCl. The environment's way too restricted for most developers to be truly interested. Still it's a bit of neat technology.

Re:Going backwards some more... (1)

GameboyRMH (1153867) | more than 3 years ago | (#35807294)

How is downloading software the same as using architecture-specific code in web pages?

Re:Going backwards some more... (1)

ogdenk (712300) | more than 3 years ago | (#35810696)

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 (mobiles or kiosks) and/or old macs.

I could a "Fat Binary" type of thing being done for cross-platform NaCL code. Or a different binary being distributed to client depending on architecture the browser is running on.

Wouldn't be too hard to turn this into something usable by everyone, the performance advantages of native code running client-side is too hard to ignore. I could see a lot of great uses for this. And if both Chrome and Firefox adopted it, IE would have to eventually.

As far as TCL over NaTCL goes.... I personally don't know JavaScript nor do I really want to, I do know and love TCL however and have used it since I got started with UNIX. Being able to call other NaCL code from TCL would be interesting as well....

My primary concern with native code is security really. I'm sure Google has come a long way since ActiveX was introduced by MS however.

Re:Going backwards some more... (0)

Anonymous Coward | more than 3 years ago | (#35811488)

Or you could just use pNaCl in the first place. That is, the "portable" version of NaCl which uses LLVM bytecode instead of x86/ARM. I guess that probably takes more work for the client which Google probably wants to avoid, at least on ARM, and is more complicated so not a good idea for a first version.

cool! (1)

StripedCow (776465) | more than 3 years ago | (#35806432)

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.

NaCl - the new ActiveX. Yuck! (1)

Polizei (1782856) | more than 3 years ago | (#35806548)

Yeah, Chrome attempts to bring ActiveX back!
I just wonder when will M$ get consumed by Google and they turn "evil".

Re:NaCl - the new ActiveX. Yuck! (2)

Minix (15971) | more than 3 years ago | (#35806584)

Native Client is open source. So any browser, even IE, could incorporate it.

In that important respect they are very different.

Is libTk on the way? (1)

bobs666 (146801) | more than 3 years ago | (#35806616)

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

Re:Is libTk on the way? (0)

Anonymous Coward | more than 3 years ago | (#35807496)

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

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?

Re:Is libTk on the way? (1)

Minix (15971) | more than 3 years ago | (#35807644)

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.

Wait, what? (0)

Anonymous Coward | more than 3 years ago | (#35806668)

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.

Re:Wait, what? (1)

Minix (15971) | more than 3 years ago | (#35807156)

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.

And NaTcl uses the speed of NaCl to achieve that.

It's a good thing.

Re:Wait, what? (1)

BZ (40346) | more than 3 years ago | (#35807630)

Except that NaCl is architecture-specific, thus defeating the whole point of using a web app (or for that matter a scripting language) in the first place.

Try using a JS-heavy web app with JS turned off (2)

tepples (727027) | more than 3 years ago | (#35807884)

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 [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.

I'm Torn (1)

eison (56778) | more than 3 years ago | (#35807264)

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.

NaTcl? (1)

Chris Mattern (191822) | more than 3 years ago | (#35807336)

Saltty!

Similar (in concept) to previous work (1)

riley (36484) | more than 3 years ago | (#35808054)

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.

Wasn't Lua first? (2)

Corsix (1178253) | more than 3 years ago | (#35808538)

I thought that one of the samples included with NaCl was a Lua interpreter, meaning that TCL is far from being first.

A little late ... (1)

Jack Greenbaum (7020) | more than 3 years ago | (#35808566)

... April 1st was almost two weeks ago.

Haskell (1)

StripedCow (776465) | more than 3 years ago | (#35808574)

I'll be really impressed when they embed a pure functional language like Haskell, and make it interoperate with the DOM.

Re:Haskell (0)

Anonymous Coward | more than 3 years ago | (#35808896)

There are Haskell-to-Javascript compilers[1], so watch out!

[1] See Google.

Call me when its PyCl (1)

mmaniaci (1200061) | more than 3 years ago | (#35809054)

Python would be much better suited for browser scripting. Its string-based also, and would wrap DOM like a womb.

What Happened to Ruby? (1)

adavies42 (746183) | more than 3 years ago | (#35810994)

The XTHML documentation (I think?) was full of references to scripts in Ruby (instead of JavaScript). Whatever happened to that?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>