Live data from Hacker News

On Scala's future

antoniocangiano.com

1–10 of 16 posts

Re: On Scala's future

#2
My guess is (a). Scala is a really interesting language, and has some serious (and undeniable) benefits, but the Scala community seems to have the same permafrost problem that torpedoed Python, as well as a bit of 'technical excellence over everyday practical value' (e.g., Scala's proliferation of operators and syntactic magic).

Re: On Scala's future

#3
post #2

My guess is (a). Scala is a really interesting language, and has some serious (and undeniable) benefits, but the Scala community seems to have the same permafrost problem that torpedoed Python, as well as a bit of 'technical excellence over everyday practical value' (e.g., Scala's proliferation of operators and syntactic magic).

In what way is Python torpedoed or permafrosted?

Re: On Scala's future

#4
post #2

My guess is (a). Scala is a really interesting language, and has some serious (and undeniable) benefits, but the Scala community seems to have the same permafrost problem that torpedoed Python, as well as a bit of 'technical excellence over everyday practical value' (e.g., Scala's proliferation of operators and syntactic magic).

How do Actors not solve real day to day concurrency problems that we face all the time?

And the 'technical excellent' stuff like internal DSL are there if you want them, but you can safely ignore them. Maybe only library designers will use some of the more advanced features, but it is awesome having them available.

Re: On Scala's future

#5
post #4
post #2

My guess is (a). Scala is a really interesting language, and has some serious (and undeniable) benefits, but the Scala community seems to have the same permafrost problem that torpedoed Python, as well as a bit of 'technical excellence over everyday practical value' (e.g., Scala's proliferation of operators and syntactic magic).

How do Actors not solve real day to day concurrency problems that we face all the time? And the 'technical excellent' stuff like internal DSL are there if you want them, but you can safely ignore them. Maybe only library designers will use some of the more advanced features, but it is awesome having them available.

Re-read my post; Actors are incredibly useful, and I like the idea behind Scala's type system -- bind things together with contracts, explicitly declare types only when you have to, and let the compiler handle the rest.

Let me repeat: I like Scala. I just wish that the Scala creators had avoided creating a syntax that is almost, but not entirely, quite unlike Java.

Look at Lift -- fast, scalable, and may as well be written in Greek. What is '_ ::'? What about '(something _)' and '(__ thing __)'? Why does Lift require that the programmer require goat-sacrifices to Maven to get things working?

It's very newcomer-unfriendly, and Scala people tend to be incredibly defensive of the language's odd syntax... and really hostile towards dynamic languages. Both static and dynamic-typed languages have their place in the programming world, so accept that and move on.

Re: On Scala's future

#6
post #2

My guess is (a). Scala is a really interesting language, and has some serious (and undeniable) benefits, but the Scala community seems to have the same permafrost problem that torpedoed Python, as well as a bit of 'technical excellence over everyday practical value' (e.g., Scala's proliferation of operators and syntactic magic).

I'm also confused by your dislike of operators and syntax sugar. These are some of the things that made Ruby so popular, and the sort of ham-stringing that make Python and Java so long-winded and painful... If you're worried about n00bs shooting themselves in the foot, that's really a matter of training -- you wouldn't give all soldiers single-shot rifles just to make sure the new recruits couldn't lose control of an automatic. Later on, those "technical excellences" may be exactly the right spanner for the bolt.

Re: On Scala's future

#7
post #2

My guess is (a). Scala is a really interesting language, and has some serious (and undeniable) benefits, but the Scala community seems to have the same permafrost problem that torpedoed Python, as well as a bit of 'technical excellence over everyday practical value' (e.g., Scala's proliferation of operators and syntactic magic).

What happens when you don't have operators and sugar? You get ten-times-worse unreadable mess like anonymous inner subclasses. You get a dirty mix of a+b and a.add(b). And finally, you get a language that has to be extended with revisions of the core, rather than with libraries.

Scala's operators are OK, but Haskell's are better yet because of the concept of a typeclass. You can't abuse + because it comes bundled with -, instances which support < are guaranteed to support ==, and so on. Operators actually have meanings that aren't arbitrary.

Re: On Scala's future

#8
post #5
post #4

Earlier quoted context omitted.

How do Actors not solve real day to day concurrency problems that we face all the time? And the 'technical excellent' stuff like internal DSL are there if you want them, but you can safely ignore them. Maybe only library designers will use some of the more advanced features, but it is awesome having them available.

Re-read my post; Actors are incredibly useful, and I like the idea behind Scala's type system -- bind things together with contracts, explicitly declare types only when you have to, and let the compiler handle the rest. Let me repeat: I like Scala. I just wish that the Scala creators had avoided creating a syntax that is almost, but not entirely, quite unlike Java. Look at Lift -- fast, scalable, and may as well be w…

Lift strikes me as the worst thing to happen to Scala.

It's a Ruby-like language in flexibility, something like Camping or Sinatra is a much better representation of Scala style than a do-everything Rails rewrite with a hard-on for Comet.

Re: On Scala's future

#9
post #6
post #2

My guess is (a). Scala is a really interesting language, and has some serious (and undeniable) benefits, but the Scala community seems to have the same permafrost problem that torpedoed Python, as well as a bit of 'technical excellence over everyday practical value' (e.g., Scala's proliferation of operators and syntactic magic).

I'm also confused by your dislike of operators and syntax sugar. These are some of the things that made Ruby so popular, and the sort of ham-stringing that make Python and Java so long-winded and painful... If you're worried about n00bs shooting themselves in the foot, that's really a matter of training -- you wouldn't give all soldiers single-shot rifles just to make sure the new recruits couldn't lose control of an…

Care to elaborate? I've never considered Python to be nearly as 'long-winded and painful' as Java.

Re: On Scala's future

#10
post #5
post #4

Earlier quoted context omitted.

How do Actors not solve real day to day concurrency problems that we face all the time? And the 'technical excellent' stuff like internal DSL are there if you want them, but you can safely ignore them. Maybe only library designers will use some of the more advanced features, but it is awesome having them available.

Re-read my post; Actors are incredibly useful, and I like the idea behind Scala's type system -- bind things together with contracts, explicitly declare types only when you have to, and let the compiler handle the rest. Let me repeat: I like Scala. I just wish that the Scala creators had avoided creating a syntax that is almost, but not entirely, quite unlike Java. Look at Lift -- fast, scalable, and may as well be w…

I can't comment on lift since we use scala with WebWork/struts2.

Testing with specs and mockit has been much easier for us than in the bad ole Java days.

  val m = mock[java.util.List[String]] // a concrete class would be mocked with: mock(new java.util.LinkedList[String])
  // stub a method call with a return value
  m.get(0) returns "one"

  // call the method
  m.get(0)

  // verify that the call happened, this is an expectation which will throw a FailureException if that is not the case
  m.get(0) was called

  // we can also check that another call did not occur
  m.get(1) wasnt called // or m.get(1) was notCalled
http://code.google.com/p/specs/wiki/UsingMockito

Being able to write a test like this seems like a pretty big win.

re: newcomer-unfriendly, the people I've spoken with all seem really excited about the language and want to share the love. shrug

Post reply on HN