Switching to Wordpress?

As my post yesterday alluded to, I'm switching to Wordpress (at least for the time being). The entire blog has been transferred over there thanks to the import mechanism.

I invite my reader(s) to try the new site and tell me what they think. I believe that for users, Wordpress is a big win, but your opinion matters. Please leave comments on either side, I will be monitoring both. I will, however, be posting mostly on the Wordpress side.

Hello World - Switching to Wordpress?

This is a copy of my first blog post created on Wordpress

Following a comment I made regarding the controversy about the applicability to Wordpress themes of GNU GPL (the license under which Wordpress is distributed), I was invited to switch to Wordpress by its creator. It's hard to say no... So I created a Wordpress account and a blog. Wordpress creates a first blog entry for you. The title of this first post is "Hello World!". For programmers, "Hello World" is a very special thing. It is this small little program that prints "Hello World" on the screen. In C, it looks like this:

#include <stdio.h>
int main(int argc, char *argv[])
{
    printf("Hello world!\n");
}

The output of this wonderful little program on the console is the following:

Hello world!

To achieve the same result with my own programming language, XL, you'd write something like:

use XL.UI.CONSOLE
WriteLn "Hello world!"

The Hello World program is a small benchmark of what a programming language can do. For example, the team behind Google's Go programming language used Hello World to highlight their support for internationalization.

A 3D "Hello World!" in 23 lines of code...

So with such an exciting blog post title, it's only fair that I would use this post to show what Hello World looks like in the stuff we are developing at Taodyne:

The video is a bit skippy, but it looks smoother in real life. Apparently, there's something wrong in the combination of grabbing the screen with Snapz Pro X, creating a movie with iMovie and publishing on YouTube. Don't ask me why, I'm just the computer guy...

The XL axioms: reconciling Lisp and C++ hackers

Re-reading Paul Graham, specifically The Hundred-Year language helped me understand that I need to write down the axioms of XL. I need to describe XL's equivalent of lambda-calculus for Lisp. If there is such a thing.

Lisp inventions

In Revenge of the Nerds, Paul Graham makes a list of the 9 things that Lisp invented

1. Conditionals
2. Function types (i.e. functions as first-class items)
3. Recursion
4. Dynamic typing
5. Garbage collection
6. Programs composed of expressions (no statements)
7. A symbol type
8. A notation for code using trees of symbols and constants (programs as data).
9. The whole language there all the time (no distinction between load time, compile time and run time).

Of these, many became part of mainstream languages over time. Some remain the exception rather than the norm.

What makes XL unique

Later in that same essay, however, Paul Graham unknowingly explains that makes XL unique in my opinion (emphasis mine):

Macros (in the Lisp sense) are still, as far as I know, unique to Lisp. This is partly because in order to have macros you probably have to make your language look as strange as Lisp. It may also be because if you do add that final increment of power, you can no longer claim to have invented a new language, but only a new dialect of Lisp.

What XL demonstrates is precisely that you can have Lisp-style macros (and in fact build a whole language on macros) without the hairy syntax. Here is how you use 'if then else' in XL (whether the imperative variant XL1 or the functionalish variant XLR):

    if A < 0 then
        write "A is negative"
    else
        write "A is positive or null"

This code should look really familiar to users of other languages, I would hope. Yet under the hood, it corresponds exactly to a simple parse tree similar to what Paul Graham refers to in his point #6. Here is what that parse tree will look like if you expand it:

% ./xl -parse ifthenelse.xl -style debug -show
(infix else
 (infix then
  (prefix
   if
   (infix <
    A
    0))
  (block indent
   (prefix
    write
    "A is negative")))
 (block indent
  (prefix
   write
   "A is positive or null")))

The big difference with Lisp is that Lisp, as Paul Graham points it out, has no parser. XL has a simple parser, but a parser nonetheless.

Axiom #1: A simple parse tree improves code readability

This leads to axiom #1 of XL: you can parse text with 8 node types or less. The 8 node types currently found in XLR are:

1. Integer: Numbers like 1234
2. Real: Numbers like 3.1415
3. Text: Literals such as "ABC" or 'X'
4. Names and symbols: Names contain letters and digits, like HelloWorld or X0, symbols contain other characters such as ; or ->
5. Prefix: Adjacent nodes where the first one defines the operation, such as sin x or -3.
6. Postfix: Adjacent nodes where the second one defines the operation, such as 3! (factorial of 3) or 24in (24 inches)
7. Infix: Adjacent nodes separated by a name or symbol which defines the operation, such as 3+4 or X and Y
8. Block: A node surrounded by separators, such as (24-3) or the second half of the prefix A[3].

This can be reduced to less than 8 relatively easily: the real and integer types could be merged into a "number" type, the prefix and postfix could be merged into a "positional" operator, which could be made more general, for instance allowing "above" and "below" notations.

In practice however, the choice currently implemented in XL is a practical trade-off. For instance, the natural computer representation of integers and real numbers are different, so it makes sense to treat them as separate from the beginning.

Of note, in XL, indentation is represented by a block, and line separators are just another kind of infix.

The benefit of this representation compared to the Lisp representation is that it is only marginally more complex (4 constructed node types instead of one, the list), but allows us to parse things much closer to the way humans do. For instance, XL will parse 2+3*6 the right way.

Axiom #2: Programs can be evaluated with macros

Despite what Paul Graham says, Lisp really has two "modes" of operation: macros/compile-time and evaluation. The distinction is subtle: Macros (and compilers) evaluate one program to transform another program, whereas evaluation evaluates the program itself.

In the XL1 compiler (the XL imperative language), the distinction is more marked than in Lisp, whereas in XLR (the XL runtime language), it is less clearly visible. Let me illustrate with an example of each.
In XL1, you would define a recursive factorial as follows:

function Factorial(N : integer) return integer written N! is
    if N = 0 then
        return 1
    else
        return N * (N-1)!

That example looks really similar to what you would write in C or Ada or whatever other imperative language you can think of. But the parse tree is there, not too far. One example is the notation written N!. This allows the compiler to recognize that (N-1)! is really a call to Factorial. This is called expression reduction. This is already quite useful, but basically it's a compile-time only thing.

Under the hood, however, the XL1 compiler uses the exact same mechanism to recognize (N-1)! and to recognize if-then-else. The exact same macro rewrite mechanism is at play. In fact, you can extend the compiler easily with your own "macros", so that for example you could write d/dx(sin x) and have the compiler rewrite it for you as cos x. This particular differentiation plug-in has been in the compiler for several years now.

In short, the language looks imperative, but it's implemented as a big set of macros.

By contrast, in XLR, you would define the same function as:

0! -> 1
N! -> N * (N-1)! 

The code is much shorter, because XLR basically has only one built-in operator, which is the macro rewrite operator ->. XLR is little more than a big macro pre-processor. Now, if XLR happens to dynamically generate machine code using LLVM to evaluate this quickly enough, it's just an optimization, an evaluation strategy.

As a result, in XLR, evaluation and macros are practically the same thing, even more so than in Lisp in my opinion.

Axiom #3: C+ hackers and Lisp hackers are both right

Depending on whether your favorite language is C or Lisp, Ada or Haskell, Java or Python, you may prefer the first or the second approach. It's really a matter of taste, and after years of healthy competition, the two camps are not any closer to being reconciled

What XL brings to the table is a single technology that demonstrably can do both.

Axiom #4: It works, almost

Well, today, XL does neither too well, mostly because the technology is not finished. It has never stopped making progress in the years since the project began, though. If you want to contribute, go to the XL web site

XL: Advancing the state of programming languages

This is the 200th post on this blog!

The WGP2010 workshop was a good occasion for me to write a short summary of where we stand with XL. With the creation of Taodyne, I'm spending much more time working on XL and with XL. This may not be immediately visible, thought, because XL is only a tool to achieve Taodyne's objectives, it is not a goal in itself.

The article's title is "Eliminating Newspeak in Programming language". Here is the abstract:

Programming languages provide us with numerous tools. But like the fictional language Newspeak in George Orwell's 1984, they also restrict what we can say, and in doing so, they shackle our minds. As a result, historical programming language all became an economic dead weight as soon as the hardware, fueled by Moore's law, passed them by.

XL is a programming language designed to get rid of this Newspeak in programming. Its primary focus is to help programmers add their own concepts and their own notations to the language. To validate this approach, many of the traditional features that XL provides are constructed, not built in the compiler. The associated methodology is called ``concept programming''. It focuses on the transformation of ideas into programs.

Writing an article about XL made me realize two things and a half:

1. XL remains novel and relevant today. Ten years after I first shared code, the problems that XL addresses are still there, the solutions are still nowhere seen in other languages.
   
2. On the other hand, the language never caught on. But then, the article, if accepted, will be the first one I ever wrote about XL for academic circles. From that point of view, it's good to have left HP.
3. XL is still evolving, and the compilers are still far from being finished... Shame on me.

So I think that XL is really capable of advancing the state of programming languages, but I need to put some additional muscle to explain what it is. Or as a friend reminded me yesterday: "It goes without saying, but it goes better saying it."

From concept to code

The first key idea behind XL is that the role of a programming language is to help us transform ideas into code. The idea seems simple enough... until you dig deeper and realize just how hard this is. This presentation is a good starting point...

What does it mean to you, to transform ideas into code? How well do the existing languages do that for you? Do you sometimes feel impaired in the way to write your code? Are there things that you simply can't say with your favorite programming language? Do you have funny horror stories about saying one thing and having the compiler understand an entirely different thing?

Linus Torvalds on religion

Linus Torvalds, original creator of Linux, writes in his blog:

One of them starts to seriously talk about praying demons away, and then after the prayer has driven the demon out of the person, you have to support the person so that the demon doesn't come back. And nobody laughs at him.

Seriously? What year is it again? I'm pretty sure they didn't have Costco foodcourts in the middle ages, but maybe there was some time warping going on.

What the hell is wrong with people?

There is a large number of comments (169 to this date). Very few of them are critical of Linus at the beginning, but then a few start voicing a different opinion. And Linus Torvalds answers with gems like:

And yes, it is acceptable to ridicule people for their beliefs. If you meet a grown person who believes in the easter bunny, in santa claus, or in the tooth fairy, they're damn well fair game.

Seriously, what's wrong with Linus Torvalds?

If someone doesn't know something, you educate them. You don't run back home and cowardly post blog entries mocking your "opponent" to a friendly crowd! This is really not Linus Torvalds' most glorious moment...

What I find more annoying is just how religiously illiterate Torvalds is, and how that doesn't stop him from believing he knows everything about everything. He is not alone in his belief that to be religious, you have to be stupid.

Facebook privacy policy

This might be interesting for folks using Facebook...

Patents considered harmful...

In the wake of the HP's acquisition of Palm, Technologizer ran a story about some Palm patents showing Palm gizmos that could have happened. Except that they didn't.

Something bothers me about all these patents: the majority of them describe items that couldn't possibly have been built at the time the patent was granted. Video-conferencing on a Palm Pilot? Seriously?

To me, this begs the question of whether it is sufficient to describe something to be able to patent it, irrespective of whether you have the technical capability to built it. If so, then StarTrek writers probably have patents on a number of useful technologies.

If you don't have a safeguard against "innovation" that is little more than a wild idea about something that might exist some day, then you open the doors for patent trolls, since they don't need to ability to build the stuff, only the ability to talk about it.

Any engineer will tell you: anybody can have a good idea. It's building it that is hard. I believe that patents were intended to promote real innovation, not just random ideas.