Hacker News Reader

>And you know why people liked it? Mostly because it had lambdas and traits - two features that are in Java 8.

I don't think this is the main reason people like it. Java's lambdas are also inferior to Scala's.

>a Haskell-like algebraic type system (sealed traits and case classes)

What do case classes and traits have to do with types?

>It doesn't have Haskell's type safety

How so? Can you explain how you think Scala isn't sound/typesafe?

>It doesn't have OO's simple, highly extensible, and just-powerful-enough type system

Uhm, can you explain to me an example of a simple OO type system that is 'just powerful enough'? Because most of the ones I know of are broken, and Scala easily has the best OO type system. C#, java, Go, etc. are all either missing generics (lolwut) or completely fucked up variance.

Classes are types. And in Scala, case classes are just an awkward take on algebraic data types.

Scala doesn't even come close to Haskell. For one, it does not do anything to capture effects in the types. Apart from being markedly less safe, this also makes things like STM impractical. Additionally, implicits may be more powerful than typeclasses, but they're also easy to mess up: you lose canonicity. In Haskell, if you have a Set a, you know it uses the same ordering of a as any other Set a; in Scala, you lose this guarantee. You also don't have any notion of kinds, which makes quite a bit of otherwise-idiomatic code hard to write. Take a look at this post[1] for more examples and details.

[1]: http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...

If you want a simple yet powerful OO system, take a look at OCaml. It does OO much better than any other statically typed language I've used. The funny thing is, of course, that people don't use OCaml's object system--not because it's bad but because by the time you're using OCaml, you've already realized functional programming is the way to go. Most of the reasons I've heard for not using OCaml's object system apply even more to other OO languages!

OCaml's object types are expressive and, unlike Scala, fully inferable. And they don't mess variance up! You also get a dual sub-typing with polymorphic variants--I don't know if Scala can do anything comparable with case classes.

>You also don't have any notion of kinds, which makes quite a bit of otherwise-idiomatic code hard to write.

I'm not sure that is true. Otherwise this would not be possible: class MyExample[A[_]](a: A)

Yeah, I think that part was a bit inaccurate. The core problem is more like the fact that higher-kinded code is hard to write. You always end up writing in terms of concrete types--you can talk about A[_], but not about A by itself. This becomes a hassle when working with things like monad transformers.

> How so? Can you explain how you think Scala isn't sound/typesafe?

Because you can do casts, and it's not pure. It doesn't even enforce immutability. You know what? Forget about enforcing – it doesn't even make mutability or casts hard. Look, Haskell is certainly not my cup of tea. Personally, I don't think the effort of thinking about my program twice (once in terms of logic and once in terms of types) is worth it in most circumstances, and pure functional languages don't support concurrent data structures which is what I deal with the most. But I do recognize Haskell's elegance, and if the elaborate type system is worth it, it's only because it can enforce many guarantees. I mean, the whole point of Haskell is that it supposedly makes safer programs. So you pay for the elaborate types (though some consider it a plus), but you gain safety. With Scala you just pay.

> Uhm, can you explain to me an example of a simple OO type system that is 'just powerful enough'?

Sure. C++, Java, C#. Almost all of the world's software is written in C++ or Java. The question is not which language has "the best type system" (and even if it were, Scala can't make up its mind because it's got three of them). A type system is not an end but a means. Practically everyone who deals with type systems agrees that they come at a cost (and Martin Odersky himself admitted as much). But the cost hopefully buys you something. It arguably buys you better design, and it definitely buys you safety. Well, Scala doesn't give you safety any more than C++ or Java, and as for design, it can't even pick one type system; a cornerstone of great design is that you have to make hard choices.

>pure functional languages don't support concurrent data structures which is what I deal with the most

This is false, you were misinformed.

>Sure. C++, Java, C#.

C++ Has a good type system, IMO. The other two are broken. Literally, you can write broken code. Scala has a long list of warts, I just don't think you're listing any of them.

>Well, Scala doesn't give you safety any more than C++ or Java, and as for design, it can't even pick one type system; a cornerstone of great design is that you have to make hard choices.

This is just FUD. Are you telling me Java/C#'s type systems enforce more safety than Scala? Because they don't. They don't get variance right. Do you know what variance is? You ignored that part of my comment.

> They don't get variance right. Do you know what variance is? You ignored that part of my comment.

This can't be stated enough, and it's a huge problem in Java and C#. Unfortunately, most programmers don't care and simply continue to write broken code.

I don't have anything against correct variance, but just to play the devil's advocate, you do know that there are other ways to write correct code than with a "correct" type system, right? AFAIK, none of the safety-critical code running avionics, medical devices, guided missiles and operating systems has been written with a "correct" type system. And people "continue to write broken code" in any language.

> This is false, you were misinformed.

If I'm wrong, I apologize. I am not familiar with any concurrent data structures in a pure functional language, but I'd love to learn of any. I have not encountered a data structure in a functional language that supports more than one concurrent writer (and I don't mean parallel construction of an immutable DS - that's trivial – but concurrent mutation, like in a concurrent B-Tree, concurrent skip-list, or concurrent hash map).

I haven't checked anymore than glancing through the slides but it has the words "concurrent data structures in haskell" at the beginning:

http://www.scribd.com/doc/28336206/Multicore-programming-in-...

You are right! Didn't know about MVars. Got some learnin' to do now...

C++ has a good type system? C++ templates are just a copy-paste find-replace-all hack around type-system, they don't typecheck at all at the generic level. There is no notion of type variance nor dependent types. Not to mention many warts inherited from C (like being able to implicitly cast char arrays to booleans). It is IMHO much worse than even Java's (which is also not good).

Yet they are extremely powerful. Whatever their flaws may be, I have worked with your preferred version of templates (C# generics) and, let me tell you, they are inferior in every practical way.

Huh, where did I say my preferred version of templates were C# generics?

As of C++ templates being extremely powerful - I agree. But this is a similar kind of "powerfulness" as C macros are, only little safer. Technically they are still just a fancy macrogenerator working at the AST level instead of lexer level, knowing nothing about the types (you even have to tell it which symbols are the types, because it cannot reason it out from syntax). IMHO it is years behind true generic typesystems like in Haskell, OCaml or Scala and calling it a "type system" is an exaggeration.

Care to elaborate on C# 5 variance issues, please?

I don't see how a case-class is different than a non-case-class from a Type perspective? It was my impression it was just sugar around generating copy, equals, accessors, an Extractor and a companion-object.

I don't see how the sugar makes them a fundamentally different kind of Type system?

And Structural Typing is just Reflection I thought. It's still compile time (which is kinda the point). Which again doesn't feel like an alternative Type system.

But I'm not at all versed in Type theory so maybe I'm just mischaracterizing what a Type is...

> I don't see how the sugar makes them a fundamentally different kind of Type system?

They're not sugar. Their crucial feature is that they can't form an inheritance hierarchy, which doesn't work well in an algebraic type system.

> And Structural Typing is just Reflection I thought... Which again doesn't feel like an alternative Type system.

The point is that you can write (and obviously people have) a big, complex piece of software just with inheritance-based types, or just with algebraic types, or just with duck types. They all serve quite nicely. It is completely unnecessary to put them all in a single language (other than to advance compiler technology), and worse than that: putting them all together takes away their respective advantages and causes a lot of confusion.

I don't think you can write idiomatic Scala with any one of those things exclusively. And I don't see why you'd even try. You might as we'll be arguing that the language shouldn't have for-comprehensions, lambdas, pattern matching or keyword arguments the way I see it.

These things (types) do have uses, but not as competing systems in Scala, but Features. I want to write c#'s using() statement, I'm not especially worried about performance, I can't go and add IDisposable to everything because I want to use it with other people's code and I don't feel like writing a Type Class every time I need to work with a new type. Structural typing is a really convenient feature for that.

Case classes are just Scala's version of a data-object. If you didn't have them you'd just be writing your own version, poorly, and forgetting about hash code and equals and all the other stuff until it bit you.

I really don't see a rationale here for removing these other than you find it offensive. I use Scala because of these things.

How in the world is this the top upvoted response? All of this is either nitpicking, arguing over the meaning of words when the intended meaning is perfectly clear, stating an opinion without argumentation, and the rest is just plain false.

Enterprise does need scala. You can tell by the way any enterprise java codebase ends up with five different sets of annotations, two almost-compatible AOP systems and a clusterfuck of XML tying it all together.

Yes, scala is more complicated than java, considered in isolation. But you can write a large program in pure scala, rather than the bloated enterprise frameworks you end up with in java.

That's not a language issue but a library issue, and modern Java libraries are not like that at all. Hell, Scala programs use them just as much as Java programs do.

If anything, Java is showing that it can clean up years of cruft (Java EE 7 is pretty neat, and even the JDK is finally being modularize) while maintaining backwards compatibility. This is the kind of thing Enterprise wants and needs.

>>That's not a language issue but a library issue

What is this, 1985?

Libraries, frameworks and the community etc make the language these days.

I moved from Scala back to Java (not because I like Java so much, but because the current project requires it). And lambdas and traits are not the main features I miss. Much more I miss lazy evaluation, pattern matching, much better type system (variance, type classes, dependent types, even erasure is not that painful) and awesome collection library. None of those things are in Java 8, nor planned in any future version.

While Scala is indeed a bit overly complex (concept-wise), in practice working with both at an "enterprise" I've found it better overall than Java. Also, neither Kotlin nor Java 8 are available in non-beta form yet.

My biggest complaint about Scala isn't the language itself, but the flakiness/immaturity of some of the libraries/frameworks/tools compared to Java.

>> But seriously, it doesn't offer anything enterprise would want.

The only thing enterprise managers want is a language that can dumb down the art of programming to a level a programmers can be managed like assembly line workers. And that is what Java does exactly, an IDE that can make a novice and expert work at the same levels of productivity, extremely verbose code that gives an illusion of people building something big(even if its down right trivial). And most importantly programming effort can be accounted like a couple of least important replaceable folks down the hierarchy doing some assembling reusable units of material.

Change this scenario, a good technology with merit makes programmers very important and makes managers look like desk clerks.

Enterprise Managers don't care a least about type systems, lambdas, or traits or whatever. Most managers don't have a remote clue what those things are. Can the technology enable them to manage herds of programmers dumbed down enough to be managed like sheep? That is all they care.

No one (well, other than language designers) cares about traits and lambdas per se. People care about maintainability, performance, productivity, runtime diagnosability etc., and "enterprise managers" care about these things a lot. That is why the whole world, almost, switched from C++ to Java faster than it's taken the smallish Python community to switch from 2.7 to 3.0.

I won't go into an argument over verbosity, because Java is indeed verbose (about the same as Go and less than C or C++, that were what many in Enterprise used before). But as to the "assembly workers" kind of thing - it is far more complex than that. First, in no language is a novice as productive as an expert; not in Java, not in C and not in Haskell. Second, lots of enterprise projects are far from trivial. Some projects are so damn big that no matter what language you use, it's gonna take a couple of years, several million LOC, and at least several dozen developers, if not more than a few hundreds. Once that's the case, productivity means something else entirely, and yes, planning for team members coming and going is part of it; I think that in that respect Java hit a sweet spot. Obviously, it could be made better; it could be modernized. Personally, I also believe that the JVM is such a great polyglot platform, that projects should be written in several languages – yes, even in the enterprise.

Not all enterprise managers are stupid, and there are good reasons your bank doesn't run on Ruby or Python. Enterprise software technology changes all the time – yes, some of it is due to excellent sales team, but some of it is based on merit. You wouldn't expect that software technologies that are good for constantly pivoting SV startups would be equally good for running banks; or aircraft carriers. The requirements are just too different. Python has its place, as does Java. It's just not always the same place.

>it's much harder to integrate Java with Scala than with Clojure or Groovy, let alone Kotlin.

Your kidding right? Scala's Java interop is seamless compared to that of Clojure.

I'm not sure what you mean. Clojure's abstractions (seqs and maps) are completely compatible with Java collections and require no conversion in either direction, while Scala collections do.

You can actually make it automatically convert in both directions with just an import. But it is good practice to do it explicitly. In my opinion, for a typesafe language, this is a good way to do it.

The conversion, either implicit or explicit, is not free, neither in terms of performance, nor in terms of mental effort. This is not the case with Groovy, Kotlin and Clojure (though Java interoperability in Clojure does require more mental effort than in Groovy and Kotlin).

I would argue that Groovy and Clojure require just as much conversion (I have no idea about Kotlin). Scala and Clojure both require conversion if you want to use idiomatic data structures. I think Groovy is actually worse about this because you get secret implicit conversion to add meta classes and null objects. I've run in to a bunch of difficult to track down bugs where Groovy has forgotten to do these conversions.