randomThoughts9

I'm not disagreeing with you, but regarding your examples, am I the only one that prefers the way lambdas and streams are implemented in Java?

First of all, the way lambdas are implemented at the JVM level was a big improvement on what others were doing. And Scala is actually moving in that direction, if I'm not mistaken.

And regarding streams, I prefer one clean interface to having all the collection interfaces polluted with 1000 methods. Not to mention that in scala you have those traps, like when you are applying a map over a set and you end up with less elements than expected.

The government might and probably will change this rule.

I can imagine that after the first couple of accidents where the algorithm decides to kill N pedestrians to save 1 driver, the government could switch to a "utilitarian" point of view - minimize the number of lost lives - and will enforce this by law.

I like to skim through their gitter channel from time to time, to see what they are up to. But lately, it's not clear.

Does anybody here have more data on this? What's next for ceylon? What's the status with the intellij plugin? Or with the android support in general?

I think that a lot of people that are against higher/progressive taxes or see these level of inequality (income and wealth) as a good thing believe in the "self-made man" myth.

But that is just a myth. When someone "makes it", can you really disregard?

- his teacher from school

- the doctor that saved his life when he was young

- the guy on the street that maybe said something that triggered a chain of actions that ended in his success

- the books he read

- the peace of mind provided by living in a safe place

- etc.

Is it enough that you paid for that doctor appointment? I don't know. But you would not be here at all without it, and that doctor himself benefited from all of the above.

A different way of looking at things could be that, as we as a society don't know what works and what doesn't, we invest in people. Some are lucky, and based on their circumstances (and on their personal merit, I won't deny that) will manage to succeed in life.

>There were holdouts in Europe originally, some central banks were slow to adopt fractional reserves. They were trounced by the economies of other European nations and their superior access to liquid capital.

This is in no way a proof. A good analogy, but not a perfect one, I agree, is looking at 2 companies where one of them has more capital and so it can undersell its competitor, using prices lower than its production prices. You might win the competition, but that's definitely not a a good system long term.

And another thing that I think is very important to keep in mind is that we went through 2 world wars quite recently, each one performing a reset of the system. It is very hard to say that we are on the right track when the system needs to crash and burn every couple of generations.

I can think of at least 3 reasons:

- it's a fun project, if you're into that sort of thing

- dart has a VM, so you can run server side applications on it

- more bragging points for ceylon, as it confirms their design as a VM independent language

Now, it would be fun to compare the javascript code produced by ceylon directly with the one produced by the the dart compiler.

Well, the community here basically discussed the topic in detail 2 days before, when Gavin announced the 1.2 release[0].

Now, on why things are the way they are currently, here are a couple of reasons.

- so far, the ceylon team focused their efforts on the language itself and less on the available platforms, and that's why there are no clear getting staring guides for basically anything: web, android, etc.

- the language itself has a very distinct feel: from the way you publish your api (using the shared annotation), to the way union types affect the language (new way of handling errors, etc) to the way you use iterables {String*} instead of lists. These are all great features, but until you get the hang of it, they feel different. For me, this is just a problem of documentation.

- There is a very strange misconception, for lack of a better word, that just because JetBrains is building a great kotlin IDE, the ceylon IDE is somehow lacking. Which is not true at all. The eclipse plugin works great, and they'll also have an Intelij plugin soon.

[0] https://news.ycombinator.com/item?id=10463464

How is the ceylon integration going? I've been waiting for that before diving into vert.x 3.

There are some places where monad composability would improve your code but in general, at least the way I see it, you can replace a scala for comprehension with a set of IF statements, each IF eliminating a wrong value (null, exception, etc). Not to mention that you can have as many options as you like (A|B|C|D|E), whereas the mentioned monads must be composed in order to capture the same thing.

But it's true I never built a big ceylon project, so I can't say I know how that works out in practice.

Not the best place to mention this, but I never understood why, at least when talking with the functional oriented people, the union types are not explained as providing first level support for the Option, Either and the Try monads.

I hope they'll redo some of the documentation with this upcoming release. Every time I read it, I am amazed by how comprehensive it is but still manages to miss some very important points.

Like the fact that on the main page, the link to the online editor is not under the "Try it out" section. The explore action from that section is also misleading.

Or a clean hello world, with a real project structure documented

Or the way collections are documented. Basically, you have section 6 from the tour of ceylon: Streams, sequences and tuples. But it's not obvious what is the big difference between streams and sequences and the fact that sequences borrow the array notation while being immutable doesn't help either. Even when you go to the List api, which is the interface any Java developer will look for,you can't find the mutable collections, because they live in another module.