Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Feels like EJB 2

blog.joda.org

Post reply on HN
Print view View original

31–40 of 119 posts

Re: Scala Feels like EJB 2

#31

Post by timclark »

codelion wrote: post #29
timclark wrote: post #23

Earlier quoted context omitted.

Is it easy for programmers of all abilities to understand and use? Will I still understand my own code in 9 months time? I think that their is more to being a good language than a list of features.

The list of features were meant to just illustrate that Scala is not some programming fad, it is strictly more expressive than Java and based on solid programming language principles. Although,I agree the code may not be easy to understand for everyone in the beginning but with effort and training I believe every programmer can learn enough of it to be more productive.

What can you express in Scala that you can't express in Java?

Re: Scala Feels like EJB 2

#32

Post by sllrpr »

dkhenry wrote: post #20
timclark wrote: 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.

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.

Many would argue that this is a flaw of C.

Re: Scala Feels like EJB 2

#33

Post by tome »

soc88 wrote: post #21
timclark wrote: post #18

Earlier quoted context omitted.

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.

The difference is that Scala also abstracts over the "container" not just the contents. If Scala only did what ML and Haskell do, the type signatures would be exactly that.

Are you hinting at Haskell's fmap? The type signature is significantly simpler:

fmap :: Functor f => (a -> b) -> f a -> f b

Re: Scala Feels like EJB 2

#34

Post by vetler »

timclark wrote: post #27
soc88 wrote: post #21

Earlier quoted context omitted.

The difference is that Scala also abstracts over the "container" not just the contents. If Scala only did what ML and Haskell do, the type signatures would be exactly that.

Can you explain the scala type signature for map? I see no container declared and it is less than obvious to me how it actually represents map across a container. I guess it is the implicit?

I'm a Scala newbie, and it did not take me long to actually understand the type signature here. Of course, when I first saw it I was confused, but it's not magical.

There are probably map-methods elsewhere, but let's take the map defined on TraversableLike[0]. TraversableLike is a base trait for all kinds of Scala collections (let's just pretend trait is like an interface for now, look it up if you're interested in the details).

TraversableLike has two definitions of map in 2.9.1:

  def map [B] (f: (A) ⇒ B): Traversable[B]

  def map [B, That] (f: (A) ⇒ B)(implicit bf: CanBuildFrom[Repr, B, That]): That
The first one isn't so bad, is it? The first one takes a function converting objects of A to objects of B, and returns something that is traversable of B (i.e. perhaps a List[B] or Set[B]).

The second one can return anything you want, as long as you have a function that describes how the objects can be converted. That is what the implicit is for. For instance, if you map a collection over a function that returns a list of integers, but you actually wanted a set of strings - you can define a function that converts your List[Int] to Set[String]. I recently found a description of canBuildFrom on Stack Overflow that explains this in a bit more detail[1].

As a Scala beginner I find that I often can't expect to understand everything at once - a lot of times it's like other languages, but when it's not I usually can't just guess what it does, but actually have to take time to learn it. I don't think this is a bad thing.

[0]: http://www.scala-lang.org/api/current/index.html#scala.colle...

[1]: http://stackoverflow.com/questions/1721356/scala-2-8-canbuil...

Re: Scala Feels like EJB 2

#35

Post by adabsurdo »

i used scala for a few months. it sounded very promising, java without the verbosity. but in the end i decided to stop using it.

The biggest problem for me was readabilty. Scala is the first language that i've learned where at first i couldn't just read code and immediately guess what it does.

I think the prime reason for this is that scala permits operator overloading; more than that, in fact, almost every character can be an identifier. This results in often very cryptic code and libraries, because you can't guess what that function does without reading its definition. quick, what's the difference between +++ and ::: ? what's /: and /:\ ? You can't even google it!

The other big problem for me was the type system. At first it sounded really great, and in fact the amount of compile-time code verification that you can achieve is indeed impressive. But in practice, i found myself fighting with the type system a lot, for example when trying to reuse a function with generic type restrictions that I had't written: some time these can get very long and your only choice is to copy-paste them from the original definition.

Also, how do you test that your type constraints are correct? you can't, by definition, write compilable code that would invalidate them.

Finally, it turns out that a lot of the bad stuff that's in java ends up in scala also, because of runtime compatibility concerns. in particular, scala's generics are an extension of java's. so, for example, almost all generic type information is lost at runtime, except for some extra metadata that scala stores in the object. this results in pretty ugly code when you have a dynamic object and you need to use it with a generic method.

Re: Scala Feels like EJB 2

#36

Post by soc88 »

masklinn wrote: post #28
soc88 wrote: post #21

Earlier quoted context omitted.

The difference is that Scala also abstracts over the "container" not just the contents. If Scala only did what ML and Haskell do, the type signatures would be exactly that.

> The difference is that Scala also abstracts over the "container" not just the contents. Haskell is perfectly able to do that as well if desired. `[]` is a monadic type.

Haskell has no subtyping as far as I know Haskell.

Re: Scala Feels like EJB 2

#37

Post by bad_user »

vetler wrote: post #34
timclark wrote: post #27

Earlier quoted context omitted.

Can you explain the scala type signature for map? I see no container declared and it is less than obvious to me how it actually represents map across a container. I guess it is the implicit?

I'm a Scala newbie, and it did not take me long to actually understand the type signature here. Of course, when I first saw it I was confused, but it's not magical. There are probably map-methods elsewhere, but let's take the map defined on TraversableLike[0]. TraversableLike is a base trait for all kinds of Scala collections (let's just pretend trait is like an interface for now, look it up if you're interested in t…

     it did not take me long to actually understand 
     the type signature here
Bullshit. You just followed somebody else's public explanation. Not a problem per se, but this doesn't strike me as beginner friendly ... Dr. Brian Beckman also has a great description of monads on Channel9 that doesn't involve category theory. Does that mean that monad comprehensions are also beginner friendly?

     if you map a collection over a function 
     that returns a list of integers, but you 
     actually wanted a set of strings
Here's some Ruby code for you:

     [1,2,3].map{|x| x * 2}.map{|x| x.to_s}.to_set
Ironically I find this code written in a dynamic language to be much more readable. Also, give me first-class functions and recursion in a dynamic language and I can implement all of the above by my own (lists, sets and map).

Re: Scala Feels like EJB 2

#38

Post by trurl »

codelion wrote: post #22

Most of the comments here talk about how whatever useful can be done in Scala can be done in some other language. That is not the point, Scala is a good language because - Compatible with JVM - Strong type system - Linear Typing - Substructal Types - Local Type inference - Concurrency constructs built in as actors (Akka) - Integration of OO and functional paradigms - Supports Higher Order Programming - defn-site Vari…

Unless there are some very recent experimental extensions that I have not heard about, Scala does not have support for linear or substructural typing.

I suspect you are thinking of structural subtyping, which is a completely different concept.

Re: Scala Feels like EJB 2

#39

Post by jorgeortiz85 »

tome wrote: post #33
soc88 wrote: post #21

Earlier quoted context omitted.

The difference is that Scala also abstracts over the "container" not just the contents. If Scala only did what ML and Haskell do, the type signatures would be exactly that.

Are you hinting at Haskell's fmap? The type signature is significantly simpler: fmap :: Functor f => (a -> b) -> f a -> f b

That doesn't capture the type of the original example.

    BitSet(1, 2, 3).map { _.toString + "!" } // returns Set[String]
The Scala code here starts with one Functor (BitSet) and returns a different Functor (Set), depending on the type of the function (in this case, Int => String). If the function had type (Int => Int), it would still return a BitSet.

The signature for fmap does not encode this flexibility.

Re: Scala Feels like EJB 2

#40

Post by vetler »

bad_user wrote: post #37
vetler wrote: post #34

Earlier quoted context omitted.

I'm a Scala newbie, and it did not take me long to actually understand the type signature here. Of course, when I first saw it I was confused, but it's not magical. There are probably map-methods elsewhere, but let's take the map defined on TraversableLike[0]. TraversableLike is a base trait for all kinds of Scala collections (let's just pretend trait is like an interface for now, look it up if you're interested in t…

it did not take me long to actually understand the type signature here Bullshit. You just followed somebody else's public explanation. Not a problem per se, but this doesn't strike me as beginner friendly ... Dr. Brian Beckman also has a great description of monads on Channel9 that doesn't involve category theory. Does that mean that monad comprehensions are also beginner friendly? if you map a collection over a func…

> Bullshit. You just followed somebody else's public explanation.

If you're referring to the stack overflow answer, then no. I understood the signature by learning Scala (by reading a book). Is that cheating?

> Does that mean that monad comprehensions are also beginner friendly?

No, not necessarily. Do you have to understand what that even means to be able to use Scala?

Post reply on HN