justthistime_

Seriously?

The same people who couldn't maintain their fork of Unity are now writing their own home-grown runtime, complete with their own garbage collector.

I don't see a chance of this working out "well" for any sane or bizarre notion of "well".

Dude, relax?

With .NET Core, is there any reason to not just drop IL2CPP completely?

(The whole thing only existed in the first place because they are stuck on a completely outdated Mono version, due to Xamarin changing the license of newer Mono versions trying to extract money from Unity.)

> Scala pretends to solve this problem by "layering" code.

From my perspective that's the large difference between Java and Scala. In Java, complexity leaks into the use-site (especially with Generics), in Scala it's possible to shield the user from that complexity.

Isn't that all basic stuff SBT did for years already?

  the things we can do with union and intersection types, 
  disjointness, abstraction over tuple and function types, 
  etc, are just beautifully elegant and powerful. Don't let 
  the fact that you love Scala blind you to other ideas.

I don't think it's a blind love, but all those things will ship in one of the next versions of Scala, too.

Given there are some things I can't just suffer anymore, like unreadable Generics (<>), required ; and "Type ident" syntax, maybe Ceylon just isn't for me. :-)

Ceylon and Kotlin are two languages who did this (both instanceOf/cast and instance creation).

    A language designer which doesn't want to give credit
    where credit is due

  I'm still waiting for you to retract that, now that I've 
  conclusively demonstrated that Ceylon's constructors are 
  totally different to—and more powerful than—Scala's. 

Eh. What?

A) You conveniently left out the other part of the sentence.

B) I already commented on that topic very early on, and clarified:

  Ok ... I'm really starting to believe you when you said you 
  didn't look into that other language, because there is 
  practically no benefit in doing it the way Ceylon does.

To which you – confusingly – replied with:

  I never said that. Please don't put words into my mouth.

So what do you actually want?

  Ceylon's constructors are totally different to—and more 
  powerful than—Scala's

Yep. I didn't deny that. It's a good thing though, because Ceylon's approach isn't very good in terms of language complexity.

  Constructors are not "static". Constructors access the members of the class.

That doesn't mean that they are not "static". Yes, they sit in a weird middle-ground, but fact is that constructors are called on the class/type, and not on the instance.

  Color foo = ...; new foo; // doesn't make any sense.


  If it's indeed a practice that constructors aren't called directly, then it's 
  interesting to enquire why that might be. And indeed an answer presents itself: 
  because they don't have names.

No, because it is good design to have one entry-point to create an instance, not 5. It is hard enough with reflection, sun.misc.Unsafe and serialization as-is.

  Wait: a factory method declared on a "companion object" is not like static?! Really?

In Scala you have one place for "static" things. In Ceylon, static is all over the place:

  - Static members inside objects
  - Static methods inside classes (with new x() {...})
  - Static fields inside classes (with new x {... }


  I mean AFAICT, the syntax for calling a factory method of a companion object in
  scala is exactly the same as the syntax for calling a constructor in Ceylon!

Yes. Ceylon wasted the "good" syntax on the wrong construct. Most of the patterns leveraged in factory methods are just not available in Ceylon, because the best syntax was directly married to the class.

  And, AFAICT, also lost like 75% of their capabilities.

Which has not been a issue in the last 10 years of Scala. Everything Ceylon has built into "constructors" are just standard methods with no magic required in Scala.

  Unless my evaluation above is wrong, and I'm missing 
  something. But so far no-one has spoken up to correct me.

Yes, you are focusing on the power of constructors. Yes, constructors are not extremely powerful – because they don't need to be in Scala. You are missing that Scala provides that power without turning constructors into such a mess.

Things that are discouraged don't receive the language's nicest syntax.

(Secondary) constructors are discouraged.

Looks like you are missing the point completely with your focus on Scala constructors:

Less is more. Nobody needs or wants the mess of Java-style initialization Ceylon tries to replicate.

  Ceylon has the notion of a value constructor.
  I have not yet found anything like that in Scala.

Yet another static thing in class declarations? Inventing different names for "static" doesn't solve the issue that you have introduced both "static" and "object" into the language. That's not a good idea.

  Also Scala sometimes seems to demand the use of the "new" operator in
  instantiation expressions, though I'm not clear why that's a requirement.

It's the same reason why instanceOf/casting is x.isInstanceOf[X]/x.asInstanceOf[X] instead of adding "convenience" syntax. You can't discourage people to use something and then provide syntax sugar for it.

Constructors in Scala are intended to directly initialize fields. They shouldn't be called directly, and are often private. Factory methods provide everything else, and are declared in objects, instead of being static like in Ceylon. That's by-design.

Because you care about the "outcome", not the "process": Scala did away with 90% of the mess associated with constructors, and used existing general-purpose features of the language to provide the rest (instead of having to introduce named constructors, default constructors, value constructors, partial constructors, and constructs which are "static" but named differently ...).

I don't think anything can change your idea that the thing you invented is the best thing ever (and everything else doesn't apply, because of the special constraints of Ceylon), therefore have a nice day! :-)

The whole idea of "let's encourage people to litter their classes with convenience constructors" is bad.

Constructors are the odd things which act like static methods, but have access to the fields of the instance-to-be-created.

Because constructors are weird and special in a lot of other ways too, it makes sense to use them only for initialization, and try to encourage people to define exactly one constructor.

Named constructors are poorly designed factory methods with the disadvantage that they are married to the class and add additional baggage to class declarations.

Why does Ceylon have objects, if they aren't used for one of their prime use-cases?

"Static methods go into objects, except static factory methods, let's keep dumping them into the class declaration" ... looks quite questionable to me.

Ok ... I'm really starting to believe you when you said you didn't look into that other language, because there is practically no benefit in doing it the way Ceylon does.

Not sure what scares me more: A language designer which doesn't want to give credit where credit is due, or a language who really didn't do his research.

Too bad that Ceylon/Dart still haven't caught up with the state of the art in terms of "named/default constructors".

Too bad it is Apple-only.

I think we definitely found the Common Lisper.

Stuff like this is why many developers don't take Go people serious anymore.

There are plenty of people out there which didn't manage or didn't need to advance beyond their first-year experience for the last ten years. "What did X do?" is a much better question than "How long did X do it?".

(For many jobs one year of experience is perfectly fine!)

I think people who can think critically and evaluate various options rarely join personality cults, which kind of explains Go's current community.

I think people who use Go in the first place are not those who think much about "can this be done in a better way?".

It's quite similar to the notion of "I'm a PHP developer and I don't understand why everyone says it is terribly designed! I learned to work with it and never tried anything else, so it can't be that bad!!!".

Not every developer cares about software development. There are plenty of people who chose this profession after they heard that a random developer can become the next Bill Gates by writing the right iOS app.

Having a language which doesn't require an inexperienced and non-interested developer to reflect on all the lessons learned in the last 40 years of software development and computer science fits the bill of this kind of person pretty well.

Sure, he/she is missing out on 4 decades of improvements to this profession, but who cares? Despite all the medical advances, there is still an economic niche for quacks selling "cosmic crystals" to cure your cancer.

There is nothing wrong with this. People don't pick a job in finance, because "they like to work with numbers" either.

We should just be aware of it.

Yeah. Go. The concurrent language with a single, mutable, thread-unsafe dictionary implementation.

I think that no-one will argue that an imperative, transient data-structure will be faster than a functional, persistent data-structure if you use it imperatively.

If you use persistent data-structures the way they are meant to be used, they can and will be faster than a simple array.

Both have valid use-cases, but they are often distinct.

> Like I feel a bit sad for Scala having native XML.

In what sense?

> up-to-date docs

Which parts are out-of-date?

> and bundled ORM

Didn't they just go the other way, de-bundling all persistence APIs/libs?

What's wrong with just picking the one that's right for your use-case and using just that?

Considering how butt-hurt these PU guys are over Scala, it seems to be unlikely.

I wouldn't say "further along". Deciding to not tackle any medium-to-hard problems just allowed them to be finished far earlier with their language.

No, I'm right. I didn't think of James Strachan. (He by the way stopped contributing to Kotlin around October 2012. You're welcome.)

People are still asking for examples, not for some popularity vote on feelings.

(Also, the designer of one of the languages mentioned was completely unaware of Scala when he created his own.)

So what _is_ your criticism?

The grammar of the language has no relationship with compilation speed.

What did they "tack on way too much, too soon"?

Most of the time is spent in the typechecker.

Plus, the ParallelUniverse guy keeps trying to spread FUD about Scala in pretty much every Java/Scala/whatever thread.

Account-created-2-hours-ago, did you ever use Scala, or are you just trying to troll (badly)? :-)

Edit: Oh, right. After reading your other comments, it's obvious that you haven't used Scala.