13 ms·

Scala: sharp and gets things cut

91 points by SanderMak 13y ago

mercurial 13y ago
> I am a great programmer and I choose static type systems because I demand sharp tools. > Of course by taking this position you run the risk of pushing a fallacious, authority-based angle. However, in the weak or strong case you’re already pushing anecdotes around, so you may at least choose the one that is open for objective measurement. Which part is open to "objective measurement"? I don't know if I'm a good programmer, whatever that is, but I use static type systems when I want a system to work both today and tomorrow after I refactor it.
- monstrado 13y ago
  These are all very subjective statements, things like "I choose ... because". If you asked 20 programmers why they like statically typed languages, I am willing to bet you will get quite the variety of answers. Personally, I think statically typed languages scratch an itch that is different from programmer to programmer.
  - mercurial 13y ago
    Ah, but the difference is that I'm not claiming my statements are open to "objective measurements" :)
nathansobo 13y ago
I also found his talk fascinating, but the paper he referred to was a bit unapproachable for me. Any suggestions for resources that could help get me more comfortable with reading and understanding type calculi?
- zeckalpha 13y ago
  Here's the Milner paper which describes ML's type system. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.5276&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.... Wikipedia also helps: https://en.wikipedia.org/wiki/Type_rules https://en.wikipedia.org/wiki/Type_rules
- gruseom 13y ago
  Pierce's book (the standard text) is surprisingly readable, at least compared to what I expected.
jaxytee 13y ago
Scala transcends the static vs dynamic typing debate via it's duck typing. Because of it's implementation of implicits, you get static type checking along with the flexibility of a language like JavaScript or Python. IMO This puts Scala head and shoulders above the rest of the programming world in terms of language design.
- anonymoushn 13y ago
  Scala lets you spend lots of time typing incomprehensible type signatures and gives you less type safety than ML-family languages in exchange. Truly it is the pinnacle of PL design!
  - mcv 13y ago
    Yeah, I hate those incomprehensible type signatures. Just give me an Object and I'll match with the type I need.
    - _random_ 13y ago
      I have a better idea! Let's just use strings for everything!
      - virtualwhys 13y ago
        thanks for the chuckle
    - anonymoushn 13y ago
      I certainly hope you don't give me an Object. That would mean I still haven't escaped the JVM! Just give me HM and I can write type safe code without typing types.
- laureny 13y ago
  > Scala transcends the static vs dynamic typing debate via it's duck typing. Hardly anyone uses duck typing in Scala (you probably mean structural typing, by the way). There are plenty of articles explaining why structural typing is a bad idea, here is one: http://goo.gl/0wcNFO http://goo.gl/0wcNFO
barrkel 13y ago
I think you missed the point of that line. Type annotations let you get the shape of the data structure out of your head and into code. The compiler can then ensure that you're using the data structure properly. Whereas if you're using a dynamic language without type annotations, you need to keep the shape of the data in mind; after that array index, hash lookup, function call, you need to know what kind of thing it is you've got in hand, and what you can do with it. Sure, you write tests to exercise the code and flush out the mistakes, but that isn't as tight an iteration cycle as a compiler - if living in an IDE, the cycle may be as low as a few milliseconds. And this is the point of the "not a great programmer" comment. Making progress even though you don't have the entire map of the whole program's data structures in your mind all at once. Having said that, I think this ability to deal with a lot of complexity in working memory can be detrimental to good code, even in typed languages. I've worked with some talented programmers that had an enormous capacity for complexity, but that very complexity made them less inclined to abstract their code. In fact, because they had less need for abstraction, their abstraction skills overall were poorer.
- mcv 13y ago
  > Type annotations let you get the shape of the data structure out of your head and into code. This is by far the best argument for static typing I've ever heard. I'm not a big fan of static typing (mostly due to Java). I like Scala, but I think its type system is way over the top. For the most part, I care about rapid development, and you'll always need unit tests anyway, so they can also test your types for you. And Scala type matching in its builtin switch statements can always get my type back when I get handed an Object. With tools like that, I don't really need absolute type safety. But getting the shape of your data structures out of your head, that's definitely an advantage.
pron 13y ago
There are so many problems with Scala, that the question of static vs. dynamic typing becomes secondary. Static typing could well be downright awesome, but Scala is still a mess. I'm repeating the same line for the third time today, but I find that Scala is for people who find Haskell too simple, and want to add mutability, inheritance and macros on top of it, while dropping safety, purity, and much of the type inference (and I'm certainly not a Haskell fan, but Scala makes Haskell seem like Logo). For the life of me I can't understand what the language designers want, or how they think software should be written. It seems like they're finding it a fun challenge to see how many features from different languages can fit in a single compiler, and they justify each feature as necessary to solve some arcane problem. I think it's the complete opposite of languages like Clojure and Erlang (or Java, even), whose designers started by pondering the major issues of software development, and tried to come up with a coherent solution, rather than pile on features, each plugs a specific hole, without any fundamental organizing principle.
- justin_hancock 13y ago
  I think you've hit the nail on the head with Scala. It feels every conceivable concept in language research has been thrown in. The lack of coherency is sometimes quite jarring. Coherency/conceptual integrity are things I look for in computing environments they make reasoning things much simpler as logical deductions can be made, I don't find myself doing that with Scala.
  - eropple 13y ago
    Your mileage may certainly vary, but having used Scala pretty steadily for the last year, I find the strong majority of Scala code I see in practice generally very easy to intuit. You can do stupid things with it--see Scalaz, which is bad ideas[1] given form--but for the most part, people don't. I used to have the same concern you're expressing, and a few others besides--I've written comments on HN along the lines of "I'm writing Scala that I can't read the next day"--but I got past that stage not too long afterwards, and I find it remarkably predictable and consistent in everyday use. [1] - this isn't a fair characterization, see deeper in the tree
seanmcdirmid 13y ago
The article is weird. Martin Odersky is an incredibly good programmer, just dive into the source code of scalac, he was probably just being modest to make a point.
- lnanek2 13y ago
  I think it is a better way to phrase it anyway. If you say you are an awesome programmer and since you are awesome your decision to use static typing to get you better compile errors and help your development is right, then people can just argue that you suck. But if you say you suck and static typing allows you to suck less, what are they going to say? It's pretty widely admitted that languages need to help developers suck less to succeed, see Java removing multiple inheritance, operator overloading, etc. and becoming the premier business language. These were power features that made it easy to shoot yourself (and team members) in the foot.
- barrkel 13y ago
  Think of Odersky's line in the same vein as bwk's "debugging is twice as hard..." line, about not using all your smarts in the code you write.
badman_ting 13y ago
I agree strongly with the statement the author calls out. Stop believing in yourself and your amazing abilities, and embrace your incompetence. Stop talking about what a great marksman you are, look down at your bullet-ridden feet at long last, and embrace tools that make it harder to shoot yourself in the foot. This weekend I found a collection of Javascript tests meant to evaluate one's abilities. I spent an hour trying to get the project to run, so I could take the tests, but it was all built on piles of Jello. A bunch of slightly-incompatible versions of libraries and frameworks and shit, so that 3 months after its release I couldn't use it. Stop the madness. Build shit to last and stop using things that make your next 5 seconds in emacs slightly easier at the expense of everyone else.
DanielRibeiro 13y ago
This is an interesting post. I worry though that Odersky's point can make people think that there are only two kinds of type: static, or dynamic. James Iry did an amazing overview of the nuances of various kinds of type systems on his Types à la Chart. [1] http://james-iry.blogspot.com/2010/05/types-la-chart.html http://james-iry.blogspot.com/2010/05/types-la-chart.html
programminggeek 13y ago
I think that typing is useful, but I say that as someone who wrote a bunch of type checking code on top of Ruby to make my boundaries cleaner and more sane. It made my code a lot nicer to work with, but I quickly realized that what I really would prefer is strong interfaces and typing at the boundaries. Thus, scala, go, java, c++, etc. make a lot of sense to me because you gain performance and stronger boundaries are baked into the language. I want strong typing because it makes my code better. I want it built into the language because it makes my code cleaner.
Aqueous 13y ago
Maybe it would be better to say, "I'm a pretty good programmer. However, I'm not perfect, and I make mistakes. Static typing helps minimize the mistakes." The one thing I don't like about Scala is type inference. We spend all that time specifying the exact type of parameters and return values, but then we can just lazily declare an immutable value val, set it equal to a return value of a function, whose signature is in different file, and from a quick glance at the code we can not tell what 'val' is. it might be convenient in the short run, and splits the difference between convenience of dynamic typing and the precision of static typing, but it does so at the cost of readability.
- gohrt 13y ago
  The type of that value is the type returned by that function. If you want to see what that type is, look at the function. That's not as weird as it sounds. Consider: int x = foo(2); What is x? OK, you know it is an "int", due to the redsundant declaration. But that's not useful to you the programmer. int foo(int n) { return n+1 } Ok, foo is successor. But you have to look at the definition to remind yourself that. Why not put that in the declaration of x as well?
- benmccann 13y ago
  There are numerous places I find Scala has preferred brevity over readability and it does not take long for that choice to take it's toll when you have many people working on a project. Yours is a perfect example. Another is allowing multiple ways of importing such as allowing relative imports. When I've tried to use Scala it's much more of a pain to figure out where some classes are coming from whereas in Java it's immediately obvious from the import at the top of the file.
- RivieraKid 13y ago
  That's exactly one of my many complains about Scala (and about type inference in general). Type annotations are not there just for the compiler, they also help readability / documentation.
- lmm 13y ago
  If you feel a particular value needs an explicit type you can always include the type in the declaration. Or your development environment should be able to tell you what type it is. I do think scala needs an IDE to be used effectively, at least if you're making heavy use of implicits and inferred types (and, as a sibling mentions, indirect imports). But I think that's ultimately a good thing: it uses the power available to us nowadays to allow a more compact representation of code than would be acceptable in a plain text file (which is good for readability - AIUI evidence is that code readability takes a big hit as soon as a function spans more than one screen). Rather than throwing away the convenience of text like the '80s "visual programming" efforts, it's more of a "progressive enhancement".
auggierose 13y ago
Scala is the best language out there today for general purpose programming, FULLSTOP. Many people complain about the complexity of Scala, or how many features it has, etc. Yes, there are some odd features (I am looking at you, native XML support), but these are features I NEVER use. Just learn the fucking type system (it's not that hard, all you need to understand for most of your coding is [A], [+A] and [A <: B] and you are set) and stick to the features you like / understand. To those who praise the purity of Clojure: That is nice, but comes with a high prize. For example that you have to wait for something like Clojure.Typed, which is already a non-issue with Scala, because Scala comes with BATTERIES INCLUDED. Complaining that Scala has too many features is like complaining that Clojure has too many libraries.
- lawn 13y ago
  Using capslock will surely make your point come across better, or not. Complaining that Scala has too many features is like complaining that C++ has too many features, which is a valid complaint.
  - auggierose 13y ago
    C++ is a dangerous and unsafe language, so you need to be aware of every little detail. That's why many features in C++ are a problem. Scala runs on the JVM. That and the saner design of Scala makes it much safer to code in Scala than in C++, and what you don't know in Scala, usually doesn't hurt you. By the way, I didn't use capslock, I used shift.
- icebraining 13y ago
  stick to the features you like / understand. Doesn't that only work if you're coding in isolation from bottom up? As soon as you include some library or start collaborating with someone who likes a different subset, you can't simply stick to what you know.
  - auggierose 13y ago
    That might be a good point. You should come to an understanding with your collaborators on the subset you code in. That may be more difficult in an open-source setting. BUT: This is even exaggerated in Clojure, where you are forced to learn all the little libraries your collaborators use...
asdasf 13y ago
His assumption is incorrect: >but I suspect it’s an attempt to counter the idea that strong static type systems like Scala’s are complicated. Nope. It is simply stating the reason we use typed languages. Because we are human beings, and make mistakes. Having a compiler automatically tell us when we make those mistakes is very helpful. That's it. It has nothing to do with "sharp tools", which untyped advocates also claim their tools to be. It is simply that type systems can find a large number of bugs, at compile time, with 100% certainty.
aklein 13y ago
"I am a great programmer and I choose static type systems because I demand sharp tools." I strive to build correct software, and I leverage a static type system to enforce the absence of incorrect program behavior. Any other benefits are just niceties.
- ajanuary 13y ago
  * to enforce the absence of certain classes of incorrect program behaviour
sandGorgon 13y ago
There is a lot of focus on haskell vs scala and deep intricate discussions about type systems, but here's a question - how is scala as a better java ? For my purpose (working with hadoop), it has proved to be more than adequate - I get a repl to work with java classes (serious productivity jump over those who have to work with vanilla java), I dont have to muck about with classnames <> filename mapping. I come from the JRuby world and I have a secret fetish for Clojure - but the near-Java performance of Scala is impossible to argue against. My biggest, biggest problem is sbt - it is fairly sucky, since it inherits Maven's Madness. Pet peeve - not sure why "sbt console" insists on compiling class files before launching a repl. I mean, I'm launching a repl since something did screw up, right ? I think Scala can be much, much simpler and better - especially in compiler error messages and tooling. But it is absolutely amazing as a Java replacement.
- eeperson 13y ago
  'sbt console' compiles before it launches a repl because it includes your project's classpath. If you want a Scala repl that doesn't have your project's classpath (and hence doesn't need to compile things) start a repl separately from sbt.
  - clhodapp 13y ago
    Alternately, use "console-quick", which brings up a console with your dependencies on the classpath, but not your actual code. As a (lengthy) side-note, that name really bugs me. In sbt, we have console-quick and console-project (brings up a console with your build on the classpath). Argh! These are kinds of consoles. They should be quick-console and project-console! Alas, those are the names that Mark Harrah gave us, so they're the ones we have to live with, I guess.
    - sandGorgon 13y ago
      whoa... THANK YOU for that!
- koeninger 13y ago
  Sounds like you want sbt console-quick http://www.scala-sbt.org/0.12.3/docs/Howto/scala.html#console-quick http://www.scala-sbt.org/0.12.3/docs/Howto/scala.html#consol...
_random_ 13y ago
It will add more confusion with the actual sharp tools: C# and F#.
abalone 13y ago
Absolutely static typing helps you be a better programmer. No programmer is infallible, and static typing helps you catch a large class of your mistakes sooner -- at the moment you write or compile them, rather than at runtime or never. The author's reasoning is quite poor. They don't even concretely define what it means to be a "sharp" programming tool.
deleted 13y ago
[deleted]

91 points by SanderMak 13y ago

> I am a great programmer and I choose static type systems because I demand sharp tools. > Of course by taking this position you run the risk of pushing a fallacious, authority-based angle. However, in the weak or strong case you’re already pushing anecdotes around, so you may at least choose the one that is open for objective measurement. Which part is open to "objective measurement"? I don't know if I'm a good programmer, whatever that is, but I use static type systems when I want a system to work both today and tomorrow after I refactor it.

monstrado 13y ago
These are all very subjective statements, things like "I choose ... because". If you asked 20 programmers why they like statically typed languages, I am willing to bet you will get quite the variety of answers. Personally, I think statically typed languages scratch an itch that is different from programmer to programmer.
- mercurial 13y ago
  Ah, but the difference is that I'm not claiming my statements are open to "objective measurements" :)

nathansobo 13y ago

I also found his talk fascinating, but the paper he referred to was a bit unapproachable for me. Any suggestions for resources that could help get me more comfortable with reading and understanding type calculi?

zeckalpha 13y ago
Here's the Milner paper which describes ML's type system. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.5276&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.... Wikipedia also helps: https://en.wikipedia.org/wiki/Type_rules https://en.wikipedia.org/wiki/Type_rules
gruseom 13y ago
Pierce's book (the standard text) is surprisingly readable, at least compared to what I expected.

jaxytee 13y ago

Scala transcends the static vs dynamic typing debate via it's duck typing. Because of it's implementation of implicits, you get static type checking along with the flexibility of a language like JavaScript or Python. IMO This puts Scala head and shoulders above the rest of the programming world in terms of language design.

anonymoushn 13y ago
Scala lets you spend lots of time typing incomprehensible type signatures and gives you less type safety than ML-family languages in exchange. Truly it is the pinnacle of PL design!
- mcv 13y ago
  Yeah, I hate those incomprehensible type signatures. Just give me an Object and I'll match with the type I need.
  - _random_ 13y ago
    I have a better idea! Let's just use strings for everything!
    - virtualwhys 13y ago
      thanks for the chuckle
  - anonymoushn 13y ago
    I certainly hope you don't give me an Object. That would mean I still haven't escaped the JVM! Just give me HM and I can write type safe code without typing types.
laureny 13y ago
> Scala transcends the static vs dynamic typing debate via it's duck typing. Hardly anyone uses duck typing in Scala (you probably mean structural typing, by the way). There are plenty of articles explaining why structural typing is a bad idea, here is one: http://goo.gl/0wcNFO http://goo.gl/0wcNFO

barrkel 13y ago

I think you missed the point of that line. Type annotations let you get the shape of the data structure out of your head and into code. The compiler can then ensure that you're using the data structure properly. Whereas if you're using a dynamic language without type annotations, you need to keep the shape of the data in mind; after that array index, hash lookup, function call, you need to know what kind of thing it is you've got in hand, and what you can do with it. Sure, you write tests to exercise the code and flush out the mistakes, but that isn't as tight an iteration cycle as a compiler - if living in an IDE, the cycle may be as low as a few milliseconds. And this is the point of the "not a great programmer" comment. Making progress even though you don't have the entire map of the whole program's data structures in your mind all at once. Having said that, I think this ability to deal with a lot of complexity in working memory can be detrimental to good code, even in typed languages. I've worked with some talented programmers that had an enormous capacity for complexity, but that very complexity made them less inclined to abstract their code. In fact, because they had less need for abstraction, their abstraction skills overall were poorer.

mcv 13y ago
> Type annotations let you get the shape of the data structure out of your head and into code. This is by far the best argument for static typing I've ever heard. I'm not a big fan of static typing (mostly due to Java). I like Scala, but I think its type system is way over the top. For the most part, I care about rapid development, and you'll always need unit tests anyway, so they can also test your types for you. And Scala type matching in its builtin switch statements can always get my type back when I get handed an Object. With tools like that, I don't really need absolute type safety. But getting the shape of your data structures out of your head, that's definitely an advantage.

pron 13y ago

There are so many problems with Scala, that the question of static vs. dynamic typing becomes secondary. Static typing could well be downright awesome, but Scala is still a mess. I'm repeating the same line for the third time today, but I find that Scala is for people who find Haskell too simple, and want to add mutability, inheritance and macros on top of it, while dropping safety, purity, and much of the type inference (and I'm certainly not a Haskell fan, but Scala makes Haskell seem like Logo). For the life of me I can't understand what the language designers want, or how they think software should be written. It seems like they're finding it a fun challenge to see how many features from different languages can fit in a single compiler, and they justify each feature as necessary to solve some arcane problem. I think it's the complete opposite of languages like Clojure and Erlang (or Java, even), whose designers started by pondering the major issues of software development, and tried to come up with a coherent solution, rather than pile on features, each plugs a specific hole, without any fundamental organizing principle.

justin_hancock 13y ago
I think you've hit the nail on the head with Scala. It feels every conceivable concept in language research has been thrown in. The lack of coherency is sometimes quite jarring. Coherency/conceptual integrity are things I look for in computing environments they make reasoning things much simpler as logical deductions can be made, I don't find myself doing that with Scala.
- eropple 13y ago
  Your mileage may certainly vary, but having used Scala pretty steadily for the last year, I find the strong majority of Scala code I see in practice generally very easy to intuit. You can do stupid things with it--see Scalaz, which is bad ideas[1] given form--but for the most part, people don't. I used to have the same concern you're expressing, and a few others besides--I've written comments on HN along the lines of "I'm writing Scala that I can't read the next day"--but I got past that stage not too long afterwards, and I find it remarkably predictable and consistent in everyday use. [1] - this isn't a fair characterization, see deeper in the tree

seanmcdirmid 13y ago

The article is weird. Martin Odersky is an incredibly good programmer, just dive into the source code of scalac, he was probably just being modest to make a point.

lnanek2 13y ago
I think it is a better way to phrase it anyway. If you say you are an awesome programmer and since you are awesome your decision to use static typing to get you better compile errors and help your development is right, then people can just argue that you suck. But if you say you suck and static typing allows you to suck less, what are they going to say? It's pretty widely admitted that languages need to help developers suck less to succeed, see Java removing multiple inheritance, operator overloading, etc. and becoming the premier business language. These were power features that made it easy to shoot yourself (and team members) in the foot.
barrkel 13y ago
Think of Odersky's line in the same vein as bwk's "debugging is twice as hard..." line, about not using all your smarts in the code you write.

badman_ting 13y ago

I agree strongly with the statement the author calls out. Stop believing in yourself and your amazing abilities, and embrace your incompetence. Stop talking about what a great marksman you are, look down at your bullet-ridden feet at long last, and embrace tools that make it harder to shoot yourself in the foot. This weekend I found a collection of Javascript tests meant to evaluate one's abilities. I spent an hour trying to get the project to run, so I could take the tests, but it was all built on piles of Jello. A bunch of slightly-incompatible versions of libraries and frameworks and shit, so that 3 months after its release I couldn't use it. Stop the madness. Build shit to last and stop using things that make your next 5 seconds in emacs slightly easier at the expense of everyone else.

DanielRibeiro 13y ago

This is an interesting post. I worry though that Odersky's point can make people think that there are only two kinds of type: static, or dynamic. James Iry did an amazing overview of the nuances of various kinds of type systems on his Types à la Chart. [1] http://james-iry.blogspot.com/2010/05/types-la-chart.html http://james-iry.blogspot.com/2010/05/types-la-chart.html

programminggeek 13y ago

I think that typing is useful, but I say that as someone who wrote a bunch of type checking code on top of Ruby to make my boundaries cleaner and more sane. It made my code a lot nicer to work with, but I quickly realized that what I really would prefer is strong interfaces and typing at the boundaries. Thus, scala, go, java, c++, etc. make a lot of sense to me because you gain performance and stronger boundaries are baked into the language. I want strong typing because it makes my code better. I want it built into the language because it makes my code cleaner.

Aqueous 13y ago

Maybe it would be better to say, "I'm a pretty good programmer. However, I'm not perfect, and I make mistakes. Static typing helps minimize the mistakes." The one thing I don't like about Scala is type inference. We spend all that time specifying the exact type of parameters and return values, but then we can just lazily declare an immutable value val, set it equal to a return value of a function, whose signature is in different file, and from a quick glance at the code we can not tell what 'val' is. it might be convenient in the short run, and splits the difference between convenience of dynamic typing and the precision of static typing, but it does so at the cost of readability.

gohrt 13y ago
The type of that value is the type returned by that function. If you want to see what that type is, look at the function. That's not as weird as it sounds. Consider: int x = foo(2); What is x? OK, you know it is an "int", due to the redsundant declaration. But that's not useful to you the programmer. int foo(int n) { return n+1 } Ok, foo is successor. But you have to look at the definition to remind yourself that. Why not put that in the declaration of x as well?
benmccann 13y ago
There are numerous places I find Scala has preferred brevity over readability and it does not take long for that choice to take it's toll when you have many people working on a project. Yours is a perfect example. Another is allowing multiple ways of importing such as allowing relative imports. When I've tried to use Scala it's much more of a pain to figure out where some classes are coming from whereas in Java it's immediately obvious from the import at the top of the file.
RivieraKid 13y ago
That's exactly one of my many complains about Scala (and about type inference in general). Type annotations are not there just for the compiler, they also help readability / documentation.
lmm 13y ago
If you feel a particular value needs an explicit type you can always include the type in the declaration. Or your development environment should be able to tell you what type it is. I do think scala needs an IDE to be used effectively, at least if you're making heavy use of implicits and inferred types (and, as a sibling mentions, indirect imports). But I think that's ultimately a good thing: it uses the power available to us nowadays to allow a more compact representation of code than would be acceptable in a plain text file (which is good for readability - AIUI evidence is that code readability takes a big hit as soon as a function spans more than one screen). Rather than throwing away the convenience of text like the '80s "visual programming" efforts, it's more of a "progressive enhancement".

auggierose 13y ago

Scala is the best language out there today for general purpose programming, FULLSTOP. Many people complain about the complexity of Scala, or how many features it has, etc. Yes, there are some odd features (I am looking at you, native XML support), but these are features I NEVER use. Just learn the fucking type system (it's not that hard, all you need to understand for most of your coding is [A], [+A] and [A <: B] and you are set) and stick to the features you like / understand. To those who praise the purity of Clojure: That is nice, but comes with a high prize. For example that you have to wait for something like Clojure.Typed, which is already a non-issue with Scala, because Scala comes with BATTERIES INCLUDED. Complaining that Scala has too many features is like complaining that Clojure has too many libraries.

lawn 13y ago
Using capslock will surely make your point come across better, or not. Complaining that Scala has too many features is like complaining that C++ has too many features, which is a valid complaint.
- auggierose 13y ago
  C++ is a dangerous and unsafe language, so you need to be aware of every little detail. That's why many features in C++ are a problem. Scala runs on the JVM. That and the saner design of Scala makes it much safer to code in Scala than in C++, and what you don't know in Scala, usually doesn't hurt you. By the way, I didn't use capslock, I used shift.
icebraining 13y ago
stick to the features you like / understand. Doesn't that only work if you're coding in isolation from bottom up? As soon as you include some library or start collaborating with someone who likes a different subset, you can't simply stick to what you know.
- auggierose 13y ago
  That might be a good point. You should come to an understanding with your collaborators on the subset you code in. That may be more difficult in an open-source setting. BUT: This is even exaggerated in Clojure, where you are forced to learn all the little libraries your collaborators use...

asdasf 13y ago

His assumption is incorrect: >but I suspect it’s an attempt to counter the idea that strong static type systems like Scala’s are complicated. Nope. It is simply stating the reason we use typed languages. Because we are human beings, and make mistakes. Having a compiler automatically tell us when we make those mistakes is very helpful. That's it. It has nothing to do with "sharp tools", which untyped advocates also claim their tools to be. It is simply that type systems can find a large number of bugs, at compile time, with 100% certainty.

aklein 13y ago

"I am a great programmer and I choose static type systems because I demand sharp tools." I strive to build correct software, and I leverage a static type system to enforce the absence of incorrect program behavior. Any other benefits are just niceties.

ajanuary 13y ago
* to enforce the absence of certain classes of incorrect program behaviour

sandGorgon 13y ago

There is a lot of focus on haskell vs scala and deep intricate discussions about type systems, but here's a question - how is scala as a better java ? For my purpose (working with hadoop), it has proved to be more than adequate - I get a repl to work with java classes (serious productivity jump over those who have to work with vanilla java), I dont have to muck about with classnames <> filename mapping. I come from the JRuby world and I have a secret fetish for Clojure - but the near-Java performance of Scala is impossible to argue against. My biggest, biggest problem is sbt - it is fairly sucky, since it inherits Maven's Madness. Pet peeve - not sure why "sbt console" insists on compiling class files before launching a repl. I mean, I'm launching a repl since something did screw up, right ? I think Scala can be much, much simpler and better - especially in compiler error messages and tooling. But it is absolutely amazing as a Java replacement.

eeperson 13y ago
'sbt console' compiles before it launches a repl because it includes your project's classpath. If you want a Scala repl that doesn't have your project's classpath (and hence doesn't need to compile things) start a repl separately from sbt.
- clhodapp 13y ago
  Alternately, use "console-quick", which brings up a console with your dependencies on the classpath, but not your actual code. As a (lengthy) side-note, that name really bugs me. In sbt, we have console-quick and console-project (brings up a console with your build on the classpath). Argh! These are kinds of consoles. They should be quick-console and project-console! Alas, those are the names that Mark Harrah gave us, so they're the ones we have to live with, I guess.
  - sandGorgon 13y ago
    whoa... THANK YOU for that!
koeninger 13y ago
Sounds like you want sbt console-quick http://www.scala-sbt.org/0.12.3/docs/Howto/scala.html#console-quick http://www.scala-sbt.org/0.12.3/docs/Howto/scala.html#consol...

_random_ 13y ago

It will add more confusion with the actual sharp tools: C# and F#.

abalone 13y ago

Absolutely static typing helps you be a better programmer. No programmer is infallible, and static typing helps you catch a large class of your mistakes sooner -- at the moment you write or compile them, rather than at runtime or never. The author's reasoning is quite poor. They don't even concretely define what it means to be a "sharp" programming tool.

deleted 13y ago

[deleted]