Post Archive

› September 5, 2004

JavaScript Quine Contest - last week

  • Reported by liorean

Just a quick summary of the JavaScript Quine Contest (started last week) so far: Six persons in total have submitted entries. Four of these have produced one or several valid quines. The contest will run this week out, so there is ample time for you to write and submit your entries.

Well, that was the summary, now let's blather a bit...

On the Javascript language

JavaScript has, if you ask me, far too bad a reputation compared to it's power and expressiveness. It has since the beginning been a very powerful but still simple language, and has since then been polished a bit. The cause for this bad reputation is mostly caused by one reason: it was developed by Netscape for use inside the browser. It's been strongly connected to just that host environment, and those who have used it have abused it for popups and right click prevention, instead of using it for the good of the user. At the time JavaScript was created, CGI using shell scripting, PERL, AppleScript or C/C++ were what we had on the server side. Netscape of course made serverside JavaScript an addition to their servers, but the damage was already done. JavaScript was in the minds of the public bound to the browser. So happened the server side revolution, and we got PHP, ASP, JSP and server side Python. JavaScript on the server never grew large, and probably never will. JavaScript never reached any momentum in the application scripting side either. This is what I consider the two greatest losses for the language. JavaScript is a higher level language that has had lots of testing and optimisation behind it. It has a positively huge user base, and it probably the scripting language that is most spread of all. Of the languages mentioned Python is the one it closest resembles - Python, the holy grail of the functional programming paradign of programming today. That could have been JavaScript, they share most of the important concepts.

I started this contest in an effort to get more people to recognise that JavaScript the language is no ugly beast forever strapped to the browser. It's a powerful, easy-to-work-with multiple purpose language that can do some amazing things in just a few characters. It's a language that makes programming faster and easier, a language that makes programming fun. Sure, JavaScript isn't perfect in every aspect, but most of it's weaknesses are related to the fact that it's bound to a limited host environment and has no good set of standard libraries. Things like file handling, standard input and standard output are missing from the core language and are not present in the most common host environment, because the most common host environment has other input and output mechanisms. Still the core JavaScript language is small and powerful - what I would call a beautiful language. In the conceptual realm it might be somewhat more complex than LISP or SmallTalk; but the complexity is mostly optional concepts that makes programmers used to Pascal, Java or C/C++ more at home with the language. JavaScript may be used for imperative, functional, structural or object oriented programming depending on what style the programmer is more at home with, something that only works to strengthen the language.

On the contest

Well, I've had quite a deal of correspondence with the people who have submitted quines to me, so I'll go through a little theory about quines here.

First of all, the quines are JavaScript and not HTML, so forget all about script elements and such. The only thing that should be required for the quine to generate it's own JavaScript source code is the quine itself.

As an extension of that, there is no need for any document.write, alert, prompt or DOM function calls. They won't help a bit. Just make sure the return value of the last statement in the quine is a string containing the source code of the quine.

Second, the method of testing the quine for validity that I posted was just one of a number of ways. Notably it might not work if you use the % character inside of your quine. So, what do if that is the case? Well, just replace % by %25 when you test it. If you don't want to do that you can use a tool such as Hixie's JavaScript Evaluation Sidebar.

JavaScript quine theory

Well, then on to the theory of quines in JavaScript. A quine is a program that when evaluated returns it's own source code. And we know that by necessity a string may not contain it's own definition, because you can't contain the string delimiters for a string within said string. Well, not without escaping them, anyways. But when you escape the string delimiters you need to represent the backslash that escapes the string delimiters by escaping it. And when you need to do that you need to escape that character, and so on ad infinitum. So, how do you get around that?

Well, effectively you need two or more expressions. The first expresison which applies a function to a second expression, and the second expression which contains the code that generates a string containing the code applying the first expression to the second expression when it is applied to the first expression. Did I lose you? I don't know if I can explain if much better than that. I'll instead go on discussing strategies.

There are a number of strategies that you may use for creating a quine. You may use a function wrapper that uses regular JavaScript escapes to generate itself. You may use decimal numbers and String.fromCharCode, you may use unescape, you may use either strings or regular expressions together with string replacements, you may use the eval the evil™, you may use function constructors. You may use an expression list or multiple statements. You may combine these in nasty ways. (When writing this I almost wish I added a Most Obfuscated Quine category to the list instead of that Fastest Quine category.)

Another thing to think about is redundancy and redundancy reduction. Is there a reason why I declare this variable here instead of entering the expression in place of the variable? Can I move this function call to surround the expression instead of follow after it? Can I avoid escaping this or that character somehow? Do I really need to do so many string concatenations, can't I merge them somehow? Is that your teddy bear in the corner? Can I use a single pair of parenteses instead of a double pair? Begin with a quine of whichever size you can make it, and then reduce from there. Do some meticulous pruning and leave only what can't be reduced away. Drop that semicolon you didn't need anyway. Go make dinner or at least take a break from thinking about it, and when you come back maybe take a quick peak at Netscape DevEdge JavaScript Central for inspiration before you start again.

Finally, remember that quines are not made to be useful. Quines are made to be fun and a challenge for your mind, and hopefully you'll learn something in the process of writing them. So, take on the challenge and write one.

Comments