Assuming that you used two different text elements, each with its own fgcolor, then my guess is that you need a layout to position the text objects one after the other -- otherwise they all are positioned at x="0" y="0" by default, so they overlap like this (source).
You can put a layout element into a canvas or view, like <simplelayout axis="x"/>, and it magically positions its siblings (the text elements) like this (source). There are even more powerful layouts like the <wrappinglayout/> that work like this (source). [Try resizing the window -- it's very xmasy!]
Another way to make a text element with two different colors is to change the colors with html, using <font color="#ff0000"> tags in the text, like this (source).
-Don
No other game has done this...
on
Why Spore Is Special
·
· Score: 2, Interesting
I hate to be sappy, but I think there's a point to games that make people think about the real world.
Hopefully Spore will make people think about Mother Earth, the Solar System and the Universe, the same way The Sims makes people think about their Mum, Family and Society.
Here is a message about The Sims titled "No other game has done this...", posted in April 2000 (one month after The Sims was released) in the alt.family-names.sims newsgroup (the Sims fans took over the alt.family-names.sims, newsgroup because there wasn't a newsgroup for The Sims game yet).
-Don
Hi... no need to reply to this cos it's just a whimsical thought:-)
When I first got the game I tried to make my own family, trying to get
their personalities accurate too. When making myself, my dad and my
sister, I attributed points to all the personality categories, and I
found I had points left over. But when I made my mum I ran out of
available points and was wishing for more -- I wanted to give her more
points than are available. It made me realise for the first time in
years how much I love my mum:-)
Now what other game has ever done *that*?:-)
Gavin Clayton
The Future of Content, and new book: Mirror Lake
on
Why Spore Is Special
·
· Score: -1, Offtopic
The Future of Content
What I learned about content from the Sims. ...and why it's driven me to procedural methods. ...And what I now plan to do with them.
Will Wright
Game Developers Conference
3/11/2005
Joel Jones and her family Will Wright and Cassidy Wright just published this beautiful new book, which I highly recommend:
Through the paintings and photographs of authors Joell Jones, Will Wright, and Cassidy Wright, this gift book looks at the nature and environment of Fripp Island, off the coast of North Carolina near Beaufort. The images and musings span more than two decades of visits to a coastal vacation spot that mirrors the process of leisure development in natural settings all over the world. In it we see and read about many aspects of nature, including the loggerhead turtles that once hatched freely on Fripp's beaches.
About the Authors
Joell Jones is an exhibiting artist with her studio in Oakland, California. She received her BA from Louisiana State University at Baton Rouge, and her MA from JFK University in Orinda, California. She studied painting with Michelle Cassou. Joell is married to co-author Will Wright and mother of co-author Cassidy Wright.
Will Wright is co-founder of Maxis Software Company in Emeryville, California, and designer of the computer games SimCity, The Sims, and Spore. Wright was given a Lifetime Achievement Award at the Game Developers Choice Awards in 2001. He has been informally photographing at Fripp Island since 1999.
Cassidy Wright has been involved in art exhibits, and in the inventor sport of Robot Wars, since she was eight years old. In 2004 she entered the California College of the Arts in Oakland, California, to investigate her interests in a variety of media. She has been photographing at Fripp Island since 2000.
That's just downright false. Where did you learn all that fiction, or did you make it up yourself?
CSS and HTML are definitely not Turing complete, and JavaScript certainly is.
JavaScript has much worse problems than buffer overruns (which are quite rare, compared to its other problems).
If you think regular expressions are the answer for translating between JavaScript and Lua, then you must have a very shallow understanding of both languages, and you probably come from a Perl or PHP background: shitty languages that encourage programmers to write half-assed regexp based parsers that break down in all but the simplest of circumstances, with cultures that encourage sloppy thinking and seat-of-the-pants parsing and half assed solutions.
Case in point: have you ever read the source code for PHP's "Smarty" template library? It's a total piece of shit, based on regular expressions that compile templates into PHP. Compare and contrast that it to the much more rigorous, much better designed "Kid" template library for Python, which uses a real XML parser, and produces valid, predictable code without any fuzzy edge cases and buggy quirks.
So how can you write a regular expression that translates JavaScript code with zero-based array indices to Lua code with one based array indices? How do you write a regular expression that supports JavaScript's inability to close over the "this" variable, which is in many cases the variable you most often want to close over? (If you don't understand what I'm talking about, you don't know JavaScript or programming langauges well enough to continue this argument.) Yes, I know "this" isn't *actually* a variable in JavaScript, but a keyword -- but that's my point: regexps simply can't deal with that kind of semantic incompatibility.
One thing that makes JavaScript inefficient is its view of function arguments as a regular JavaScript associative array objects, which you can index with numbers, or with other special names like arguments.caller. This precludes the use of an efficient stack for passing parameters. So JavaScript has a much higher overhead for function calls than Lua, because it has to create and destroy so many objects each time. Compare that with the way Lua VM passes parameters much more efficiently on a stack.
Speaking of the special "arguments" parameter, how will your glorious regular expressions get "functionName.arguments" to work? When Lua code refers to a function, it gets the function itself, with no silly runtime information like the magic JavaScript function that just happens to have a reference called "arguments" to the latest stack frame that called it. How do you propose to make that work in a multi-threaded environment? How do you propose to write regular expressions that translate deep semantic differences between the languages like that?
Your claim that you can translate from one language to another using regexps is like a little 6-year-old girl thinking she can bake a huge wedding cake with an easy-bake oven and a 20 watt lightbulb. Take a compiler class, kiddo.
Comparing implementations of the languages certainly does count in this case, because of the EXTREMELY HUGE difference between the most popular JavaScript implementation (SpiderMonkey), and Lua. They are totally at opposite ends of the spectrum. When comparing speed and memory usage, Lua's score is 41.7, and SpiderMonkey's score is 4.7. How do you explain that Lua's score is 8.87 times better than SpiderMonkey's score? Yes, SpiderMonkey does compile into bytecode, so it's not because it's interpreting the parse tree directly.
You should study the history of Lisp design and implementation, as well as Haskel, and of course Self, and even C++ and Java, if you want to understand how to design programming languages that can be compiled into efficient code. Then you will understand why PHP and JavaScript will never run fast, and why it's no surprise that they're the bottom losers in the computer language shoot out. There is such a thing as cause and effect, you know.
You don't know eiter Lua or JavaScript very well, if you actually think you could convert between them with a "a couple of regexps and a small compatibility module".
If you really think JavaScript can be made to run as fast as Lua, then can you offer an existence proof, or explain why SpiderMonkey is so much slower than its potential? Why is it so slow and inefficient, and why hasn't anyone done anything about it?
Yes, you're reading the code wrong, because it's very tricky.
The event is not used to click on a confirmation button (that would be impossible), it's used to trick the browser into executing a JavaScript function in a different (trusted) context, where it can directly call the addBookmarkForBrowser function (which normally can't be called by untrusted code). The way it does that is to add a getter method hook to the head element "ownerDocument" property, so the hook gets called in a totally different (trusted) context when the dummy event is handled. The trusted event handling code foolishly accesses the head element's "ownerDocument" property, which calls the code provided by the untrusted web page, in a trusted context.
So you're saying it's ok for the browser to leak references to internal functions, because your user interface guidelines dictate that it's a bad idea to call those particular functions (even if my clients dictate they want a button that does that on their web page)?
My point, in case you missed the sarcasm, is that Firefox's JavaScript implementation is so complex and tangled that it leaks pointers to functions that web based scripts should not be able to call. If you can call the function to add a bookmark, then what kind of other functions are sitting there waiting to be cherry picked and called by maliscious scripts?
Oh yes there is quite a lot about Lua's design that make it inherently much more efficient that JavaScript.
Why do you think it's SO MUCH faster and smaller -- mere coincidence?
Have you ever looked at either the Lua source code or the SpiderMonkey source code, or compiled either of them yourself, or are you just pulling that statement out of your ass?
Here's the "standard" way to add a bookmark to the current page in Firefox:
function addBookmarkForBrowser() {
if (document.all) {
window.external.AddFavorite(document.location.href , document.title);
} else {
var ea = document.createEvent("MouseEvents");
ea.initMouseEvent("mousedown",1,1,window,1,1,1,1,1 ,0,0,0,0,1,null);
var eb = document.getElementsByTagName("head")[0];
eb.ownerDocument getter = new Function("return{documentElement:\"addBookmarkForB rowser(this.docShell);\",getBoxObjectFor:eval}");
eb.dispatchEvent(ea);
}
}
So it's a good thing that Firefox's JavaScript interpreter leaks references to internal functions that web scripts aren't supposed to access. Because some of them are useful, interesting functions that are fun to call!
That's too bad about FireFox being essentially written in JavaScript.
SpiderMonkey, the JavaScript interpreter in Firefox, is BY FAR the worst programming language (in terms of speed and memory use) of them all, according to the Computer Language Shoot Out.
When you compare all the languages on CPU time, SpiderMonkey JavaScript is twice as slow as the second worst, Ruby.
When you compare all the languages on memory usage, SpiderMonkey is 1.7 times as bloated as the second worst, Smalltalk Visual Works.
When you compare all the languages on CPU time AND memory usage, SpiderMonkey is 2.1 times as bad as the second worst, Smalltalk GST.
Firefox would be much better off using Lua, which is much easier to integrate with C code than SpiderMonkey's nightmare sausage factory, much faster, much smaller, and a vastly better language design. The fact is, that good language design has a huge effect on speed and memory usage -- you can't just stick your head in the sand and pretend good language design isn't important, like the PHP and JavaScript designers originally did and still do. Bad design paints your bad implementation into a bad corner, and there it stays.
Here's how Lua and SpiderMonkey JavaScript stack up against each other. Lua TOTALLY smokes JavaScript, in every category, by a long shot. It's not even funny -- it's tragic. Face it: JavaScript is not only a horribly designed language, but SpiderMonkey is also a horrible implementation of that horribly designed language. So it's not surprise that SpiderMonkey has always had gaping security holes, to complement its horribly slow speed and extremely huge size.
Lua x times better than SpiderMonkey JavaScript
binary-trees: 2.9 x faster, 6.6 x smaller
cheap-concurrency: No SpiderMonkey
fannkuch: 3.8 x faster, 1.2 x smaller
fasta: 8.2 x faster, 13.9 x smaller
k-nucleotide: 3.7 x faster, 10.0 x smaller
n-body: 6.3 x faster, 77 x smaller
nsieve: 7.8 x faster, 2.0 x smaller
nsieve-bits: 2.3 x faster, 29 x smaller
partial-sums: 7.0 x faster, 80 x smaller
recursive: 2.9 x faster, n/a3
regex-dna: 1.9 x faster, 5.3 x smaller
reverse-complement: 8.0 x faster, 5.8 x smaller
spectral-norm: 6.2 x faster, 71 x smaller
startup: 1.2 x slower, 1.1 x smaller
sum-file 5.3 x faster, 21 x smaller
Don't you guys trying to optimize your software bubble sorts realize that these days, all the fast sorting action is happening in hardware accelerated Bubble Memory?
Another advantage of standardizing computers to be shaped like human heads: Rich computer-phobic people can hire real humans to sit under the table and stick their head up through a hole.
Steve Jobs already turned down the sexiest shaped computer possible (well, excluding naughty bits):
Sometimes his quest for creativity had comical results, like when Steve Jobs searched for the most innovative designers of the day to create the shape and look of the new machine. He noticed a London firm that won a contest for its styling of a flashlight, and he hired the firm to build a prototype for the NeXT computer.
When the work was completed, Steve and Bud Tribble flew to London. They sat in a conference room looking at a shrouded form on the table. These guys had the same sense of drama Steve did! The British designers talked at length about the thinking that informed their approach. Then, finally, they pulled off the shroud and revealed... a computer in the shape of a human head!
Well FYI: text == graphics, in case you didn't notice. Ever hear of fonts, glyphs, unicode, typesetting, layout, flow, justification, css styles, colorization, syntax highlighting, selection, cut and paste, drag and drop, scrolling, outlining, collapsing, linking, etc? So yes, texual user interfaces == graphical user interfaces, unless you're reading text as braille.
-Don
Re:Yeah, that's tab completion.
on
GUIs Get a Makeover
·
· Score: 2, Insightful
Read the article I linked to: it describes how TOPS-20 programs and commands can document themselves to the CLI, so it can provide the user with consistent completion and full help about the parameters, insert (and ignore) noise words, and provide completion over alternative symbol spaces for special types of arguments, like host names. That was quite useful when ARPANET addresses were only 8 bits long, and you could type "teln mit-?" to get a list of all host names beginning with "mit-" that you could telnet to. TOPS-20 command line help and completion is much more comprehensive and standardized than the hodge-podge of Unix shells and utilities and weird scripting languages and quoting conventions like: find . -name '*~' -exec rm "{}" \;
Origins and Development of TOPS-20
by Dan Murphy
Copyright (c) 1989, 1996 - Dan Murphy
Another area where TENEX, and later TOPS-20, excelled was in the user interface, described in detail below. A key reason that we were able to extend the user interface so significantly is that the code which implemented it ran an an ordinary user program. Hence, it wasn't constrained by size or limited by functions which could not be performed in kernel mode. Beyond that, debugging it was much simpler -- it didn't require stand-alone use of the machine as did kernel debugging. All of this allowed a great deal of experimentation and evolution based on tuning and feedback from real use and real users.
User-oriented Design Philosophy
A piece of system design "philosophy" had emerged at BBN and among some of the ARPA research sites that was to have a large impact on the overall feel of TENEX and, ultimately, TOPS-20. At the time, we called this "human engineering" -- we wanted the system to be easy to learn and easy to use, and we wanted the system to take care of as many grungy details as possible so that the programmer or user did not have to deal with them. Beyond that, we were willing to spend real machine cycles and real (or at least virtual) memory to make this happen.
This philosophy led initially to the human interface features of the EXEC, including "escape recognition", the question-mark help facility, optional subcommands, and "noise" words. Few people now argue against the need to provide effective human interfaces, but at that time there were many detractors who felt that it was a waste of cycles to do such things as command recognition. These kinds of things, they said, would "slow the system down" and prevent "useful work" from getting done. Other contemporary systems used short, often one-letter, commands and command arguments, provided no on-line help, and did not give any response to the user other than the "answer" (if any) to the command that had been entered.
Computer use by non-experts
Many such systems fell into the "by experts, for experts" category. That is, they were built by experts and intended to be used by other experts. An "expert" would obviously not need frivolous features like noise words or command recognition. Experts would know, not only all the commands, but all the legal abbreviations as well. Experts may have read the manual once, but would always remember everything needed to interact with the system. So went the implicit assumptions about users -- either you were an expert, or you were an inferior being not really entitled to use the Computer anyway.
The TENEX team took a different view. It was clear that the power of computers was increasing every year and so one should expect the computer to do more and more interesting things. Most people would agree that a major purpose of computer automation is to relieve people of boring, repetitive tasks; we believed that purpose extended to computer system development as well, and that it was wrong to require a person to learn some new set of boring, arcane tasks in order to use the computer. The machine should adapt to man, not man to the machine.
The view was probably reinforced by the artificial intelligence research being done in the environment where TENEX was designed. In such areas as speech recognition, pattern recognition, and natural language comprehension, massive computation power was being applied to make computers interact in ways that would be more human. These were long-term efforts, but we wanted our computer systems to be more human-oriented in the sort term as well.
I think there are some good lessons to learn from TCL/Tk, that can be applied to Lua gui api design! (But not to the Lua language design!;-)
TCL was popular because of Tk, which was the best X11 user interface toolkit of its time. One reason Tk was so successul, was that the Tk toolkit was tightly integrated with the TCL scripting language, and they nicely complemented each other. Tk called out to the TCL scripting language to do most of the work, instead of trying to do all that string bashing, table lookup, configuration, plugging together and scripting stuff in C, like "Xt" (the Ech-StoolKit) and Slowtif make so awkward. So it was quite easy for Tk programmers to configure guis and script callbacks with TCL, without having to modify and recompile any C code. TCL worked well with C because it nailed something that C sucks at: string processing.
In the same way, JavaScript is popular because of Dynamic HTML, not because it's a good language. The killer app is really DHTML, and JavaScript is just along for the ride. Outside of the realm of Microsoft's ActiveX/OLE/IScriptingEngine, it's difficult to integrate JavaScript with C. But languages like TCL and Lua, and tools like SWIG make that easy.
I'm optimistic that some form of Lua will eventually find its way into common use for scripting web browsers, and even more interestinig stuff like 3D virtual worlds ala WOW and There. It will spread through the same as the Flash virus used to infect 98% of all desktops (ActiveX, Netscape plug-in API), and other even more infectious vectors: computer games. The WOW and There clients are basically just smart 3D VR AJAX engines, scripted in Lua. WOW, Lua's already There!
Yes, Auctioneer is very pretty code, and it does a lot of sophisticated stuff, too! Every time I log into WOW, I let auctioneer scan all the auctions and update its tables of market price statistics, and once it's done (about 7 minutes of downloading), it presents a list of the most profitable auctions that are expiring soon, and the expected profits. I've snatched up strange items like "Elemental Fire", and turned them around for huge profit. Every object you point at can pop up stats about its expected auction price. Some people use Auctioneer regularly (and game the auction house) to make real money (selling WOW gold for real cash).
The "cosmos" ui and "thottbot" service is an even more elaborate set of WOW extensions, all scripted in Lua. It gathers statistics on EVERYTHING you see in the game, and uploads the data to the central server, which hosts discussion boards for every location, object, non player character, quest and magic spell in the game. It's like a real time screen scraper that spys on WOW's data stream, which it can do efficiently because so much of the game is exposed to Lua, and all events are reported to the scripting language!
Yeah, I had a great fling with TCL/Tk, which was the best thing around in 1992, but I'm really glad it didn't become the Standard Scripting Language. As bad as it is, I can live with JavaScript.
But RMS was right when he said: If Tcl does
become the "standard scripting language", users will curse it for
years -- the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with. He forgot to mention Perl, and PHP was just being ill-conceived in 1994.
Of course the FSF was developing GUILE as an alternative to TCL/Tk.
But Lua also has all the properties that Stallman recommends for an extension language: it's a real programming language for writing and maintaining substantial programs, with arrays, structures, numbers, semantically lisp-like, but with a traditional algebraic syntax, and extremely fast execution. And it's under the MIT license (ahem), so it gets used in real world commercial products (WOW).
But there are other important properties for a scripting language that he doesn't mention. Especially: Easy integration with C and native libraries, which is hard to get right in a Scheme system that efficiently supports full continuations. Easy integration with applications and libraries is essential!!!
The final straw that made me decide to use Lua instead of SpiderMonkey JavaScript, was that SWIG supports LUA well, but it doesn't support SpiderMonkey. That's very important to me, because by using SWIG instead of a language-specific binding (tolua++, boost, etc), SWIG makes it easy to plug my libraries into ANY scripting language (except JavaScript;-).
-Don
GIMP is only free if your time is worthless.
on
GUIs Get a Makeover
·
· Score: 1
Sheez, do I have to deconstruct it for you? The expression means that GIMP wastes a lot of your time, which is not a problem if your time is worthless. But most people value their time as priceless, so it costs them too much to use GIMP. By wasting your own time, you're certainly not hurting Bill Gates or John Warnock.
The "command --help syntax" is certainly not supported by all Unix programs, and it's much less convenient and comprehensive than TOPS-20's built-in command line completion, which every utility and application supported. TOPS-20 is so 1969 -- why is Unix still so far behind?
Yes, programming languages, scripting languages and command line interfaces certainly are user interfaces, because programmers are users of programming languages, which allow programmers to interface with the computer, tell it what to do, manipulate its internal state, build models, call functions, etc. And many of the guidelines that apply to designing graphical user interfaces also apply to designing textual programming languages. Yes it does matter if a programming language or command line interface is badly designed and hard to use.
Do you really think PHP, one of the most popular badly designed scripting languages, is "optimized for people who use it a lot"? No, it's optimized to be "useful" for inexperienced people who have never used any other programming language before, who shouldn't be programming in the first place, to quickly and easily introduce gaping security holes in networked computers.
PHP is the classic example of a badly designed user interface for programming computers, with deeply rooted design flaws that empower users to shoot themselves in the foot (with an automatic machine gun) while swinging by the neck from a noose (automatically tied for them). PHP "features" like magic_quotes_gps and register_globals were bad user interface design decisions, that the authors of PHP should have never made, if they thought of language design as user interface design. (Especially considering the kind of naive users they have programming PHP scripts.)
Slashdot Mirror
IT didn't cause your divorce. Getting married caused your divorce. And who do you have to blame but yourself and your wife, for that?
-Don
Assuming that you used two different text elements, each with its own fgcolor, then my guess is that you need a layout to position the text objects one after the other -- otherwise they all are positioned at x="0" y="0" by default, so they overlap like this (source).
You can put a layout element into a canvas or view, like <simplelayout axis="x"/>, and it magically positions its siblings (the text elements) like this (source). There are even more powerful layouts like the <wrappinglayout/> that work like this (source). [Try resizing the window -- it's very xmasy!]
Another way to make a text element with two different colors is to change the colors with html, using <font color="#ff0000"> tags in the text, like this (source).
-Don
I hate to be sappy, but I think there's a point to games that make people think about the real world. Hopefully Spore will make people think about Mother Earth, the Solar System and the Universe, the same way The Sims makes people think about their Mum, Family and Society.
Here is a message about The Sims titled "No other game has done this...", posted in April 2000 (one month after The Sims was released) in the alt.family-names.sims newsgroup (the Sims fans took over the alt.family-names.sims, newsgroup because there wasn't a newsgroup for The Sims game yet).
-Don
The Future of Content
...and why it's driven me to procedural methods.
...And what I now plan to do with them.
What I learned about content from the Sims.
Will Wright
Game Developers Conference
3/11/2005
Joel Jones and her family Will Wright and Cassidy Wright just published this beautiful new book, which I highly recommend:
Mirror Lake is the natural environment where Joell Jones, Will Wright and Cassidy Wright retreat for vacation to draw inspiration. Proceeds from this new book go to the Turtle Nest Protection Program.
Through the paintings and photographs of authors Joell Jones, Will Wright, and Cassidy Wright, this gift book looks at the nature and environment of Fripp Island, off the coast of North Carolina near Beaufort. The images and musings span more than two decades of visits to a coastal vacation spot that mirrors the process of leisure development in natural settings all over the world. In it we see and read about many aspects of nature, including the loggerhead turtles that once hatched freely on Fripp's beaches.
About the Authors
Joell Jones is an exhibiting artist with her studio in Oakland, California. She received her BA from Louisiana State University at Baton Rouge, and her MA from JFK University in Orinda, California. She studied painting with Michelle Cassou. Joell is married to co-author Will Wright and mother of co-author Cassidy Wright.
Will Wright is co-founder of Maxis Software Company in Emeryville, California, and designer of the computer games SimCity, The Sims, and Spore. Wright was given a Lifetime Achievement Award at the Game Developers Choice Awards in 2001. He has been informally photographing at Fripp Island since 1999.
Cassidy Wright has been involved in art exhibits, and in the inventor sport of Robot Wars, since she was eight years old. In 2004 she entered the California College of the Arts in Oakland, California, to investigate her interests in a variety of media. She has been photographing at Fripp Island since 2000.
That's just downright false. Where did you learn all that fiction, or did you make it up yourself? CSS and HTML are definitely not Turing complete, and JavaScript certainly is. JavaScript has much worse problems than buffer overruns (which are quite rare, compared to its other problems).
-Don
HTA's _ARE_ ActiveX controls, written in XML and your language of choice, which just might happen to be JavaScript, but doesn't have to be.
-Don
If you think regular expressions are the answer for translating between JavaScript and Lua, then you must have a very shallow understanding of both languages, and you probably come from a Perl or PHP background: shitty languages that encourage programmers to write half-assed regexp based parsers that break down in all but the simplest of circumstances, with cultures that encourage sloppy thinking and seat-of-the-pants parsing and half assed solutions.
Case in point: have you ever read the source code for PHP's "Smarty" template library? It's a total piece of shit, based on regular expressions that compile templates into PHP. Compare and contrast that it to the much more rigorous, much better designed "Kid" template library for Python, which uses a real XML parser, and produces valid, predictable code without any fuzzy edge cases and buggy quirks.
So how can you write a regular expression that translates JavaScript code with zero-based array indices to Lua code with one based array indices? How do you write a regular expression that supports JavaScript's inability to close over the "this" variable, which is in many cases the variable you most often want to close over? (If you don't understand what I'm talking about, you don't know JavaScript or programming langauges well enough to continue this argument.) Yes, I know "this" isn't *actually* a variable in JavaScript, but a keyword -- but that's my point: regexps simply can't deal with that kind of semantic incompatibility.
One thing that makes JavaScript inefficient is its view of function arguments as a regular JavaScript associative array objects, which you can index with numbers, or with other special names like arguments.caller. This precludes the use of an efficient stack for passing parameters. So JavaScript has a much higher overhead for function calls than Lua, because it has to create and destroy so many objects each time. Compare that with the way Lua VM passes parameters much more efficiently on a stack.
Speaking of the special "arguments" parameter, how will your glorious regular expressions get "functionName.arguments" to work? When Lua code refers to a function, it gets the function itself, with no silly runtime information like the magic JavaScript function that just happens to have a reference called "arguments" to the latest stack frame that called it. How do you propose to make that work in a multi-threaded environment? How do you propose to write regular expressions that translate deep semantic differences between the languages like that?
Your claim that you can translate from one language to another using regexps is like a little 6-year-old girl thinking she can bake a huge wedding cake with an easy-bake oven and a 20 watt lightbulb. Take a compiler class, kiddo.
Comparing implementations of the languages certainly does count in this case, because of the EXTREMELY HUGE difference between the most popular JavaScript implementation (SpiderMonkey), and Lua. They are totally at opposite ends of the spectrum. When comparing speed and memory usage, Lua's score is 41.7, and SpiderMonkey's score is 4.7. How do you explain that Lua's score is 8.87 times better than SpiderMonkey's score? Yes, SpiderMonkey does compile into bytecode, so it's not because it's interpreting the parse tree directly.
You should study the history of Lisp design and implementation, as well as Haskel, and of course Self, and even C++ and Java, if you want to understand how to design programming languages that can be compiled into efficient code. Then you will understand why PHP and JavaScript will never run fast, and why it's no surprise that they're the bottom losers in the computer language shoot out. There is such a thing as cause and effect, you know.
-Don
You don't know eiter Lua or JavaScript very well, if you actually think you could convert between them with a "a couple of regexps and a small compatibility module".
If you really think JavaScript can be made to run as fast as Lua, then can you offer an existence proof, or explain why SpiderMonkey is so much slower than its potential? Why is it so slow and inefficient, and why hasn't anyone done anything about it?
-Don
Yes, you're reading the code wrong, because it's very tricky. The event is not used to click on a confirmation button (that would be impossible), it's used to trick the browser into executing a JavaScript function in a different (trusted) context, where it can directly call the addBookmarkForBrowser function (which normally can't be called by untrusted code). The way it does that is to add a getter method hook to the head element "ownerDocument" property, so the hook gets called in a totally different (trusted) context when the dummy event is handled. The trusted event handling code foolishly accesses the head element's "ownerDocument" property, which calls the code provided by the untrusted web page, in a trusted context.
-Don
So you're saying it's ok for the browser to leak references to internal functions, because your user interface guidelines dictate that it's a bad idea to call those particular functions (even if my clients dictate they want a button that does that on their web page)?
My point, in case you missed the sarcasm, is that Firefox's JavaScript implementation is so complex and tangled that it leaks pointers to functions that web based scripts should not be able to call. If you can call the function to add a bookmark, then what kind of other functions are sitting there waiting to be cherry picked and called by maliscious scripts?
-Don
Oh yes there is quite a lot about Lua's design that make it inherently much more efficient that JavaScript. Why do you think it's SO MUCH faster and smaller -- mere coincidence?
Have you ever looked at either the Lua source code or the SpiderMonkey source code, or compiled either of them yourself, or are you just pulling that statement out of your ass?
-Don
Here's the "standard" way to add a bookmark to the current page in Firefox:
So it's a good thing that Firefox's JavaScript interpreter leaks references to internal functions that web scripts aren't supposed to access. Because some of them are useful, interesting functions that are fun to call!
-Don
That's too bad about FireFox being essentially written in JavaScript. SpiderMonkey, the JavaScript interpreter in Firefox, is BY FAR the worst programming language (in terms of speed and memory use) of them all, according to the Computer Language Shoot Out.
When you compare all the languages on CPU time, SpiderMonkey JavaScript is twice as slow as the second worst, Ruby.
When you compare all the languages on memory usage, SpiderMonkey is 1.7 times as bloated as the second worst, Smalltalk Visual Works.
When you compare all the languages on CPU time AND memory usage, SpiderMonkey is 2.1 times as bad as the second worst, Smalltalk GST.
Firefox would be much better off using Lua, which is much easier to integrate with C code than SpiderMonkey's nightmare sausage factory, much faster, much smaller, and a vastly better language design. The fact is, that good language design has a huge effect on speed and memory usage -- you can't just stick your head in the sand and pretend good language design isn't important, like the PHP and JavaScript designers originally did and still do. Bad design paints your bad implementation into a bad corner, and there it stays.
Here's how Lua and SpiderMonkey JavaScript stack up against each other. Lua TOTALLY smokes JavaScript, in every category, by a long shot. It's not even funny -- it's tragic. Face it: JavaScript is not only a horribly designed language, but SpiderMonkey is also a horrible implementation of that horribly designed language. So it's not surprise that SpiderMonkey has always had gaping security holes, to complement its horribly slow speed and extremely huge size.
-Don
Don't you guys trying to optimize your software bubble sorts realize that these days, all the fast sorting action is happening in hardware accelerated Bubble Memory?
Plus, Bubble Memory is much more secure and less obnoxious than Flash Memory (which everybody hates because it has major security holes and displays annoying advertisements).
-Don
Another advantage of standardizing computers to be shaped like human heads: Rich computer-phobic people can hire real humans to sit under the table and stick their head up through a hole.
-Don
Math is hard, so the Barbie PC uses the Pentium to guess at the answer in software.
-Don
Steve Jobs already turned down the sexiest shaped computer possible (well, excluding naughty bits):
(from "The Second Coming of Steve Jobs")
With a case like that, you'd need to hire a Phrenologist to fix your computer when it goes on the fritz.
-Don
Well FYI: text == graphics, in case you didn't notice. Ever hear of fonts, glyphs, unicode, typesetting, layout, flow, justification, css styles, colorization, syntax highlighting, selection, cut and paste, drag and drop, scrolling, outlining, collapsing, linking, etc? So yes, texual user interfaces == graphical user interfaces, unless you're reading text as braille.
-Don
Read the article I linked to: it describes how TOPS-20 programs and commands can document themselves to the CLI, so it can provide the user with consistent completion and full help about the parameters, insert (and ignore) noise words, and provide completion over alternative symbol spaces for special types of arguments, like host names. That was quite useful when ARPANET addresses were only 8 bits long, and you could type "teln mit-?" to get a list of all host names beginning with "mit-" that you could telnet to. TOPS-20 command line help and completion is much more comprehensive and standardized than the hodge-podge of Unix shells and utilities and weird scripting languages and quoting conventions like: find . -name '*~' -exec rm "{}" \;
-Don
The designers of TOPS-20s understood how "human engineering" and user interface design applied to command line interfaces and language design.
-Don
http://www.linique.com/dlm/tenex/hbook.html
Origins and Development of TOPS-20
by Dan Murphy Copyright (c) 1989, 1996 - Dan Murphy
Another area where TENEX, and later TOPS-20, excelled was in the user interface, described in detail below. A key reason that we were able to extend the user interface so significantly is that the code which implemented it ran an an ordinary user program. Hence, it wasn't constrained by size or limited by functions which could not be performed in kernel mode. Beyond that, debugging it was much simpler -- it didn't require stand-alone use of the machine as did kernel debugging. All of this allowed a great deal of experimentation and evolution based on tuning and feedback from real use and real users.
User-oriented Design Philosophy
A piece of system design "philosophy" had emerged at BBN and among some of the ARPA research sites that was to have a large impact on the overall feel of TENEX and, ultimately, TOPS-20. At the time, we called this "human engineering" -- we wanted the system to be easy to learn and easy to use, and we wanted the system to take care of as many grungy details as possible so that the programmer or user did not have to deal with them. Beyond that, we were willing to spend real machine cycles and real (or at least virtual) memory to make this happen.
This philosophy led initially to the human interface features of the EXEC, including "escape recognition", the question-mark help facility, optional subcommands, and "noise" words. Few people now argue against the need to provide effective human interfaces, but at that time there were many detractors who felt that it was a waste of cycles to do such things as command recognition. These kinds of things, they said, would "slow the system down" and prevent "useful work" from getting done. Other contemporary systems used short, often one-letter, commands and command arguments, provided no on-line help, and did not give any response to the user other than the "answer" (if any) to the command that had been entered.
Computer use by non-experts
Many such systems fell into the "by experts, for experts" category. That is, they were built by experts and intended to be used by other experts. An "expert" would obviously not need frivolous features like noise words or command recognition. Experts would know, not only all the commands, but all the legal abbreviations as well. Experts may have read the manual once, but would always remember everything needed to interact with the system. So went the implicit assumptions about users -- either you were an expert, or you were an inferior being not really entitled to use the Computer anyway.
The TENEX team took a different view. It was clear that the power of computers was increasing every year and so one should expect the computer to do more and more interesting things. Most people would agree that a major purpose of computer automation is to relieve people of boring, repetitive tasks; we believed that purpose extended to computer system development as well, and that it was wrong to require a person to learn some new set of boring, arcane tasks in order to use the computer. The machine should adapt to man, not man to the machine.
The view was probably reinforced by the artificial intelligence research being done in the environment where TENEX was designed. In such areas as speech recognition, pattern recognition, and natural language comprehension, massive computation power was being applied to make computers interact in ways that would be more human. These were long-term efforts, but we wanted our computer systems to be more human-oriented in the sort term as well.
One of the ideas to come out of the AI re
I think there are some good lessons to learn from TCL/Tk, that can be applied to Lua gui api design! (But not to the Lua language design! ;-)
TCL was popular because of Tk, which was the best X11 user interface toolkit of its time. One reason Tk was so successul, was that the Tk toolkit was tightly integrated with the TCL scripting language, and they nicely complemented each other. Tk called out to the TCL scripting language to do most of the work, instead of trying to do all that string bashing, table lookup, configuration, plugging together and scripting stuff in C, like "Xt" (the Ech-StoolKit) and Slowtif make so awkward. So it was quite easy for Tk programmers to configure guis and script callbacks with TCL, without having to modify and recompile any C code. TCL worked well with C because it nailed something that C sucks at: string processing.
In the same way, JavaScript is popular because of Dynamic HTML, not because it's a good language. The killer app is really DHTML, and JavaScript is just along for the ride. Outside of the realm of Microsoft's ActiveX/OLE/IScriptingEngine, it's difficult to integrate JavaScript with C. But languages like TCL and Lua, and tools like SWIG make that easy.
I'm optimistic that some form of Lua will eventually find its way into common use for scripting web browsers, and even more interestinig stuff like 3D virtual worlds ala WOW and There. It will spread through the same as the Flash virus used to infect 98% of all desktops (ActiveX, Netscape plug-in API), and other even more infectious vectors: computer games. The WOW and There clients are basically just smart 3D VR AJAX engines, scripted in Lua. WOW, Lua's already There!
-Don
Yes, Auctioneer is very pretty code, and it does a lot of sophisticated stuff, too! Every time I log into WOW, I let auctioneer scan all the auctions and update its tables of market price statistics, and once it's done (about 7 minutes of downloading), it presents a list of the most profitable auctions that are expiring soon, and the expected profits. I've snatched up strange items like "Elemental Fire", and turned them around for huge profit. Every object you point at can pop up stats about its expected auction price. Some people use Auctioneer regularly (and game the auction house) to make real money (selling WOW gold for real cash).
The "cosmos" ui and "thottbot" service is an even more elaborate set of WOW extensions, all scripted in Lua. It gathers statistics on EVERYTHING you see in the game, and uploads the data to the central server, which hosts discussion boards for every location, object, non player character, quest and magic spell in the game. It's like a real time screen scraper that spys on WOW's data stream, which it can do efficiently because so much of the game is exposed to Lua, and all events are reported to the scripting language!
-Don
Yeah, I had a great fling with TCL/Tk, which was the best thing around in 1992, but I'm really glad it didn't become the Standard Scripting Language. As bad as it is, I can live with JavaScript.
Remember RMS's Great TCL War? "Why you should not use Tcl"? But that only got more people interested in TCL. But Sun hired the authors of TCL to make it the universal scripting language of the Internet, and then squashed it with Java, so Sun deserves credit for wiping out TCL's chances of world domination, not RMS.But RMS was right when he said: If Tcl does become the "standard scripting language", users will curse it for years -- the way people curse Fortran, MSDOS, Unix shell syntax, and other de facto standards they feel stuck with. He forgot to mention Perl, and PHP was just being ill-conceived in 1994.
Of course the FSF was developing GUILE as an alternative to TCL/Tk. But Lua also has all the properties that Stallman recommends for an extension language: it's a real programming language for writing and maintaining substantial programs, with arrays, structures, numbers, semantically lisp-like, but with a traditional algebraic syntax, and extremely fast execution. And it's under the MIT license (ahem), so it gets used in real world commercial products (WOW).
But there are other important properties for a scripting language that he doesn't mention. Especially: Easy integration with C and native libraries, which is hard to get right in a Scheme system that efficiently supports full continuations. Easy integration with applications and libraries is essential!!!
The final straw that made me decide to use Lua instead of SpiderMonkey JavaScript, was that SWIG supports LUA well, but it doesn't support SpiderMonkey. That's very important to me, because by using SWIG instead of a language-specific binding (tolua++, boost, etc), SWIG makes it easy to plug my libraries into ANY scripting language (except JavaScript ;-).
-Don
Sheez, do I have to deconstruct it for you? The expression means that GIMP wastes a lot of your time, which is not a problem if your time is worthless. But most people value their time as priceless, so it costs them too much to use GIMP. By wasting your own time, you're certainly not hurting Bill Gates or John Warnock.
-Don
The "command --help syntax" is certainly not supported by all Unix programs, and it's much less convenient and comprehensive than TOPS-20's built-in command line completion, which every utility and application supported. TOPS-20 is so 1969 -- why is Unix still so far behind?
Yes, programming languages, scripting languages and command line interfaces certainly are user interfaces, because programmers are users of programming languages, which allow programmers to interface with the computer, tell it what to do, manipulate its internal state, build models, call functions, etc. And many of the guidelines that apply to designing graphical user interfaces also apply to designing textual programming languages. Yes it does matter if a programming language or command line interface is badly designed and hard to use.
Do you really think PHP, one of the most popular badly designed scripting languages, is "optimized for people who use it a lot"? No, it's optimized to be "useful" for inexperienced people who have never used any other programming language before, who shouldn't be programming in the first place, to quickly and easily introduce gaping security holes in networked computers.
PHP is the classic example of a badly designed user interface for programming computers, with deeply rooted design flaws that empower users to shoot themselves in the foot (with an automatic machine gun) while swinging by the neck from a noose (automatically tied for them). PHP "features" like magic_quotes_gps and register_globals were bad user interface design decisions, that the authors of PHP should have never made, if they thought of language design as user interface design. (Especially considering the kind of naive users they have programming PHP scripts.)
-Don