Google native code browser plug-in gets tickled The Tcl scripting language has been plugged into Google's Native Client, allowing Tcl code to run inside the Google Chrome browser in much the same way that JavaScript does. Using Native Client – a Google-created plug-in for securely running native code inside the browser – Tcl now has direct access to the Chrome DOM. "The net …
The difference is that it's running in a NaCl box as opposed to a DirectX plugin, so it's both platform independent and inherently trustable (according to how much you trust the NaCl sandbox, anyhow - but no need to put extra trust in the TCL interpreter or the code it's running).
It already is. Google's sites are best viewed in Chrome simply because it's the only browser which uses SPDY instead of HTTP to see them. (don't tell me others can implement SPDY, the protocol is badly documented not to mention there should really be at least an RFC for it)
Welcome to the 90s all over again, just replace Microsoft by Google.
Do people who choose to write complex apps in Tcl have no idea what other roughly comparable languages (e.g. perl, python) are like? Honestly trying to not make this a troll.
Not to take away from all it can do, but it's so strange to use. In my limited use, when I write any Tcl at all (other than simple unconditional commands) I find I'm often trying to trick the language into doing what I want because it seems the 'normal' way doesn't ever work (or I find out after, that the trick which worked is in fact the normal way for Tcl). I can certainly see how, if you've put in the steep learning curve to be good at Tcl, you'd then want to put that to use. But when you choose it mainly based on that investment bias, it doesn't mean you get to call it a good language. Am I being unfair?
And it's not as though there aren't at least a dozen languages out there which can do anything Tcl can both more concisely and more understandably: Perl, for example. Or Python. Or Java. Or Javascript. Hell, I'll write Visual Basic before I'll write Tcl.
(And I don't want to hear a *word* out of you Python lot about how awful Perl is. By comparison with Tcl, your holy cause and mine might as well both be the same language entirely -- that is, the language that lets you get your job done, instead of impeding you from doing so at every possible turn because it was invented by one guy from Shithole Flats, North Dakota who'd never heard of Unix before and only ever saw an Algolic language once, briefly, immediately after sustaining a nasty blow to the head and before he'd finished wiping the blood out of his eyes.)
http://wiki.tcl.tk/25960
You're wrong.
There's at least one thing Perl, Python, Java, Javascript and Java can't do as we speak, and that's run under NaCl.
That will change, but then we can see how well Tk stacks up compared to writing raw HTML/CSS for generating Web GUIs. Hint: very well indeed.
Tcl keeps the entire interpreter state in one (non-global) variable, thus allowing multiple, independent interpreters to be run in different threads. Maybe this is why it's a good choice for this app.
I don't think this is at all possible for python, unless you do a *lot* of recoding. You can 'bless' threads to share the same interpreter with other threads, but that's not the same thing.
Short answer: Tcl is lisp for strings, and we're all afflicted by the smugness of people who *get* lisp.
One significant difference between Tcl and PERL, Python, etc is that Tcl is completely defined by a very small set of syntactic rules. There is *no* special syntax for conditionals, loops, threads, coroutines, etc. Everything is expressed in a very simple syntax.
So, for me, that radical simplicity translates to a freeness of form. I now bridle at the arbitrary restrictions imposed by more traditional languages.
Tcl is utterly completely extensible, and highly introspective, and lends itself to emulation and interfacing to new and unexpected things, and so the community seems to define itself, not in terms of PERL and Python, but in terms of the next big thing coming down the track.
Some people don't get that, or don't want it. That's ok.
I think I know what u mean, in that since I've done a lot of python coding, I get very very frustrated with C++. Not because it isn't python -- that would be silly -- but because from the perspective of using python I now clearly see all the ways it's totally falling short of what it (C++) is trying to do with templates and so forth.
I don't really know perl but I think that python has the goods for extensibility and introspection. You can, for instance, fairly easily generate functions in the form of strings - ordinary source code - and then compile them and call them .. not quite as transparently as in Tcl (or lisp, for that matter) but not at all hard. This is a really good speedup trick in some cases, but it's difficult to imagine a case where this is the only reasonable option. In Tcl of course, executing a string is business as usual
If you are trying to "trick" the language, perhaps you don't understand how it works. Tcl is not a language that just simply simulates what other languages do, but uses a different, "weird" syntax. It *IS* different. It is also extremely powerful, if you dare to go beyond basics. It's power lies in it's super dynamism, where everything is modifiable and morph-able at runtime. It also has a whole buffet of object oriented frameworks, in addition to the built-in one. Tcl is such a chameleon language that you can build other DSL (Domain Specific Language) languages on top of it. It is the power to shape and mold it in a way that is only limited to my imagination is what attracted me to it. It is a power to be creative.
What I meant is that, 'how it works' appears to a novice like you are tricking the language, e.g. by reprocessing a string in some non-obvious way to get a certain result. That's how it works, but it means that some ordinary, everyday Tcl things look like strange tricks to the learner. In other languages you don't have to get strange simply in order to do fairly ordinary things (which is not the same as saying you *can't* get strange if you want to). Only stated as my opinion.
And I feel that pretty much everything you say about TCL, run-time morphing, do-anything powerful, can also be said about coding directly in assembler -- just replace the word 'string' in any overall description of TCL with 'byte, or group of bytes' and you could easily end up with a description of assembler (try this: absolutely everything is a "string" and the programmer controls exactly how each string is treated by the program). Except of course that TCL has garbage collection and much better behaviour when things go wrong, and is not tied to a specific processor. So it's definitely better than assembler, but in terms of general usability it's a good way off in that direction IMHO.
@Aaron Em
There are two certain things in the world -- death and taxes, but in fact there is a third one -- the ignorant ones, those who know the least, they talk the most. It is a sure sign of a fool.
Most people who use Tcl also use *and* respect Python, Perl, C and Javascript, sometimes even those over-hyped, awful, trendy, hip and *popular* languages called Java and PHP. While knowing those languages, and, being able to compare them fully, they still prefer to use Tcl. There might be a good reason for it. For some people, hype is not intelligent enough reason to select a programming language.
Certainly sounds like as Tcl is not one of the Google sanctioned language - I thought they'd been limited to the Gang of 4: Java, C++, Python and Perl?
Anyway nice thought experiment. Another approach is to use LLVM to port to Javascript. "What?" I hear you cry. All in the spirit of research. Try http.//zodb.ws (3 MB download works best, if at all in FF 4) - a Python application cross-compiled in Javascript using local storage for persistence. And while it is kind of neat, it was also released on 1st April! :-D
People brought up on algol-derived languages may not appreciate tcl, but the rest of us enjoy how easy our lives are when we program in the language.
Right now for example I am using tcl in a web project and the domain-specific language (DSL) I use for generating HTML lets me express what I mean more simply and directly than nearly any other web framework I have ever seen, making the code easier to write and easier to read.
This property is a result of the very simple and regular syntax, which is also what makes the language very easy to learn, at least if you don't have algol-ish preconceptions of how programming works. Of course lisp does nearly everything tcl can do and more, and might be a better choice for someone choosing a new language to learn.
Not that there is anything wrong with C or Java; I have programmed in the former for years and tutored students of the latter so I know what they are about, but I still prefer to use tcl.
For those who need some help groking tcl, I suggest a look at the MIT SICP lectures. These are not about tcl, but the concepts will help a lot with understanding what tcl is about: http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
As to the present topic, I have not seen this tcl-on-NaCl work so I can't comment on it but it sounds interesting. However I probably won't use it myself until (if) NaCl becomes widely supported, not just in Chrome. It is also worth noting that in terms of security sandboxing, tcl has had its own sandboxing mechanism for some time in the form of safe interpreters, which are a core part of the language.
but just want to throw out a question here, and that's if you *really* need to program in Tcl for this to work?
Could someone (Google, whoever) create a compiler (pseudo-compiler?) to take your C (or whatever) code and translate it into Tcl?
A friend of mine (who, unlike myself, *is* a programmer) is a big fan of a RAD tool called code-charge which allows write-once for a variety of web servers and DB back-ends, and I thought there were tools that allowed write-once app for various mobile platforms... seems to me that putting together something to translate your code into Tcl wouldn't be any more difficult than any of those.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
