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

41–50 of 119 posts

Re: Scala Feels like EJB 2

#41

Post by timclark »

soc88 wrote: post #36
masklinn wrote: post #28

Earlier quoted context omitted.

> 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.

Haskell has typeclasses which would probably correspond to structural typing in Scala. This type signature:

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

Defines map for any type that implements the type class functor. Lots of types will implement functor and it is easy to implement it yourself.

Re: Scala Feels like EJB 2

#42

Post by nickik »

ekidd wrote: post #15
nickik wrote: post #10

Earlier quoted context omitted.

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…

It is possible to build all kinds of crazy type stuff into any lisp. Look at Qi or Typed Racket they build all kinds of type-stuff into the language (Im not an expert in stuff like this so I don't know how far you could go). There are allready people working on this in Clojure.

A Typesystem in this still combind with some tools to check this befor you run the programm should provide almost everything you get from Haskell or Scala.

This kind of approach does yield the additional benefits:

1. Much easier to change

2. You can add another static analysing system ontop of it

3. Less restrictive

Re: Scala Feels like EJB 2

#43

Post by bad_user »

ekidd wrote: post #15
nickik wrote: post #10

Earlier quoted context omitted.

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…

Scala is not Haskell and in Scala you can only check if a variable contains an Employee or a String. The problem is that such types do not actually contain anything useful about the content within that object, it just says how the object behaves (the messages it responds to).

For instance, say you have a String ... well, a String containing what? A name? A regular expression? A number waiting to be converted to floating point? A bank account number? A phone number? An email?

I don't see compile-time type-checking in Scala as something useful, as most often than not it stands in my way. It does help to alleviate some bugs related to incorrect usage of types, but on the other hand you need tests with good code coverage anyway.

Re: Scala Feels like EJB 2

#44

Post by masklinn »

timclark wrote: post #41
soc88 wrote: post #36

Earlier quoted context omitted.

Haskell has no subtyping as far as I know Haskell.

Haskell has typeclasses which would probably correspond to structural typing in Scala. This type signature: Functor f => (a -> b) -> f a -> f b Defines map for any type that implements the type class functor. Lots of types will implement functor and it is easy to implement it yourself.

> Haskell has typeclasses which would probably correspond to structural typing in Scala.

Nah, typeclasses are nominative typing but added post-facto (you can define a typeclass instance for a third party's type). Typeclasses are similar to Scala's traits I think (I don't know if you can add traits to a library's types though).

Re: Scala Feels like EJB 2

#45

Post by noelwelsh »

nirvdrum wrote: post #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 n…

Many people, including experienced Scala developers (e.g. me), find Dispatch hard to use. The BlueEyes HTTP Client is much simpler:

   val client = new HttpClientXLightWeb
   client.host("somesite.com").get[ByteChunk]("/some/url")
That, plus some imports, is all you need

Re: Scala Feels like EJB 2

#46

Post by noelwelsh »

bad_user wrote: post #43
ekidd wrote: post #15

Earlier quoted context omitted.

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…

Scala is not Haskell and in Scala you can only check if a variable contains an Employee or a String. The problem is that such types do not actually contain anything useful about the content within that object, it just says how the object behaves (the messages it responds to). For instance, say you have a String ... well, a String containing what? A name? A regular expression? A number waiting to be converted to float…

The whole point of having an expressive type system is to encode useful properties in it. If a type of String isn't any use to you, give the value a more expressive type. Make a Name type, or a RegEx type, or whatever. Use unboxed types:

  http://www.chuusai.com/2011/06/09/scala-union-types-curry-howard/
if you don't want to pay an abstraction tax.

Re: Scala Feels like EJB 2

#47

Post by masklinn »

soc88 wrote: post #36
masklinn wrote: post #28

Earlier quoted context omitted.

> 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.

It does, but it does not support downcasting (it does support upcasting)

For instance, the Ord typeclass extends the Eq typeclass, so any instance of Ord can be used as an instance of Eq. But there is no way to cast an instance of Eq to an instance of Ord.

Re: Scala Feels like EJB 2

#48

Post by trurl »

timclark wrote: post #31
codelion wrote: post #29

Earlier quoted context omitted.

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?

You do realize the futility of such questions given Turing completeness, right?

It is not about what can be expressed, but about how you express things. You do not need function literals in Scala, but it is sure is more concise and cleaner than anonymous classes in Java. You do not need traits in Scala, but it avoids code duplication or the overhead of wrapper classes or proxies in Java. You do not need case classes and algebraic pattern matching in Scala, but it is far more concise and less error prone than having to write the obscene amounts of boilerplate you would write in Java.

And so on.

Re: Scala Feels like EJB 2

#49

Post by stephen »

noelwelsh wrote: post #45
nirvdrum wrote: post #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 n…

Many people, including experienced Scala developers (e.g. me), find Dispatch hard to use. The BlueEyes HTTP Client is much simpler: val client = new HttpClientXLightWeb client.host("somesite.com").get[ByteChunk]("/some/url") That, plus some imports, is all you need

Dispatch is so often used as an example of hard to read Scala code/operator overloading abuse, that I think it should be shuttered just for the greater good of the Scala community.

That being said, programmers can over-engineer things in any language; it's just that in Java, over-engineered things are "incomprehensible and huge" while in Scala over-engineering things are usually "incomprehensible and small".

Re: Scala Feels like EJB 2

#50

Post by bad_user »

noelwelsh wrote: post #46
bad_user wrote: post #43

Earlier quoted context omitted.

Scala is not Haskell and in Scala you can only check if a variable contains an Employee or a String. The problem is that such types do not actually contain anything useful about the content within that object, it just says how the object behaves (the messages it responds to). For instance, say you have a String ... well, a String containing what? A name? A regular expression? A number waiting to be converted to float…

The whole point of having an expressive type system is to encode useful properties in it. If a type of String isn't any use to you, give the value a more expressive type . Make a Name type, or a RegEx type, or whatever. Use unboxed types: http://www.chuusai.com/2011/06/09/scala-union-types-curry-howard/ if you don't want to pay an abstraction tax.

Maybe my example wasn't clear enough.

How about if you want to do stuff only with Employees with a salary greater than X? Consider this case ...

   a_employees = employees.filter{|x| x.salary > A}
   b_employees = employees.filter{|x| x.salary > B}

   # where A > X, B > X
   # so both should work with:

   def do_stuff(employees) where employees.salary > X
       ...
In other words, creating new subclasses is a poor substitute for code contracts, especially since many contracts could be checked at compile time.
Post reply on HN