Ceylon progress report

Is the spec available for download? If yes, where? thx.

What do you think about Kotlin? (new language from JetBrains)

Arbi Sookazian wrote on Jul 20, 2011 14:10:
Is the spec available for download? If yes, where? thx.

Nope, only contributors currently have access to our github repos, which includes the spec, frontend, and backend. We'll open up public access to the github repos when we release M1.

Ivan wrote on Jul 20, 2011 15:21:
What do you think about Kotlin? (new language from JetBrains)

Of all the languages out there, it's easily the one most similar to Ceylon, and on that basis, obviously it's the other language I would find most reasonable for use in business computing. Emmanuel thinks it fits in between Fantom and Ceylon on the simplicity<->power scale, but I think it's much closer to Ceylon than Fantom. I say that on the basis that it proposes a full system of (reified) parameteric polymorphism that is extremely similar to ours, whereas Fantom ditches generics except for certain built-in types.

Certainly Kotlin as the proposal exists today looks far saner and more manageable than Scala with all its crazy punctuation characters and evil evil implicits and supertype linearization, etc, etc, etc.

The differences between Ceylon and Kotlin seem to be mainly skin-deep matters of syntax though there are certain areas of disagreement. For example, they like pattern matching, full operator overloading, extension methods, and delegation, whereas we prefer a more limited switch, operator polymorphism, fullblown introductions, and a typesafe metamodel with interception. These are the areas where you need to make tradeoffs between different things that are nice to have in order to avoid too much overall complexity, so it's not surprising to see different people making different tradeoffs. I think I can make quite strong arguments for the decisions we've made, but I'm sure they won't convince everyone.

Overall it's a reasonable language design and I think that most people would find you can accomplish the same things with more or less a similar amount of effort in both languages. I think it's excellent that people are still thinking hard about how a post-Java language can be more powerful without going down the path of crazy complexity and unreadability. I do believe that a lot of people are going to be very comfortable with a language that occupies this particular niche when it comes to getting real work done.

P.S. One thing that mystifies me is this current fad for Pascal/ML style type declarations. Ceylon has:

local name = "Gavin";           //nice and clean
String hello = "Hello!";        //still nice and clean

Scala and Kotlin go with:

val name = "Gavin";            //nice and clean
val hello: String = "Hello!";  //omg, wtf!

Apart from the obvious extra verbosity of the Pascal/ML-style (a whole extra keyword and a totally useless stray punctuation character), the thing I hate worst about this is that it seem to be telling me that String = "Hello", instead of that hello = "Hello". So wrong!

I think we need to be very careful to not throw out the nice things about Java along with the broken things.

But listening to the arguments why it makes more sense [snip] does make a lot of sense.

I see one argument there. Which I disagree with. Let's take Martin's own example:

Map<String,Boolean> map = HashMap { "hello"->true, "goodbye"->false };

vs:

val map: Map<String,Boolean> = HashMap { "hello"->true, "goodbye"->false };

I know which I prefer.

I hope that over time Ceylon can produce excellent compiler error reports indicating exactly what went wrong because without that the battle's lost.

It already does. As mentioned above, the type checker is basically a done deal.

And let me be clear: complexity isn't a problem of scala. It just holds the mirror to you and that in turn reflects the average devs persona corrupted by years of J2EE/Hibernate/Spring imperative-getter-setter-mutable-1000-line classes. Design by types and functional programming distinguishes the chaff from the grain.

Ahyes, the classic Scala community response to criticism: if you don't like Scala it's because you're too stupid for Scala. I'm chaff next to the elite Scala developer grain. Ohboy I'm just so dying to be part of a developer community that thinks like that!

Well, let's suppose you're right. Let's just suppose that I and other folks such as Cedric Beust, and Stephen Colbourne, and the folks from Jetbrains, and others like us who spend a lot of time thinking and writing about programming languages and frameworks really are all too stupid for Scala. Surely would could as some kind of mark against the language, no?

Yeah, sorry man, I meant to say:

Surely would count as some kind of mark against the language, no?

About the more general syntax question, I agree that val = value is easier to read than val : type = value, but it's probably the kind of thing that ends up blending as you work more with the language.

Yeah, sure, I don't doubt that. The truth is we're actually able to adjust and get used to all kinds of funny syntax. I mean, we speak natural languages all day, with all their irregularities.

But I think that if you pile on enough slightly-more-difficult-to-visually-parse constructs into a language, then at some point the language does become noticeably slower to read and understand. Getting the little things right is in my view really important when you're creating something that you're going to be asking people to spend upwards of 4 hours a day staring at.

And the point here with this particular issue is that if you're starting from something basically Java-like, and looking for problems that need fixing, then this is definitely not a thing I would want to fix.

The Scala example not correct, it is

val hello = "Hello"

Scala has pretty nice type inference. Good luck on your efforts to ship Ceylon.

Oh, and another one:

val map = Map("hello" -> true, "goodbye" -> false)

is correct Scala code.

Your friendly scala neighbor wrote on Jul 21, 2011 15:25:
The Scala example not correct, it is val hello = "Hello" Scala has pretty nice type inference. Good luck on your efforts to ship Ceylon.

I gave two examples of Scala:

val name = "Gavin"

and

val hello: String = "Hello!"

These are actually both perfectly syntactically correct Scala declarations. I guess I did make one sort-of mistake - I accidentally left in semicolons that are unnecessary in Scala, though that was totally irrelevant to the point under discussion. We're comparing Pascal/ML style type annotations to C-style type annotations.

All the languages we're discussing have nice type inference, which you would know if you had actually taken the time to study any of them. But sometimes explicit type annotations are necessary or desirable for human-understandability, and we're discussing what the code looks like when they are there.

In future, please actually read the thread and figure out what is being discussed before shooting off silly comments.

The Scala examples are more informationally dense - you can see the variable references are immutable. Great signal-to-noise ratio if you can rely on the type inference, but quite the opposite if you need to specify the type and aren't bothered about the immutability...

I guess if you're not bothered about a particularly functional approach you might not care about promoting final variables, but what is your opinion on the benefits when reasoning about concurrency?

These are actually both perfectly syntactically correct Scala declarations. I guess I did make one sort-of mistake - I accidentally left in semicolons that are unnecessary in Scala, though that was totally irrelevant to the point under discussion. We're comparing Pascal/ML style type annotations to C-style type annotations.

Scala has postfix type annotations for two reasons. The first is it makes the syntax more consistent w.r.t. type inference. In Ceylon, you had to introduce a new keyword, local, which takes the place (syntactically) of the type. This is exactly the same as what C# does with var. The problem with this is your syntax is now inconsistent. Consider the following BNF:

decl ::= type-id id "=" expr

type-id ::= id | "local"

id = ...
expr = ...

So effectively, local is a type, syntactically speaking, but it's a type that can only be used in declarations. That's a little weird. Also, does type inference work for fields? If so, what keyword do you use there? I would imagine that local would get confusing, so does that mean you have another special non-type-standing-in-for-a-type? I'm speaking out of ignorance here, but I think you see where I'm going. Postfix types make the syntax much more consistent. And, speaking as someone who has done a fair amount of research in type theory and formal logic, postfix types are quite a bit more in line with standard mathematical notation (see also: domain/co-domain notation on functions).

The other reason Scala has postfix types is to handle function types. I actually don't know if Ceylon has these, so it may be a non-issue, but consider the following Scala:

val f: String => Int = ...

Compare that to the following (fictional) Ceylon syntax:

(String => Int) f = ...

The parentheses are required to avoid creating local ambiguities in the grammar. It's not a global ambiguity, so you can technically get away with some clever parser construction, but your error messages aren't going to be as good (imagine, for example, that someone forgets to type the identifier in a declaration). C has exactly this same problem with its function pointers, which is why everyone uses typedef when working with function pointers.

This is all syntax, so I'm not sure I care one way or another. I'm just trying to point out that there are very good reasons for Scala choosing postfix types. Prefix types may be more familiar to people coming from a language in the C family, but they don't mesh well with some of the features you're putting into Ceylon. It would not surprise me if you discover this as you flesh out the standard library.

Ok, relax man. I read that as one example of Scala, and one example of Kotlin. My mistake. Your point just seemed a bit construed to me. I was not saying that other languages don't have nice type inference. The Pascal/ML type style annotations never troubled me. I guess I will refrain from commenting here in the future.

I guess if you're not bothered about a particularly functional approach you might not care about promoting final variables, but what is your opinion on the benefits when reasoning about concurrency?

All attributes and locals in Ceylon are final by default, because we're strongly promoting the use of immutability. In idiomatic Ceylon code, variable locals are going to be quite uncommon, and are going to come with:

• a great big variable annotation attached, along with
• the use of a special symbol := for variable assignment, instead of the usual = for specification of an immutable value.

Both serve as a warning the reader of the code that something side-effecty is going on. Ceylon is actually much more opinionated on this issue than Scala.

For more information about the Ceylon language, here's the tutorial.

One thing that mystifies me is this current fad for Pascal/ML style type declarations

One thing that mystifies me is this current fad for Pascal/ML style ':=' instead of the more usual '='.

Daniel:

The problem with this is your syntax is now inconsistent. [snip] So effectively, local is a type, syntactically speaking, but it's a type that can only be used in declarations. That's a little weird. Also, does type inference work for fields? If so, what keyword do you use there? I would imagine that local would get confusing, so does that mean you have another special non-type-standing-in-for-a-type? I'm speaking out of ignorance here, but I think you see where I'm going. [snip] Postfix types make the syntax much more consistent.

Traditional C syntax for declarations is:

(keyword|Type) Identifier Definition

Ceylon is totally consistent with this. The following syntax is no more regular:

(keyword) Identifier (":" Type)? Definition

It's just more verbose.

And, speaking as someone who has done a fair amount of research in type theory and formal logic, postfix types are quite a bit more in line with standard mathematical notation

Oh wow, I guess I don't have the right to argue with you then. (P.S. I studied pure mathematics and scientific computing at university. This included a bunch of stuff on set theory, logic, foundations of mathematics, etc. Of course, I never try to use this knowledge to try and bully people I disagree with.)

The other reason Scala has postfix types is to handle function types. I actually don't know if Ceylon has these, so it may be a non-issue [snip] Compare that to the following (fictional) Ceylon syntax:

Oh please, for gods sake go and actually learn the language before criticizing it. You don't have the right to invent your own fictional and incorrect Ceylon strawman syntax just to criticize it.

Prefix types may be more familiar to people coming from a language in the C family, but they don't mesh well with some of the features you're putting into Ceylon

Actually they mesh nicely. I happen to know this, since I'm the actual designer of the language and I actually know what it's syntax is.

Your friendly Scala neighbor wrote on Jul 21, 2011 16:53:
Ok, relax man. I read that as one example of Scala, and one example of Kotlin. My mistake. Your point just seemed a bit construed to me. I was not saying that other languages don't have nice type inference. The Pascal/ML type style annotations never troubled me. I guess I will refrain from commenting here in the future.

Sorry, that was perhaps unfair. I'm a little touchy, due to the rather nasty behavior of the Scala community in general towards folks who are fans of other languages (see Daniel's post above, as a more-or-less typical example).

anonymous wrote on Jul 21, 2011 17:12:
One thing that mystifies me is this current fad for Pascal/ML style type declarations One thing that mystifies me is this current fad for Pascal/ML style ':=' instead of the more usual '='.

In Ceylon := is used only for assignment to variables, as a warning that the code is doing something non-functional. The = specifier is much more common.

Gavin King wrote on Jul 21, 2011 17:17:

anonymous wrote on Jul 21, 2011 17:12:
One thing that mystifies me is this current fad for Pascal/ML style type declarations One thing that mystifies me is this current fad for Pascal/ML style ':=' instead of the more usual '='.

In Ceylon := is used only for assignment to variables, as a warning that the code is doing something non-functional. The = specifier is much more common.

Of course, I admit that this is the same thing ML does. Well, that's OK, I rather like ML.

I'm surprised that Celyon team believes that there is a place for two very close languages... I'm not saying one is better than the others (both are not more than unfinished specs right now) - but I'm pretty sure there's no space for both in the marketplace in their current form.

... and I was talking about Ceylon vs. Kotlin, of course.

Nikita Ivanov wrote on Jul 21, 2011 17:23:
I'm surprised that Celyon team believes that there is a place for two very close languages...

There may not be. I don't especially have an opinion on that topic.

I'm not saying one is better than the others (both are not more than unfinished specs right now)

Really? How would you know? Neither team has made their work public yet. But both teams are saying that they have already made significant progress on their respective compilers. In fact, as I mentioned in the original blog post, we're very close to having an initial release of a Ceylon compiler. The Jetbrains folks are saying they'll have one later this year, and they seem to be saying that they'll even have some kind of IDE for it at that stage.

So clearly both languages are more than unfinished specs.

I'm not really reading a lot of hate from daniel's email, and I'm not sure you addressed his point. Your view: I stay closer to C style syntax in Ceylon. His view: Scala stays closer Mathematical notation.

Great. How often to you use a type instead of local in Ceylon? That's the question that answers whether or not the view is a good one. I am biased because I rant on why the scala way is better, but let's not resort to name calling here. I think you have a point in what you're saying.

Note: Scala allows mutable variables (var) and immutable (var) vs. just immutable in Ceylon (local) so the benefit of keeping styles of variables on the left is lost in the Ceylon language, allowing it to stay closer to C-style. Great! Let's not misrepresent either side.

Josh Suereth wrote on Jul 21, 2011 18:19:
I'm not really reading a lot of hate from daniel's email,

Well, on twitter he wrote, linking to his above comment:

Took another tilt at the Gavin King windmill of Scala disinformation.

I didn't appreciate that. Just because you disagree with someone, doesn't mean that what they say is disinformation. Frankly, I think I deserve just a little more respect than that, since it should be clear to most people here that I approach these issues with intellectual curiosity and honesty, and that I'm stating my considered opinion, after putting much thought into the matter.

I don't accuse other people with different views of disinformation or intellectual dishonesty, and I expect the same level of respect in return.

I also didn't appreciate Daniel's invention of some nonsense strawman fictional Ceylon syntax when the actual syntax is quite easy to discover with just a little research on this very site.

and I'm not sure you addressed his point. Your view: I stay closer to C style syntax in Ceylon. His view: Scala stays closer Mathematical notation.

Well, no, I didn't bother to respond to that one. Both syntaxes are conventional in one way or another, and both have been used in many programming languages. I don't think any reasonably experienced programmer is unfamiliar with either. I've coded in languages from both camps. But I remain firm in my belief that one option is clearly superior ;-)

Daniel's other claim, which I did respond to, that Postfix types make the syntax much more consistent is simply wrong, as far as I'm concerned. Both options are perfectly internally consistent.

Great. How often to you use a type instead of local in Ceylon?

Well, in any language without HM type inference (that, in practice, includes really almost any imaginable object-oriented language), type annotations are needed on at least parameters. But, in fact, I think that they're needed somewhat more widely than that, simply for reasons of readability.

Cedric, honestly, since we're probably not going to use the seam wiki infrastructure for the new Ceylon website, and since we've all got a lot of other work to do, I doubt that anyone is really going to find the time to put any work into improving seam wiki. Pity, I happen to love this software, since I understand it's quirks, and so for me it's simply the quickest way ever to push out content, but to really make it perfect would require a dedicated person, which we simply don't have.

Both Scala and Ceylon camp should chill IMO. You should embrace each other as friendly competition never hurt anyone. However, I think there's a fundamental problem with Ceylon and Kotlin in that they are not really solving anything and don't stand a chance of widespread adoption. If you have a development team for whom Scala is "too complex," believe me Ceylon will be "too complex" for them as well. The problem isn't in the complexity of the language, but in the fact that there's too much Java code in large companies and on large projects and most companies are not going to invest resources to switch to Ceylon/Scala/Kotlin/Groovy... just because it's "cool", or "removes boilerplate" or "easier to read" or "[put whatever reason you can think of that your language is better than Java]". This isn't about post-fix or mathematical theory or which camp has read more books or whatever other theory each camp is going to throw at us, this is about reality. And reality IMO is simple - there won't be a widespread adoption of any Java-killer anytime soon. Just look how many blogs and whatnots are out there titled "How Convince Your Boss to introduce [Scala/Groovy...] into your project" or variations on the same theme. It just won't happen unless there's a compelling business need to do so and there isn't. Most people don't work at Twitter who had a specific need that had to be solved with the specific language. What is Ceylon going to solve? Absolutely nothing at the moment but maybe there will be a Twitter-like story that will happen in 3-4 years if this project stays live that long. Groovy? Good for writing test and if you are starting out and using Grails - great. If you succeed you'll probably switch to Scala for performance reasons. All these new languages are dying to get wider Java audience and that is simply not going to happen. If languages like Scala and Groovy cannot gain better traction than they are currently getting what is Ceylon/Kotlin going to do for us? I can tell you what - it's going to make some money for NFJS guys that are going to spend 2-3 hours reading through the docs and examples and then they will "teach" the wider Java community at NFJS/JavaOne/... on all the benefits of using this new language, there'll be more blogs on "How to convince your boss to switch to Ceylon/Kotlin..." and that's where that will all end. None of these languages stand a chance for wider adoption simply because there no one is actually looking for a silver bullet because it does not exist. And even if it existed, I'll give you a few phone numbers to try to convince people that pay salaries to switch to this new glorious language. Everyone seems to think that there is a need for a language to replace Java which may absolutely be the case but I think all people that involved in creating Ceylon/Kotlin better be doing it for the love of hacking or for potential to make a little $$$ on the conference circuit cause that's all that their language will ever be.

Dejan, you may well be right. Possibly none of these languages will ever gain traction in commercial environments. Or perhaps one will. Or perhaps two or more will. Predicting the future is difficult. Technology advances by people taking risky bets on things that might not work out, and seeing how the market reacts.

(Hell, I remember reading many, many confident predictions that JBoss would never gain acceptance in big companies, and look what happened...)

Anyway, I think it's a really good idea that the technology community be ready with solutions just in case businesses are ready for a change. It would be sad if the opportunity were there, but we just weren't ready to take advantage of it. And I think it's great that there is a whole range of options along the spectrum from simple to powerful.

Gavin King wrote on Jul 21, 2011 18:57:
Well, on twitter he wrote, linking to his above comment: Took another tilt at the Gavin King windmill of Scala disinformation.

That's true, I did write that. It was mostly in jest though. 140 characters isn't a lot of space!

In case it wasn't clear, I don't see any Scala disinformation in this post. However, as you have made such inaccurate representations in the past, I think you can see how the characterization was at least partially accurate.

I don't accuse other people with different views of disinformation or intellectual dishonesty, and I expect the same level of respect in return.

Noted. Your turn now: I don't bully people with titles or experience and I resent the insinuation that I do. Additionally, you have pretty consistently dodged the points raised in my comments on Ceylon. That's certainly your right, but embracing and answering dissent is part of the intellectual honesty package.

I also didn't appreciate Daniel's invention of some nonsense strawman fictional Ceylon syntax when the actual syntax is quite easy to discover with just a little research on this very site.

The strawman syntax was illustrative, and I very clearly prefixed it as such. I was trying to point out some of the (numerous) problems with prefix type annotations. More importantly, I was attempting to dispel the myth that Scala went for postfix types simply on a whim. Scala solved the problems with prefix type annotations by not using them. I was actually curious as to how Ceylon solves those problems.

Daniel's other claim, which I did respond to, that Postfix types make the syntax much more consistent is simply wrong, as far as I'm concerned. Both options are perfectly internally consistent.

Well, no prefix types aren't syntactically consistent. :-) I think we've reached on impasse on this one though, so I'll let it drop. I've never seen Ceylon beyond simple one-liners, so I certainly lack perspective on the language that you have.

Wrap up point: I'm not trolling you just because I happen to use Scala. With both of my comments on your blog re:ceylon to date, I have been wanting to get a decent discussion going on the pros and cons of various language design choices. I'm very disappointed that we haven't been able to see that sort of discourse.

Can I ask again how persistence is being handled? Is persistence going to part of the language/compiler/runtime? I think the use of persistence is high enough to warrant its inclusion.

Thanks.

That's true, I did write that. It was mostly in jest though. 140 characters isn't a lot of space!

Ah huh. Hah hah hah. Funny jest. I'm sure you won't be upset when I post jests like that about you.

In case it wasn't clear, I don't see any Scala disinformation in this post. However, as you have made such inaccurate representations in the past, I think you can see how the characterization was at least partially accurate.

And of course, now you're going to provide us with a link to specific clearly-factually-incorrect claims about Scala that I have written in a public forum.

Links please. Here. Now.

Or you're going to just stop smearing me Right Now, please.

Additionally, you have pretty consistently dodged the points raised in my comments on Ceylon.

I think I've answered every concrete point you've made. I think your problem is that you don't consider something an answer unless you agree with it. Nevertheless, I invite you to explicitly list the points that you think remain unanswered.

The strawman syntax was illustrative, and I very clearly prefixed it as such. I was trying to point out some of the (numerous) problems with prefix type annotations.

But you could have just gone and read the Ceylon tutorial and seen how Ceylon resolves this problem. And then you wouldn't have wasted other people's time with strawmen.

I was trying to point out some of the (numerous) problems with prefix type annotations.

Oh, numerous problems! Wow, funny how in more than a decade of writing code in a language with prefix types, I've simply never run into any of them. Quite incredible actually.

Scala solved the problems with prefix type annotations by not using them. I was actually curious as to how Ceylon solves those problems.

But not curious enough to actually read up on the topic.

Well, no prefix types aren't syntactically consistent.

Well, yes, they are. See my BNF which clearly illustrates the regularity here.

I've never seen Ceylon beyond simple one-liners, so I certainly lack perspective on the language that you have.

Right, I can tell that, so why are you even posting about it.

Wrap up point: I'm not trolling you just because I happen to use Scala. With both of my comments on your blog re:ceylon to date, I have been wanting to get a decent discussion going on the pros and cons of various language design choices. I'm very disappointed that we haven't been able to see that sort of discourse.

The interesting thing is that there have been any number of very interesting, involved discussions about language design in the comments section of this site. You haven't noticed because you haven't been paying attention.

By the way, here is a silly example how you declare a higher-order function in Ceylon:

void asCurrentUser(void do(Principal principal, Permissions permissions)) {
    if ( !loggedIn ) {
        throw NotLoggedIn();
    }
    do {
        principal = currentPrincipal;
        permissions = permissions(currentPrincipal);
    };
}

Note that since named arguments are such an integral part of the programming model in Ceylon, we want to know not just the types of the parameters of a function reference, but also names of the parameters. (And their default values, and whether the last one is a varargs parameter.) Yes, I understand that this is a lot different to the traditional view of a lambda expression, but Ceylon is, well, a bit different. So a function type syntax like (Principal, Permissions) => Void just simply doesn't capture all the information Ceylon thinks is interesting.

And now notice how there is no real problem with prefix types in this. We're using exactly the same syntax to declare a functional parameter that we use to declare a formal (abstract) method. Now that is nicely regular. We simply avoid having a special syntax for declaring the type of a functional parameter. The same is true for other kinds of function reference:

Float double(Float x) = 2.times;

Now, I am oversimplifying a little here: there actually is a second way to write down the type of a function, but it's only really useful if you want to use a function type as a type argument. And it's not in any way a special language feature, it's basically just part of the typesafe metamodel. You would use it, for example, if you wanted a List of functions of a certain type. That's a pretty rare case. I'll let you guys read the Ceylon tutorial for more information about this.

you can add/remove it without changing the placement of the rest of the declaration

The same is true with Ceylon's approach. I can easily change local to String or vice versa.

More important, it's much more consistent: any variable declaration always starts with the var/val (or equivalent keyword); in a C-style syntax but type-inferred language, you usually write String x = null, but when you don't need to declare the type, you need some special token anyway, e.g. var x = f().

And how is that inconsistent? The abstract BNF of C declarations is:

(keyword|Type) Identifier Definition

It's all totally regular.

again it's inconsistent if you require it only for the non-default [im]mutability case.

I don't see how using a modifier annotation is inconsistent or irregular in the context of any language which has modifiers (all the languages under discussion here). By this exact same reasoning, abstract, public, override, etc, are all inconsistent.

Gavin -

I assume that the omg wtf next to the scala/kotlin example was tongue-in-cheek (i.e. you don't really think it's ridiculous, just unnecessarily different than other C-background languages). I'm also from the camp of Java programmers for more than 10 years and I also started off with scala thinking why did they do this? with post-fix type annotations. However, I've radically changed my mind, to the extent where I hate and despise prefix type annotations:

Map<Fund, Map<TradingBook, Map<Pair<Instrument, Trade.Side>, AggregateTrade>>> trades = ....

The actual variable name gets totally lost. To the extent that I've chosen my IDE Java colour scheme now so that types are grey and variable names are bold - basically to get around the fact that I'm stuck with prefix types.

Let me be clear, I have no issue with Ceylon or what you decide to do with your own language. But you do appear (even assuming you were being tongue-in-cheek) to be criticising the choices that other languages have made. Which is also fine. What is less fine is the fact that when people criticize your language decisions, you say things like: Oh please, for gods sake go and actually learn the language before criticizing it. But you just criticized Kotlin - did you learn it first?

PS.

To say that this site is terrible from the perspective of leaving comments is the understatement of the century. It does your technical credentials no credit whatsoever to be apparently satisfied with third-rate rubbish.

I assume that the "omg wtf" next to the scala/kotlin example was tongue-in-cheek

Yes, of course, it was hyperbolic.

you don't really think it's ridiculous

Ridiculous, no. I certainly don't think that. Hell, one of my favorite languages (ML) uses the same style.

I hate and despise prefix type annotations:

Map<Fund, Map<TradingBook, Map<Pair<Instrument, Trade.Side>, AggregateTrade>>> trades = ....

Wow! Impressive. I've never written a type annotation like that, not ever.

What is less fine is the fact that when people criticize your language decisions, you say things like: "Oh please, for gods sake go and actually learn the language before criticizing it".

I think there's a clear difference between criticizing the actual syntax of a language that you actually know and criticizing a syntax you just made up out of thin air, that is not the actual syntax of the language you're criticizing. Do you agree that there is a difference there? Do you agree that if you're going to post negative things about a technology, then it would be better to be sure of the facts you are posting first?

But you just criticized Kotlin - did you learn it first?

Well, yes, I guess I did, to the extent possible. I read all the material that they have published so far. That's the most I could do, I suppose. I make it my business to be well-informed about other languages out there. Kind of my job.

Furthermore I don't see where I was very critical of Kotlin. Actually I intended to be quite positive about it, and I think other readers took it that way. I wrote:

Of all the languages out there, it's easily the one most similar to Ceylon, and on that basis, obviously it's the other language I would find most reasonable for use in business computing. .... Overall it's a reasonable language design and I think that most people would find you can accomplish the same things with more or less a similar amount of effort in both languages. I think it's excellent that people are still thinking hard about how a post-Java language can be more powerful without going down the path of crazy complexity and unreadability.

I think that was pretty fair-minded, don't you? I'm guessing you're the only guy who took it as a negative critique.

And, well, I certainly didn't invent any hypothetical strawman Kotlin syntax in order to criticize it. I stuck to the actual published facts about the actual language. I didn't speculate.

Gavin King wrote on Jul 21, 2011 18:57:
I also didn't appreciate Daniel's invention of some nonsense strawman fictional Ceylon syntax when the actual syntax is quite easy to discover with just a little research on this very site.

So I've searched and the type of 'String => Int' is 'Callable<Int, String>'. Which just demonstrated Daniel's point I think, but instead of simple parenthesis you use angle brackets and then 8 more characters.

Gavin King wrote on Jul 21, 2011 22:14:
By the way, here is a silly example how you declare a higher-order function in Ceylon:

void asCurrentUser(void do(Principal principal, Permissions permissions)) {
    if ( !loggedIn ) {
        throw NotLoggedIn();
    }
    do {
        principal = currentPrincipal;
        permissions = permissions(currentPrincipal);
    };
}

In http://relation.to/Bloggers/IntroductionToCeylonPart8 you write:

So the type of sum in Ceylon is: Callable<Natural, Natural, Natural> What about void functions? Well, remember that way back in Part 1 we said that the return type of a void function is Void. So the type of a function like print() is: view sourceprint? Callable<Void,String>

So which one is it?

Above, I wrote:

Now, I am oversimplifying a little here: there actually is a second way to write down the type of a function, but it's only really useful if you want to use a function type as a type argument. And it's not in any way a special language feature, it's basically just part of the typesafe metamodel. You would use it, for example, if you wanted a List of functions of a certain type. That's a pretty rare case. I'll let you guys read the Ceylon tutorial for more information about this.

Good Work, Ittay, you actually went and read the tutorial and found the thing I was talking about!

So which one is it?

It's both! Many (most?) of these languages have more than one way to write a function type.

For example, in Scala you have three ways to declare the type of a function:

• def f(s: String, i: Int): String, i.e. an ordinary function declaration,
• (String, Int) => String, i.e. the syntax sugar for a function type
• Function, Function1[String,String], Function2[String,Int,String], etc.

The second form is the form you usually use when writing a higher-order function.

In Ceylon you have two ways:

• String f(String s,Integer i), and
• Callable<String,String,Integer>.

The first form is the form you use when writing a higher-order function.

Read a bit further into the tutorial for more information.

Function, Function1[String,String], Function2[String,Int,String], etc.

Should be Function0[String], Function1[String,String], Function2[String,Int,String], etc, if I'm not mistaken.

Ittay Dror wrote on Jul 22, 2011 12:32:

Gavin King wrote on Jul 21, 2011 18:57:
I also didn't appreciate Daniel's invention of some nonsense strawman fictional Ceylon syntax when the actual syntax is quite easy to discover with just a little research on this very site.

So I've searched and the type of 'String => Int' is 'Callable<Int, String>'. Which just demonstrated Daniel's point I think, but instead of simple parenthesis you use angle brackets and then 8 more characters.

Ooops, missed this comment.

Again, you should have read the whole tutorial, instead of just searching. Callable<Int,String> is Ceylon's version of Scala's Function1[String,Int]. It's not the syntax usually used to declare a higher-order function.

And, if we're going to be silly about it, I count 21 characters in the the Scala version vs. 20 in the Ceylon version. Why? Well, because Scala needs multiple types Function0, Function1, Function2, etc, whereas Ceylon can abstract over all functions argument lists with a single type Callable, due to sequenced type parameters.

Again, folks, it's very, very risky to criticize something you've spent three minutes studying. You wind up posting stuff like this. That you think is a gotcha. But in fact just makes you look a little silly.

Well, you wrote about the Callable form: You would use it, for example, if you wanted a List of functions of a certain type. So in Ceylon you need to use Callable in your code sometimes. In Scala, FunctionX is just an implementation detail you don't care about. In other words, if they change it tomorrow to CallableX, my source code will not need to change. So I would never need these 21 characters. This is maybe the sort of disinformation that Daniel referred to.

And I find the fact that there are two ways to declare a function type is confusing/complex.

Actually the form: Float double(Float x) = 2.times; appeals to me since it is very similar to the form of declaring a method with a body. But then again, in both Scala and Ceylon I would rely on type inference instead of writing the types.

And I find the fact that there are two ways to declare a function type is confusing/complex.

And yet, it doesn't confuse you that there are three ways to do it in Scala. Hrm, Sorry, but I don't actually believe that you find it that confusing. I think you understand it perfectly, in fact. I think you're just looking for stuff not to like.

Gavin King wrote on Jul 22, 2011 14:20:
And I find the fact that there are two ways to declare a function type is confusing/complex. And yet, it doesn't confuse you that there are three ways to do it in Scala. Hrm, Sorry, but I don't actually believe that you find it that confusing. I think you understand it perfectly, in fact. I think you're just looking for stuff not to like.

Let me turn this around on you. I find it confusing and complex that you sometimes see Scala folks write:

def f(s:String, i:Int):String = ...

And other times:

val f: (String,Int)=>String = ...

Except that, well, I don't actually find it that confusing. I definitely think the first form is more readable, but it doesn't actually confuse me. Nor would it confuse me if I ever saw:

val f:Function2[String,Int,String] = ...

Though again, it's less readable than the first version.

But for my money, the following is just ideal:

String f(String s, Int i) = ...;

And if the language will almost always let me write it that way, I'm happy :-)

Well, you wrote about the Callable form:

You would use it, for example, if you wanted a List of functions of a certain type.

So in Ceylon you need to use Callable in your code sometimes.

OK, so here we have a serious language design question. And I'm interested in your serious answer. Do you think it is worth our introducing a third way to write down the type of a function - a syntax sugar for Callable<R,A1,A2>, just like Scala has the syntax sugar (A1,A2)=>R for Function2[A1,A2,R].

The only real usecase for this in Ceylon would be when you're using a function type as a type argument. e.g. if you've got some kind of Collection of functions or something like that.

Would it be worth the extra syntactic complexity being able to write, for example:

String:(Integer,String)[] sequenceOfFunctions = ... 

List<String:(Integer,String)> listOfFunctions = ... 

(Or whatever syntax we wound up choosing)

Instead of:

Callable<String,Integer,String>[] sequenceOfFunctions = ... 

List<Callable<String,Integer,String>> listOfFunctions = ... 

I have gotta think that this is not worth it, but perhaps I'm wrong. We could always introduce, like Scala, a third way to write function types. We have that option. But, well, I just don't think this is something that is ever going to bother anyone. How often, really, does a function type appear as a type argument in real code that does actual work?

Ittay, FYI I just deleted your last comment, and you are now banned from this site, because for the second time in less than an hour you accused me of disinformation. I exercised great self-control in not responding to the first accusation, but now you're simply not welcome here. This is my site, and people don't have the right to smear me, especially not when I'm trying to focus on keeping the discussion technical and away from nonsense personality stuff.

Please go use Scala and don't come back. I'm trying to build a community of nice, open minded people here.

Gavin King wrote on Jul 22, 2011 14:52:
Ittay, FYI I just deleted your last comment, and you are now banned from this site, because for the second time in less than an hour you accused me of disinformation. I exercised great self-control in not responding to the first accusation, but now you're simply not welcome here. This is my site, and people don't have the right to smear me, especially not when I'm trying to focus on keeping the discussion technical and away from nonsense personality stuff. Please go use Scala and don't come back. I'm trying to build a community of nice, open minded people here.

Furthermore, I'm going to close comments, since I just don't want to spend the rest of my day responding to all this stuff. I want to protect myself from getting dragged further into discussions about Scala, since the Scala community has repeatedly proved itself extremely thin-skinned when it comes to criticism. I don't want my name dragged through the dirt again.

Apologies to all the folks who might have wanted to post thoughtful stuff here.