There's a point I make in my *Introducing the Ceylon Project* presentation that's been widely misunderstood (perhaps mainly by people who're *trying* to misunderstand). Since I've been criticized over this in several venues, it merits a response. The offending statement is the following:

- Java’s syntax is rooted in standard, everyday mathematical notion taught in high schools and used by mathematicians, engineers, and software developers
- not the lambda calculus used only by theoretical computer scientists

Of course, now that I read this back, I admit it's quite unclear what I'm trying to say here. In my defense, this was from a presentation slide for a small conference in China that somehow wound up on slashdot. The context of the statement is a slide where I list some reasons why I think Java was a successful mainstream language for business computing. It's really quite a small point and it doesn't especially matter whether you agree with it or not.

So, a bunch of people have decided that what I'm trying to say is that somehow Java is better or more mathematical

than the lambda calculus or something. Well, this interpretation doesn't even make sense. Java is a programming language. The lambda calculus is a formal system for studying the mathematical behavior of functions. So it's clear that this *can't possibly* be what I mean.

Now, I understand that in these days where the gotcha

demagoguery and cheap-point-scoring of cable news, twitter, and blog comments have substituted for thoughtful intellectual debate, many folks aren't aware of the idea of reading arguments according to the principle of charity

, that is, searching for the most charitable possible interpretation when the author's meaning is unclear. But I'm an old-fashioned type of guy, and I'm still surprised by this lack of ... hmmm ... *courtesy?*

Anyway, since we know - starting from the assumption that I'm not a total idiot - that I can't possibly be trying to say something totally idiotic, let's ask ourselves what is it that I was *actually* trying to say. (I'm afraid my real meaning will turn out a bit disappointing, after all this fuss.) The key to understanding is my use of the word syntax

. Focus on that word for a second. What I mean is that Java uses a notation for function invocation, for example, `f(x,y)`, that is taken directly from everyday mathematical notation used in engineering, science, and applied mathematics. It doesn't inherit the notation in which the lambda calculus is usually expressed, for example `f x y` or `\x y -> x*y`. I'm talking about *notation*. I'm not talking about the actual semantic relationship to the lambda calculus or any other mathematical concepts or formal systems.

Now, there might be perfectly good reasons why a language might want to use the notation in which the lambda calculus is usually expressed. There might be problems where this notation is simply less clunky. All I'm arguing is that it's a barrier to readability for a language intended for business or scientific computing. Again, it doesn't really matter to me if you agree or not.

Now waiting for a flood of apologies from all the folks who've called me ignorant

over this. I'm looking especially at you, Scala fans ;-)

I don't usually post a lot on the web because I'm an old programmer Enterprise busy guy. What you already given to the Enterprise world with Hibernate and CDI is just massive accomplishment. The best of luck for Ceylon.

Seriously Gavin, you can't be surprised about all this, can you? Remember the Hibernate then JPA days. Remember the WebBeans then CDI spec days. This infoQ

could only end up like that.Yet again who cares about a bunch of stoned dorks who can't but criticize? They are frustrated to be stuck in their cubicle because of their lack of brains and creativity, and jealous not to be the ones really making the industry change. Let them rot in their tweets.

The few ones that know what it takes to do what you're trying to do (especially as Ceylon aims at being Java-as-if-made-in-the-21st-century), are too respectful for the work achieved in only 2 years to be wililing to comment at this point.

In my view there are other reasons why Ceylon started. Java needed yet another a leap forward, right? CDI was a big fish. There's a cetacean ahead this time, if you see what I mean.

Wishing you good speed this time again.

I think you are all missing something very important. There is a reason why Lisp is language of the gods, it has the coolest language video ever: http://landoflisp.com/

No Cool Video? No Thanks!!!!

Mark

Your no way in hell ignorant! Seeing the reactions from the people from your last post is what I call ignorant. As Garcia pointed out, you have given a lot to this enterprise world. And everyone of those projects you have started were Open Sourced from the beginning, what more can the community ask for!

Seriously ... we need more people like you in this world. People like you drives innovation forward. You give motivation for people like us to continue what we do best!

So thank you! We are all looking forward for Ceylon, and hopefully you will accept contributions from the community to really make this project great for all. We all understand the Java frustrations you guys were having, and hopefully this will work out.

x:Natural;

is obviously more "mathematical" notation-wise than

Natural x;

In many functional languages, you have the well known arrow notation, so you'll see stuff like:

f:X->Y

which obviously is extremely common in math books. I find it much easier to read X->Y than syntax like Func<X,Y>.

There are other examples, like ML-style pattern matching, tuples, comprehensions etc which are more similar to what you find in math textbooks than how you would do it in Java.

Also, in many languages you can define functions with this or very similar syntax:

let f(x) = x + 1

In Java, you have to write a lot of "non-mathematical" tokens in order to express the same function.

I guess the average user of Haskell, Scala or any ML descendant language would disagree with your statement that Java is rooted in everyday mathematical notation.

If closeness to mathematical notation would have been important for a programming language in order to succeed in the enterprise space, I believe ML and it's descendants would have been far more popular than Java. I suspect the reason that Scala looks quite scary/complex to many (most?) Java programmers is because Scala *is* rooted in mathematical notation, way more than Java is.

You should mention that Java use

practicalsyntax used by every sane language since C. Or even shorter: we dont like Haskell syntax. :)Ceylon keeps the focus on readability, simplicity. Producing better code is the key. The mantra: readability for business or scientific computing. Go beyond the pseudocode with its lack of mathematical notation. If code isn’t clean, it can bring any project to its knees. We need code that is sound and efficient. We need to produce cleaning code on the fly, not coding standards or emergent patterns.

Gavin, we celebrate your courage, your vision.

I also agree with this,Go Gavin ,give us another great piece of tech.

Jarle, those are all very reasonable points, well-made, and I'm not going to dispute any of them. Indeed, fans of FP have plenty of good reasons to think that functional languages are

than the C family of languages. I'm not sure that this is especially interesting to me personally, mainly because it's not clear to me that is really in the end very meaningful here. Sure, a functional representation of an algorithm is better if you're interested in correctness proofs, but I don't see how having a correctness proof of a functional algorithm means you can't still go ahead and actually implement the algorithm in a procedural language. I mean, if you're really working with a mathematically-inclined brain, surely you can handle dealing with a couple of different levels of abstraction? And really, exactly how many of the folks using functional languages for practical business or scientific computing are really doing correctness proofs in the first place? In my (quite outdated) experience, applied mathematicians and physicists aren't any more interested in correctness proofs for their programs than folks in business computing.But again, I simply wasn't trying to make this argument in that slide. My point was a

muchmore narrow point about the readability of the expression syntax in e.g. ml, haskell, and lisp. I think many people would find these languagesmucheasier to read if function application looked likef(x,y).Well, yes, perhaps that was naive. OTOH, I had got the impression that the PL community was a bit more gentlemanly and openminded - at least that's the impression I got from the reading lambda the ultimate. :-)

It seems to me that you are slightly confusing things by conflating

with . What Lisp has that uses the word is merely an anonymous function; the fact that is uses the keyword is of no importance at all. Yes, ordinary math notation uses to mean application of function f to the values of x and y. High school algebra class doesn't teach you any notation for anonymous functions. I do not think that's a good reason to leave anonymous functions out of a programming language. And in my own opinion, having some syntax for them isn't going to repel or confuse people, as long as you pick something not entirely tastless. If you don't like anonymous functions for some reason, that's fine, but saying that it has something to do with isn't illuminating, in my opinion.Nope, I'm not conflating them, but some folks have read two unrelated slides from different bits of the presentation to be related. :)

Right.

Right.

Agreed. That's not the real reason for leaving them out :-)

The main reason for leaving them out is that coming up with a syntax for them that (a) can be parsed according to a context-free grammar and (b) is visually consistent with the rest of the syntax of a C-like language is not easy at all.

Well, we are providing an alternative language feature that achieves the same thing, but using a syntax which is more visually consistent.

I didn't say that

anywhere.