Scala gods make me laugh.

General Discussions
#1

Scala is not complex! Honest.

:wink:

http://adriaanm.github.com/research/2010/10/06/new-in-scala-2.8-type-constructor-inference.html

(something simple and useful “explained” in the worst way possible, with terrible cryptic type variable names).

The Haskell spirit has arrived!
And it is in the Scala std lib.

Can you imagine a newbie trying to look into scala std lib to figure out how to code a map ;D.

Note that i’m not trying to attack the language, or it’s self image. I’m just saying why i think it will NEVER replace java for organizations coding. They went so far down type theory / number of character compression that even “simple” library concepts (and who didn’t do a library here) gets crazy.

#2

Maybe this specific article is not the best example. One of the articles at the bottom of his explanation is probably better, but they are of advanced topics anyway so would be complex or impossible anyway.

But i definitely laugh about it, no mistake.

#3

But i’m actually sad inside. A language with great concepts(mostly), updated std lib, topnotch collections - all hampered by a incredible need to write the least code possible.

Names are not noise.

#4

[quote]Scala uses local type inference to explicitly type parameters by type variables and track the subtyping constraints to determine type arguments that were not specified. For each expression that requires type arguments, the compiler types the unknown type parameters with type variables and collects the constraints that are required for the expression to type check, tracking the subtyping constraints that are required for this expression to type check.
[/quote]
Seems pretty clear to me! XD

#5

The example it’s clear if you disregard the short names. A generic type for types that take types. allowing one to make typesafe interfaces/abstract methods for methods that have different type signatures.

I don’t doubt that brain twisting applications are possible however.

BTW that quote didn’t parse for me. Seemed awfully circular. Maybe you’re being sarcastic, or i’m just that stupid.

#6

I wonder why did the scala designers bother with pattern matching. They obviously can do it in their brain just fine.

#7

Let’s see if i’m reading that right:


class Traversable[CC[x], T] {
  def filter(p: T => Boolean): CC[T]
  def retain(p: T => Boolean): CC[T] = filter(!p(_))
}

The list example is simple, but what about types that take more than one type argument, like map for instance. Am i right in thinking that this specialization makes

 T == [Key, Value]

and

CC[x] == Map[[Key, Value]]

Shouldn’t it be

CC[x] == Map[Key, Value]

?
How do they handle different numbers of type arguments?

#8

A different perspective that i hope is the case from the scala mailing list:

#9

"academic "

Someone wrote (don’t remember where), that Scala is a typical “academic” programming language. As far as that goes, it has already failed as a broadly accepted language. A programmer (his boss, his client) wants the problem solved, only an academic finds pleasure in using a language so syntactically complex.

#10

I had a lot of hope for Scala, I really liked sml (and ocaml not as much) but Scala really is a complex language. People like my certified Architecture Astronaut at my job have no clue about functional programming, let alone pattern matching or higher order functions. I do not think Scala will ever see wide spread adoption. In fact, I would’ve liked to have used it in personal projects, but it’s just too painful. Could you imagine writing a Swing app in Scala? Cringe.