4 ms·

You keep posting this argument. As a practicing Scala user, I think it's pretty unfounded. You could make the same "3 unnecessary type systems" argument about

by ssmoot 13y ago

You keep posting this argument. As a practicing Scala user, I think it's pretty unfounded. You could make the same "3 unnecessary type systems" argument about Ruby with attr_ methods, duck-typing, and classes. But I've never seen that. Maybe that's because if you're a fan of Ruby, the fact that it's Strongly Typed is pretty incidental. Things have Types, but if it's not enforced in any practical way, do you care? Pretty much not. It's a dead giveaway when people misunderstand what "expressiveness" means in the context of a type-system and go on to talk about how expressive Ruby is. Next to VBScript and JavaScript it's the least expressive language I know. Scala isn't Java++ for me. It's Ruby++. So maybe it's a case of differing backgrounds and expectations. I don't know Haskell. I went from VBScript, to JScript, to c#, to Ruby, to a smattering of Java, to Scala. So from my perspective this argument is as Ivory Tower as it gets (which is a bit ironic right?). It's like suggesting Ruby needs to remove attr_ methods, or Struct. It's like suggesting that all you need is eigenclasses and you shouldn't have any label following the "class" keyword. It's like suggesting Ruby must drop respond_to. And I have to wonder: What's the point? Would it make Ruby a better language? Is it going to make Scala a better language? No. Taking away my ability to emulate c#'s using() method with Structural Typing is not a step forwards, and it's most certainly not a case of "good design". So eliminate case-classes? Why? Limit yourself to bolting on properties, equality, hash codes, etc ad-hoc? What's the point of any of that? It's definitely a step backwards in ease-of-use. This is the very opposite of a practical or pragmatic critique. There are problems with Scala sure. That it simplifies a lot of boiler-plate (and really enables the FP/OO bridge) with a keyword (case class) and syntax (structural typing) isn't one of them from my perspective.

pron 13y ago
Ruby (in which I've written no more than maybe 100 LOC) is great for what it does, but no one in their right mind is going to build a 10 MLOC aircraft-carrier control software in Ruby. Ruby's main goal is fast prototyping and fun initial development, a goal which it accomplishes beautifully. It is not a language for big engineering undertakings. But Scala tries to compete with Java, and you would write a 10 MLOC aircraft-carrier control software in Java. Once you're dealing with big engineering efforts, out-of-the-box ease-of-use is no longer your main concern; it's not even among the top five concerns, but complexity certainly is. I don't have a problem with Scala as a Ruby replacement. I do have a problem with it as a Java replacement.
- dragonwriter 13y ago
  > Once you're dealing with big engineering efforts, out-of-the-box ease-of-use is no longer your main concern; it's not even among the top five concerns, but complexity certainly is. If you are writing massive software to handle comprehensive control for an aircraft carrier, you'd better be writing it in loosely-coupled components with well-defined interfaces, or its going to be a maintainability nightmare no matter the language features. If you are doing that, Scala's flexibility lets you, internal to each component, take the approach most suitable for the team responsible for that component addressing that components requirements. I can see where Scala's flexibility could make a bad situation worse if you are writing an enormous piece of software but not doing it in loosely coupled components but instead doing a tightly coupled nightmare -- the OO equivalent of spaghetti code -- but, even though it might be less of a disaster, that's still going to be disaster in Java or C#, too.
eranation 13y ago
> Scala isn't Java++ for me. It's Ruby++. Exactly! I wish more people knew both Scala and Ruby well enough to notice it

by ssmoot 13y ago

pron 13y ago

Ruby (in which I've written no more than maybe 100 LOC) is great for what it does, but no one in their right mind is going to build a 10 MLOC aircraft-carrier control software in Ruby. Ruby's main goal is fast prototyping and fun initial development, a goal which it accomplishes beautifully. It is not a language for big engineering undertakings. But Scala tries to compete with Java, and you would write a 10 MLOC aircraft-carrier control software in Java. Once you're dealing with big engineering efforts, out-of-the-box ease-of-use is no longer your main concern; it's not even among the top five concerns, but complexity certainly is. I don't have a problem with Scala as a Ruby replacement. I do have a problem with it as a Java replacement.

dragonwriter 13y ago
> Once you're dealing with big engineering efforts, out-of-the-box ease-of-use is no longer your main concern; it's not even among the top five concerns, but complexity certainly is. If you are writing massive software to handle comprehensive control for an aircraft carrier, you'd better be writing it in loosely-coupled components with well-defined interfaces, or its going to be a maintainability nightmare no matter the language features. If you are doing that, Scala's flexibility lets you, internal to each component, take the approach most suitable for the team responsible for that component addressing that components requirements. I can see where Scala's flexibility could make a bad situation worse if you are writing an enormous piece of software but not doing it in loosely coupled components but instead doing a tightly coupled nightmare -- the OO equivalent of spaghetti code -- but, even though it might be less of a disaster, that's still going to be disaster in Java or C#, too.

eranation 13y ago

> Scala isn't Java++ for me. It's Ruby++. Exactly! I wish more people knew both Scala and Ruby well enough to notice it