Live data from Hacker News

Scala Feels like EJB 2

blog.joda.org

11–20 of 119 posts

Re: Scala Feels like EJB 2

#11
post #6

Scala's great, if you have a gorgeous Haskell program and you want to port it to the JVM. Unfortunately, by itself, that may be a niche market. If you want a dynamic language, you have lots of great choices. If you want powerful syntactic abstractions, you have Clojure, Lisp or Racket. You can win big with any of these tools. But some problems benefit from powerful mathematical abstractions, and that's where Haskell…

I think the reason why Scala is often used for these niche applications is that:

A) The language doesn't fall apart as soon as you try something not imagined by the original language creators.

B) Pushing the boundaries actually returns useful results.

C) Java isn't able to solve the given task or at least not productively.

That doesn't make Scala a non-general-purpose language. Probably the majority out there is using Scala as a better Java and is perfectly happy with it.

Re: Scala Feels like EJB 2

#12
Consider this method signature:

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

All this complexity to allow for automatic conversions (the following will return a Set[String]) ...

BitSet(1, 2, 3).map { _.toString + "!" }

In a dynamic language, the signature of map is simply this: (a → b) → [a] → [b]

The big difference is that the language doesn't care about types "a" and "b" until runtime. You're the one that cares about it, only on a need-to-know basis. Hence the implicit conversions become explicit (although conversions are less necessary) and code correctness is guarded by unit tests, which you need with Scala anyway. Also, the implementation of "map" in a dynamic language is something that a junior developer can come up with.

So the biggest problems I have with Scala:

    1) it is not readable
    2) it separates developers in two camps:
       library designers and users
    3) it does not provide clear benefits 
       over dynamic languages (Haskell does)

Re: Scala Feels like EJB 2

#13
post #5
post #4

Earlier quoted context omitted.

Steve's remarks on concurrency seem a totally fair observation to me, don't a large number of functional languages deal with concurrency through immutability and support that at the language level - I can think of Clojure, Erlang, Haskell, F# for example. The fact that it was possible to send a mutable message to a Scala actor made me extremely suspicious when I first used the language.

It's a relatively well acknowledged fact in the community that Scala's builtin actors are heavily flawed. This is why many of us switched to using Akka. It is also why there are currently plans to integrate Akka actors into the language itself, replacing the builtins. He does acknowledge that "It could become EJB3" which is a far sight better. But the tone of the rest of his post genuinely seems in conflict with this…

Even if the Actors are better, generally people still build programmes with lots of mutability. If don't start to build your application with concurrency in mind you will end up with problems later. With clojure you can be pretty sure that everything is threadsafe by deafault.

This is just how it seams to me from afar. I don't know if that is right.

Re: Scala Feels like EJB 2

#15
post #10
post #6

Scala's great, if you have a gorgeous Haskell program and you want to port it to the JVM. Unfortunately, by itself, that may be a niche market. If you want a dynamic language, you have lots of great choices. If you want powerful syntactic abstractions, you have Clojure, Lisp or Racket. You can win big with any of these tools. But some problems benefit from powerful mathematical abstractions, and that's where Haskell…

I don't see how Haskell or Scala are better in mathematical abstractions. I guess it would be equally easier (or even much easier) to abstract away this kind of thing in clojure, you could generate all the checking that you would get in Haskell/Scala. The only real diffrence I see is the compiletime checking, right?

Yeah, the big advantage of Haskell (and Scala) for abstract mathematical code is the compile-time type checking. Normally, I'm extremely happy with dynamic languages, because I make maybe 2 type bugs a year. I mean, it's not that hard to remember whether a variable contains an Employee or a String, and that's all you need for some programs.

But when you're designing a library, and a variable contains the free module over nullable real numbers, then the type checker is your friend. At least I can't keep that stuff straight without lots of help. And Haskell's ability to do compile-time dispatch on the desired return type of a function makes monads cleaner, too.

If you want to do this in Clojure, see "Typing Haskell in Haskell" http://web.cecs.pdx.edu/~mpj/thih/ , and whip up some macros that do Hindley-Milner type inference with type classes. And if you do, please e-mail me so I can play with it. :-)

Re: Scala Feels like EJB 2

#16
Everything's unreadable until one learns to read it. This is a classic non-argument that people buy into for reasons I can't comprehend. Is Scala harder to read than other languages? Perhaps, but then just say that.

As Rich Hickey pointed out recently, "I can't read German; does that mean it's unreadable?"

Re: Scala Feels like EJB 2

#17
post #5
post #4

Earlier quoted context omitted.

Steve's remarks on concurrency seem a totally fair observation to me, don't a large number of functional languages deal with concurrency through immutability and support that at the language level - I can think of Clojure, Erlang, Haskell, F# for example. The fact that it was possible to send a mutable message to a Scala actor made me extremely suspicious when I first used the language.

It's a relatively well acknowledged fact in the community that Scala's builtin actors are heavily flawed. This is why many of us switched to using Akka. It is also why there are currently plans to integrate Akka actors into the language itself, replacing the builtins. He does acknowledge that "It could become EJB3" which is a far sight better. But the tone of the rest of his post genuinely seems in conflict with this…

My personal experience in wrapping non-trivial Java libraries in Scala and Clojure is that with Clojure it usually just works and it works quickly. In Scala I am usually reduced to an extra hour or two of adding manifests to signatures until the compiler accepts it.

I am disappointed with Scala and having lived through EJB 1, EJB 2 and then onto Spring and EJB 3, I agree with Steve it makes me feel exactly the same as I felt about EJB 1 and EJB 2 - that is I am being sold overcomplicated technology as a panacea. I want a powerful language with a simple syntax, for example Lisp, ML or Haskell, not a powerful language with a complicated syntax like C++. Does Scala really want to be known as Java++?

I think the criticism of implicits is valid and should be addressed by the scala community, it is a frequent occurrence for me to be left scratching my head when reading code because something is bringing in an implicit declaration unbeknownst to me.

Also one complaint not made by Steve is compile times, reasonable in SBT, unreasonable using the typical build tool used in legacy Java projects.

Re: Scala Feels like EJB 2

#18

Consider this method signature: def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That All this complexity to allow for automatic conversions (the following will return a Set[String]) ... BitSet(1, 2, 3).map { _.toString + "!" } In a dynamic language, the signature of map is simply this: (a → b) → [a] → [b] The big difference is that the language doesn't care about types "a" and "b" until runtime…

Not only dynamically typed languages, the signature would also look remarkably close to (a → b) → [a] → [b] in ML and Haskell. Your ML and Haskell compiler would also make check that it was called correctly at compile time without extra unit tests.

Re: Scala Feels like EJB 2

#19
I've been picking up Scala on-and-off for the past few months. "Programming in Scala: Second Edition" is one of the best tech books I've ever read. The authors assume you already know how to program, offer mutable & immutable approaches to nearly everything, anticipate esoteric questions in the footnotes, and even have a good sense of humor.

The book also weighs in at 883 pages and I was astonished how much of it I needed to read to even get started. Once I did, I very much like what I saw. But I was a big fan of ML back in grad school.

I do share some of the blog author's gripes though. Most of the popular Scala libraries are just a mess of DSL operators that have no real world association. I'm constantly having to look up what an operator means. I still have no clue how to use the Dispatch library, since the concepts it encapsulates are about 400 pages deeper into the book than I'm currently at. This, just to issue an HTTP GET request. I really thought there might be something on the lines of Ruby's rest-client library.

Additionally, my issues with versioning occur at a much simpler level. The release notes of any given Scala release are devoid of anything useful. Usually it's just a list of JIRA issue numbers (not the issue titles). And then there was this whole debacle around 2.9.0.1 and how SBT called the version. That took me 4 hours longer to work than was really necessary.

So, anyway, I do have some Scala projects. Incidentally they're all Java interop because I just can't wrap my head around how to use most of the Scala-specific libraries. But I've found it works really well in those situations. Deep down I really do like the language. The Scala ecosystem leaves a lot to be desired, but fortunately I can pull in stuff from elsewhere on the JVM.

Re: Scala Feels like EJB 2

#20
post #4
post #3

A few things about this post. firstly it is never good when you start out a discussion by saying now I know people will disagree but thats because their bigoted zelots. Its kind of disingenuous to attempt to post a technical dissent filled with personal opinion and preface it with that kind of clause inevitability allowing you to label any dissent as "See those scala zelots are at it again" That being said this is an…

Steve's remarks on concurrency seem a totally fair observation to me, don't a large number of functional languages deal with concurrency through immutability and support that at the language level - I can think of Clojure, Erlang, Haskell, F# for example. The fact that it was possible to send a mutable message to a Scala actor made me extremely suspicious when I first used the language.

Functional Programming does deal with concurrency with immutability. And thats how you should deal with it in scala. The fact that you can use mutable constructs in concurrent program is no more a flaw of scala then the fact that I can execute any pointer in C as a function is a flaw of C.
Post reply on HN