Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Chrome Google Programming

Tcl Announces NaTcl: Native Client Tcl 124

Posted by timothy 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 :)"
This discussion has been archived. No new comments can be posted.

Tcl Announces NaTcl: Native Client Tcl More

Tcl Announces NaTcl: Native Client Tcl

Comments Filter:

  • 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. 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: (Score:2)

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

    • 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 ha

      • Re: (Score:3)

        by Minix ( 15971 )
        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

        • Re: (Score:2)

          by zoips ( 576749 )

          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

        • Re: (Score:2)

          by Qzukk ( 229616 )

          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!"

          Can you imagine my surprise when I first learned (enti

      • Re: (Score:2)

        by mwvdlee ( 775178 )

        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: (Score:2)

          by harrkev ( 623093 )

          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

          • Re: (Score:1)

            by Anonymous Coward

            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 clai

            • Re: (Score:2)

              by Minix ( 15971 )
              | Can someone comment on ANY technical advantages that Tcl would have over Javascript

              Good 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

              • Re: (Score:2)

                by Minix ( 15971 )
                Oh, one more!

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

      • Re: (Score:2)

        by BZ ( 40346 )

        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: (Score:2)

        by Ant P. ( 974313 )

        That's why it's a requirement to specify the language used.

        Only for a language other than the standard default [whatwg.org].

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

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

  • 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

        • Re: (Score:2)

          by dkf ( 304284 )

          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.
  • Tcl actually had the first in-browser applets, before Java. You can still get a mozilla plugin that I think works in firefox.

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

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

  • Going backwards some more... (Score:5, Insightful)

    by GameboyRMH ( 1153867 ) <`gameboyrmh' `at' `gmail.com'> on Wednesday April 13, 2011 @08:55AM (#35806426) Journal

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

    • Comment removed based on user account deletion

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

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

          On the other hand

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

          • Re: (Score:2)

            by Minix ( 15971 )
            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.

              • Re: (Score:2)

                by dkf ( 304284 )

                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.

        • 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 na

      • 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?

        • 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 n

          • Re: (Score:2)

            by tepples ( 727027 )
            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.

    • Re: (Score:2)

      by dkf ( 304284 )

      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.

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

        • Re: (Score:2)

          by dkf ( 304284 )

          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.

    • Re: (Score:2)

      by ogdenk ( 712300 )

      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

    • This started years ago when Java and Flash came out. Applications have proven to often be dependent on versions, and platform inter-operability has not proven to be as advertised.

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

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

    • Re: (Score:3)

      by Minix ( 15971 )
      Native Client is open source. So any browser, even IE, could incorporate it.

      In that important respect they are very different.
  • 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

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

  • Saltty!

  • 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 t

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

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

    • Re: (Score:2)

      by dkf ( 304284 )

      [Python] ... would wrap DOM like a womb.

      So for mortal humans, producing anything with it would take 9 months, require enormous amounts of pain, and afterwards there would be much screaming and being sick?

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

    • 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...
  • 1. It's Turing complete. 2. Umm...

    • Re: (Score:2)

      by dkf ( 304284 )

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

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close