4 ms·

I used Scala for some small projects. I absolutely loved much of it, although I found I got caught up in experimenting with syntax to learn "better" ways to th

by aneth 16y ago

I used Scala for some small projects. I absolutely loved much of it, although I found I got caught up in experimenting with syntax to learn "better" ways to the point of distraction. These days I use mostly ruby and have started on node.js. Ruby programmers don't seem to understand the importance of encapsulation and typing, which is quite frustrating and leads to much head banging. I yearn for the day Scala or something similar is broadly adopted. Interestingly, many of the best features of scala mentioned here are veey new to the language. Named parameters and built in copy for case classes were not available until a year ago. It's great to see a language implementing prudent improvements quickly - here's looking at you Java.

samstokes 16y ago
Ruby programmers don't seem to understand the importance of encapsulation and typing Interesting juxtaposition. I wonder if it's a concrete benefit of static typing to make you more aware of encapsulation: that does resonate with my experience. Because functions and object methods have to have types that fit together, you're forced to think about what goes into and comes out of a given component, so you're thinking about component boundaries more often. I know when writing a Ruby method it's all too easy to just return the first intermediate result that makes sense, subconsciously thinking "let the caller process this result, and if it's messy I'll refactor it later". In Java, I have to write the return type and also return something, and if I planned to return an Iterable<String> but I'm tempted to return a List<Object>, the redundancy catches me out. I have to consciously make the decision: should I change the contract of this method by changing the return type, or should I instead massage the results into the form I planned to return? (I think the same holds for Scala, where I might not have to write the return type because it's inferred: if anything actually calls my method, the compiler will still remind me that the assumptions made at the call site don't line up with the assumptions made in the method. In Ruby, although I'll still have to change the caller if I change the return type, I'm more likely to do it mechanically, in a "I changed that so I have to change this" mindset, rather than stepping back a level and thinking "which one of these is actually right?".)
- aneth 16y ago
  You are largely correct about Ruby I think, although it's broader than that. Functional programming is popular because mutable data is a major cause of bugs, is hard to debug, and creates unnecessary complication. In Ruby, all data INCLUDING the executable code itself, is mutable and regularly mutated. Integration and extension, including throughout the Rails codebase, is accomplished by changing object prototypes. This means that you can never rely on an object behaving in a certain way or following a certain code path, and your code or any third party code can easily be broken by a single line of rouge code from a library - and yes this happens often. Regarding Scala, I don't think type inference means that you stop thinking about types, particularly when writing in a functional style where the returned value is the only thing that matters.
  - samstokes 16y ago
    Regarding Scala, I don't think type inference means that you stop thinking about types I didn't mean to imply that it did - quite the opposite in fact (that even if you didn't write the type, you'd still be encouraged to think about it, because of the compile-time checking).

by aneth 16y ago

samstokes 16y ago

Ruby programmers don't seem to understand the importance of encapsulation and typing Interesting juxtaposition. I wonder if it's a concrete benefit of static typing to make you more aware of encapsulation: that does resonate with my experience. Because functions and object methods have to have types that fit together, you're forced to think about what goes into and comes out of a given component, so you're thinking about component boundaries more often. I know when writing a Ruby method it's all too easy to just return the first intermediate result that makes sense, subconsciously thinking "let the caller process this result, and if it's messy I'll refactor it later". In Java, I have to write the return type and also return something, and if I planned to return an Iterable<String> but I'm tempted to return a List<Object>, the redundancy catches me out. I have to consciously make the decision: should I change the contract of this method by changing the return type, or should I instead massage the results into the form I planned to return? (I think the same holds for Scala, where I might not have to write the return type because it's inferred: if anything actually calls my method, the compiler will still remind me that the assumptions made at the call site don't line up with the assumptions made in the method. In Ruby, although I'll still have to change the caller if I change the return type, I'm more likely to do it mechanically, in a "I changed that so I have to change this" mindset, rather than stepping back a level and thinking "which one of these is actually right?".)

aneth 16y ago
You are largely correct about Ruby I think, although it's broader than that. Functional programming is popular because mutable data is a major cause of bugs, is hard to debug, and creates unnecessary complication. In Ruby, all data INCLUDING the executable code itself, is mutable and regularly mutated. Integration and extension, including throughout the Rails codebase, is accomplished by changing object prototypes. This means that you can never rely on an object behaving in a certain way or following a certain code path, and your code or any third party code can easily be broken by a single line of rouge code from a library - and yes this happens often. Regarding Scala, I don't think type inference means that you stop thinking about types, particularly when writing in a functional style where the returned value is the only thing that matters.
- samstokes 16y ago
  Regarding Scala, I don't think type inference means that you stop thinking about types I didn't mean to imply that it did - quite the opposite in fact (that even if you didn't write the type, you'd still be encouraged to think about it, because of the compile-time checking).