function fac(x){ return x==0?1:x*fac(x-1); }
  a = fac(8);

  or a one-liner:

  a = (function fac(x){ return x==0?1:x*fac(x-1); })(8);

Personally, I have never found much of a reason to use the Y combinator. I typically use the method you used in the second example; I declare a named function within the scope of the anonymous one. I find it to be a readability win.

But I agree with you that Y combinators are not generally a good approach for working programmers because there are clearer ways of accomplishing the same thing. However I've heard that in some functional languages they can be very useful as a pattern to compile language constructs to.

http://foohack.com/tests/ycomb.html

a = (function(x) {return x == 0 ? 1 : x * arguments.callee(x - 1)})(8);

  builder   = function(x){ return function(n){ return x(x)(n); }}
  factorial = function(f){ return function(n){ return n==0?1:n*f(f)(n-1);} }
  alert(builder(factorial)(8))

  r = (function(x){ return function(n){ return x(x)(n); } } (function(f){ return function(n){ return n==0?1:n*f(f)(n-1);} }))(8);

* Bought Symbian and open-sourced the entire OS.

* Bought Trolltech, relicensed the Qt toolkit to LGPL, and developed new Python bindings from scratch.

* Poured investment into Maemo, including 3G phone support (check out the upcoming Nokia N900).

They're just testing the waters with this new Windows 7 notebook. (Did you notice that the screenshots are mostly showing Ovi Suite 2.0 which is Qt-based and will be available on Linux as well?)

i wonder how much a h/w platform or pre-installed s/w would matter in one's life when a browser is your new OS and almost all your apps are on the cloud !!!

The web is great for some things, but some things aren't everything.

as far as h/w platform is concern it would be too early to make a call, we may think right now that intel will lead the market/platform as they now support both (PC & MAC) but i wont be surprised if there are new players... especially from taiwan and china!!!

And even if intel dominates the microprocessor market, I really wonder how would a common man will differentiate a MAC laptop with Lenovo's thinkpad because all they have installed is the same Browser-OS (chrome, safari etc.) on the same platform (intel), with the same specs(say 4GB RAM, 5 USB ports, 2HDMI, same display card.... etc.) and almost everything else is on the cloud .... i guess then it would be all about speed, power and exterior look/design of the laptop??!!!

I don't doubt that lots of interesting things will pop up on the web. But "browser-as-that-thing-I-spend-a-lot-of-time-in" is very, very different from any sane definition of "browser-as-an-OS".

visit: http://googleblog.blogspot.com/2009/07/introducing-google-ch...

Then the title is misleading. Rebol as an influence to what?

We should ask that question to Brendan to see what influenced HIM to design javascript as he did.

It would be better if you watched the video before commenting this.

def foo(n): lambda i: n += i

Give me two powerful languages with the same features and I'll pick the latter for its syntax.

So no, lisp may be the best right now, but it won't be the best forever, its syntax is its best friend and worst enemy.

Something lispers will never understand. Love is blindness.

I'd like to know, though: is that true? Is an abstract syntax tree the only good way to represent programs as data? Has any other expressive way to do this been invented, or do programs always boil down to an AST after the syntax has been stripped away?

I say "expressive" because I can think of at least one other code-as-data representation: binary. But that isn't suitable for programming. If there is another representation that is suitable, but isn't isomorphic to a parse tree, then presumably one could derive from it an analog to Lisp that doesn't simply reduce to Lisp. Until then, though, I think the point that PG made semi-jokingly in the essay, that any language as powerful as Lisp will be a variant of Lisp, has to hold true.

Some day I'd like to research this question (or better, someone on HN could just tell me the answer). If other meaningful representations are possible, surely some must have been invented by now. And if they aren't, then the AST is a considerably more remarkable discovery than people realize.

What would really interest me would be exploring that if human logic fundamentally reduces to a parse tree because of something to do with the language faculty of the mind, and the programming languages that we create tend towards that just because programming languages are built out of the same logical faculty.

That is actually an excellent question.

http://news.ycombinator.com/item?id=780853

Now, say I fork lisp and change one little thing:

(defun foo (n) (lambda (i) (incf n i)))

to this:

[defun foo [n] [lambda [i] [incf n i]]]

or even this:

{defun foo {n} {lambda {i} {incf n i}}}

or how about this?

<defun foo <n> <lambda <i> <incf n i>>>

Hmm, trees are powerful, no matter how they are expressed huh?

What if we can represent the same trees using colons and commas as delimiters?

:defun foo:n, :lambda:i, :incf n i.

Maybe spice it up a bit using periods as recursive closing delimiter.

See? still powerful trees!

Between common lisp and colon lisp, I still use the latter.

Love is blindness.

I don't see what you're trying to claim. Initially you seemed to be saying that you preferred conventional sytax to sexprs. I pointed out that this meant you had to give up macros. You reply that you could use other characters to delimit sexprs. Sure, but so what?

Ergonomics win.

The syntax in that first example you quote isn't arbitrary. It's essentially the only notation that exists for representing the structure of a program explicitly in language. Is that valuable? Uh, yeah. It's incredibly valuable. It's worth a lot more than syntax in many cases.

By contrast, the syntax in the second example is arbitrary: the delimiters and operators could just as easily be organized differently. Perhaps this particular organization makes certain programs clearer, but it loses the ability to represent programs in general.

If that doesn't make sense, think of the fairy tale of the goose that lays golden eggs. Everybody's obsessed with their particular golden egg. Lisp - precisely because of the difference visible in those two examples - is the goose.

There's nothing in this that PG didn't already express in his comment. But what you wrote deserves more than one protest :)

"0 based for spatial coordinates, 1 based for lists and character positions."

Sums up my thoughts pretty well.

The real reason we do zero-based counting in computers is because of bits, speed and laziness.

Computers were made to serve us and as such they should translate all their inner thoughts to more human consumable data.

Five is 5, not 101.

So no, numbering should start at ONE, even if most programmers have already been hardwired to start counting from zero.

We could still achieve the same effect if we started indexing at 1, but it would require more code, and it would be less clear.

Really?

How about dealing with strings?

"123456789" how many chars we have? 9

char[1] = 1

char[2] = 2

:

char[9] = 9

Now, let's try the C approach:

"123456789"

char[0] = 1

char[1] = 2

:

char[8] = 9

where is char "1"? at zero index!

how many elements we have?

last index plus one!

see? there is already confusion in place, or as you say, more code and less clear...

  ch[0] = 0;
  ch[1] = 1;
  ch[2] = 2;
  :
  ch[9] = 9;

  ch[1] = 0;
  ch[2] = 1;
  ch[3] = 2;

  ch[1] = 0;
  ch[2] = 1;
  ch[3] = 2;
  ...
  ch[10] = 9;

When we start indexing from 0, the only time we need to do a +/- 1 is when we need to index the last element. All other times (iterating, mapping) we don't need to.

Also, starting indices at 1 would change the idiomatic iteration to:

   for (int i = 1; i <= SIZE; ++i)

  for (int i = 1; i < SIZE + 1; ++i)

Read your post and understand the same can be said of using one-based indexing.

No, the only way there's no lump in the carpet is his way.

[1] thumb

[2] index

[3] middle

[4] ring

[5] pinkie

so we have a simple range [1..5]

which can be represented in so many ways in computer programs:

for i=1 to 5 print finger[i]

for(i in [1..5]) print finger[i]

my first finger[1] is my thumb

my last finger[5] is my pinkie

how many fingers we have? as many as the last index in the list: 5

-

now, C programmers like to count this way:

for(i=0;i<5;i++) print finger[i]

where finger[0] is thumb

and finger[4] is pinkie

how many fingers we have?

as many as the last index in the list plus one: 4+1

how human-like!

And that's why you get so messy when trying to get the string position of a substring:

if(pos>-1) exists, since pos=0 means the substring is in the starting position

again, how human-like!

But how dare I argue with C programmers without being burned at the stake?

4+1=5 never enters into it. What a rubbish argument. I might as well complain that your [a,b] has (b-a+1) integers in it. (5-0)=5 so the half open interval has 5 things in it.

What's the measure of a real interval 1<=x<=5? 4. 0<=x<5? 5.

We go from 1 to 5, so the math would be 5-1 +1

You go from 0 to 4, the math would be the same, 4-0 +1

Using 5 as your upper bound, then starting from 0 to 4 is the same as me using 6 as my upper bound then going from 1 to 5.

for(i in [1..5]) print finger[i]

You're using an inclusive upper range here. Not that that's necessarily wrong, but it isn't standard for the reason Dijkstra mentioned (how many fingers do I have? 5 - 1 = 4. Oops.)

Upper-Lower+1, easy. Whenever the lower is 1, just the upper is enough.

In your case you go from 0 to 4, how's that different from how many fingers you have? 4-0=4 Oops.

People are used, due to forty years or more of tradition in the great majority of major languages, to zero-based indexing. Tossing that away Because It's Inelegant won't do much good to anyone, especially when you take into consideration the fact that an awful lot of math is more convenient with 0-based indexing.

Now that I am older I try to go to bed the same day I wake up.

The older I get the earlier I want to wake up, the less I want to sleep.

Since WebSocket is not available everywhere yet, use a Flash interface (pure actionscript, no visuals) with the same methods: onopen, onsend, onreceive, onclose, to communicate with the server. So when WebSockets is available all you have to do is replace the flash object with the real stuff.

  mychat = new WebSocket(chatserverurl);
  mychat.send("Hello");
  mychat.send("Can you hear me?");
  mychat.send("Am I getting through to you");

XMPP supports this natively via its HTTP binding specification, and there are free open source servers such as openfire that will work with Strophe out of the box.

http://code.stanziq.com/strophe/ http://www.igniterealtime.org/projects/openfire/index.jsp