smcj

"I believe these figures are implausibly low - and an insult to IE users."

MISSION ACCOMPLISHED!

Could you elaborate?

Yes, sure. There is much less discrimination against "other" people on non-Apple platforms and that's great!

This is a great and honest article and has changed the way I think about Apple users/developers.

Before that, I considered Apple users to be a group of gay douchebags, but today I have learned that there is at least a sane person on the other riverside.

(I have neither developed for any smartphone nor do I possess one, so no need for "Stupid FANDROID!1!")

It is still painfully slow, right?

You ignorance is so painful embarrassing, it almost hurts to read your non-sense.

What's wrong with List.of(...)?

I think adding special syntax rules is a pretty bad idea.

Oh god. Please no, collection literals are the worst idea ever. Making up special rules for some special classes in a language? What the fuck!?

Mitigation would just have required to make an optimizer option non-default, like in 6.

It is more like C/C++.

Wrong.

Just a few thoughts...

- Scala has function inlining, look at @inline.

- Module system: this looks extremely wonky, especially considering what Oracle is planning with Jigsaw

- Pattern matching is extremely hard to get right

- "No hybrid", "industrial", that seems to be a pure marketing move, considering that even 95% of the syntax is the same as in Scala, together with types like Unit, Any, ...

- Kotlin is pretty much in the same complexity level currently, without being nearly as clean and orthogonal as Scala.

My estimate is that as soon as someone writes more than a few hundreds of lines of code in Kotlin, things will break down, especially in the collections area, features get thrown in, complexity explodes.

If they want to have some primitive Java-like collection design, then maybe not. But judging from their comments they want to have a design with higher-order functions (like map, filter, flatten, flatMap, partition, ...), they will need higher-kinded types. The problem is that higher-kinded types don't work well with reified generics.

I know it is quite popular to bicker about the "complexity of Scala", mostly coming from people having visited the webpage for a few minutes and not from those people using Scala in industry daily.

> They mince no words in emphasizing that this is an OOP language.

Scala is as OO as Kotlin, no compromises here.

> "Scala's syntax more flexible (with its own caveats)"

Not really. Scala and Kotlin share almost the same syntax (apart from <> vs. [] for generics).

I really wonder ... Microsoft is constantly increasing the margin between their languages (C#/F#) and Java, while the Java community as a whole has nothing better to do than being a huge bickering load of "language experts" getting nothing done at all.

The question is: Should we really wait for yet another language like Gosu, Fantom, Ceylon, Kotlin, ... to be usable in 2020?

Or should we maybe just starting to use Scala, which is proven, mature and stable, has received tons of bugfixes over the last then years, has a complete language specification, runs on JVM, with work being done to let it run on the CLR and on the LLVM, with a JavaScript compiler in the works, with a huge useful and clean standard library, with tools to check if JAR files are binary compatible, with a great amount of third party libraries, ...

Couldn't say it any better, thanks!

The state of IDE support has pretty much changed since a year ago.

IntelliJ pretty much rocks, Eclipse is done by the Scala team itself (no idea about Netbeans, though). While Scala IDEs haven't reached the level of maturity or the wealth of features of Java IDEs, they have useful features even Java IDEs lack.

I guess the .NET port is mainly for people wanting to keep writing Scala regardless if they are targeting the JVM, the CLR, browsers with JavaScript/GWT or the LLVM.

>>> Is driving a car better than eating a banana?

>> They serve completely different goals.

> Show us numbers.

That makes sense, doesn't it?

> That was the main request of my comment, and you come with a list of libraries?

Well, after you failed to even tell concurrent and parallel computing apart, I assumed giving you an overview first would be beneficial.

Maybe you could use the links I already gave you or use Google. For instance, here is an additional link I found pretty easily: http://www.azavea.com/blogs/labs/2011/06/scalas-numeric-type...

Why and how should actors outperform OpenMP or TPL? They serve completely different goals.

Scala ships by default with sequential, lazy and parallel collections and actors.

Akka (akka.io) provides a different implementation of actors (which will replace the one in the standard library in the future), as well as Agents, STM, Transactors, ... for all your concurrency needs. Akka actors can actually outperform Erlang actors in core areas.

Spark (spark-project.org) provides a (Hadoop-like) framework for distributed collections.

Work is being done to make Scala collections run on GPUs, too.

I would argue that Scala's toolbox is pretty diverse and complete when dealing with parallel and/or concurrent problems.

Without facts I wouldn't claim that Scala is slower than Java/C++/C#.

Scala beats the shit out of Java in situations where Java has to work with boxed types instead of primitives like in ArrayList<Integer>, enables people to write fully generic algorithms supporting any number type without speed penalty.

Scala is certainly nicer than C++ because it just works and has far less weird corners or surprises. It lets you write code faster and gives you more time to actually optimize those places where it matters.

C# is pretty much a kitchen-sink language with many features bolted on in a non-othogonal way, unlike Scala. The unreliable VM doesn't help, although value types and the thing Mono did with SIMD is certainly nice.

Well, the Scala developers are currently moving their build system to Scala. This means they can fully bootstrap their language/compiler, library and build system from one source language.

The .NET port has only added some minor changes to the compiler (which have actually uncovered a bug in the compiler implementation!) and most of the .NET backend works as a compiler plugin, just like the JVM backend or the LLVM backend.

Well, there is also a JavaScript compiler in the works and a LLVM backend. Who cares? Adding more supported platforms makes the language and its libraries more stable and mature, because less things are taken for granted.

Things in the Java standard library will work on .NET. Scala, too. If Scala uses .NET classes, this will also work. What's the problem?

Well, some might actually want co-variant return types and "real" variance instead of the interface/delegate as well as non-broken array variance, real type inference, higher-kinded types (to not loose the collection type like in LINQ) and many things more. That said, yes, C# looks a bit more familiar to Java developers although it is more or less a C++ descendant.

Additionally, most Java developers want to stay on the JVM, because it guarantees high performance, stability and maturity and has a wealth of well-known third party libraries.

I found the authors mistake:

"But now that students and parents are paying the majority of the cost of the education [...]"

WTH? Every society which basically favours people with deep pockets instead of intelligent, gifted people (and don't let yourself be fooled by "scholarships") is heading for a huge failure.

Real scientific research, political progress and prosperity of the nation will suffer from it (which is exactly what you can observe in the US).

As commented on the blog:

I pretty much don't understand the comment about loosing exception information is about. Isn't that exactly what getSuppressed() does?

printStackTrace() also mentions the suppressed exception, even with nice indentation. Am I missing something?

Yeah sure. Why should you do backups when you can start whining and pointing at Google instead...

I'm really interested in that idea. That would create the possibility to clean up the remaining Java cruft like "every object is a monitor", clone vs. Cloneable, ...

The compiler can only optimize simple calls in tail position, so recursive algorithms can overflow the stack, because the JVM lacks the support for any optimization here.

No good IO/File API (because it needs support from the JVM for certain operations, which will only be added in Java 7).

No good Unicode support (it uses Java's java.lang.String).

Type erasure (although the consequences are not as bad as Java's).

Java's reflection API doesn't agree with Scala code sometimes.

You have never looked more than 5 seconds at Scala, right?

Option[X] is only a crock if you haven't understood it. Stop thinking of it as a "null check", start as thinking of it as a collection which can either hold 0 or 1 elements and then you are on the right track.

null in Scala mostly exists for Java compatibility.

Re: Collections ... you haven't looked even _once_ at it. All collections return an empty collection or None, based on the operation. There are maybe 2 methods in the whole Scala standard library which return null, and both are _not_ in the collection framework.

This is so unbelievable misinformed... I can't believe it you have no problem showing this level of ignorance publicly.

"type inference system in Scala is always doing strange things behind my back" ... Example please.

"Automatic conversions" WTF?

"The trouble I see [...]" this is so much pure bullshit.

Failure to compile is always better than generating wrong bytecode.

Hi Tony,

isn't #963 more or less fixed? (It crashes the compiler, but doesn't fail at runtime anymore ...)

Could you post a new example of it if it isn't?

I had a completely different experience. Code is very readable, because it describes what it does and not how.

> (even in Java/Scala, all method-dispatching is done at runtime, as you're dispatching based on the implicit parameter).

Uh ... invokestatic?

> For example, Scala cannot implement the Hindley–Milner algorithm for type-inference, being forever forced to the current poor implementation that only deals with inferring the type of local variables.

The reason is that Scala has a much more powerful type system, than one that can be inferenced completely by HM (The HM type system was kept simple for exactly that reason).

Actually, the Scala language specification leaves out type inference for a reason: It is improved with every release to inference more and more useful things.

I'm getting slowly annoyed by those people thinking that a HM type system is "the best thing ever". Yes, it is simple, and simple is good.

But look at what Scala's type system can do as a comparison.

Please, get some idea what you are talking about before trolling about it.

"works great" doesn't necessarily exclude "it's a stupid thing to do".

I wonder how things like concurrency are expected to work, if no single line of code can be sure that things it expects will exist at runtime. Or maybe exists every 5 seconds for 3 seconds. It is an optimization nightmare (proven by the abhorrent performance Ruby exhibits).

Even the Ruby "developers" have understood that monkey-patching is bad and decided to do something against it.