8 ms·

> but still very limited compared to Scala. The fact that Kotlin has fewer features than Scala is what makes it appealing to me. Scala has become a kitchen si

> but still very limited compared to Scala. The fact that Kotlin has fewer features than Scala is what makes it appealing to me. Scala has become a kitchen sink with too many features, it's kind of the C++ of the 21st century in that respect.

kbenson 11y ago
I'm not really sure how to interpret that. To you, what's the negative aspect of a feature? If features are things to avoid, what's the benefit of Kotlin over something with less features, like Java 6?
- zck 11y ago
  A car plus an airplane has downsides in both car and airplane mode that cars and airplanes do not have.
  - kbenson 11y ago
    Cars and airplanes are things, not features. The ability to drive on roads and the ability fly don't necessarily entail the downsides of a car or of an airplane. I'm honestly wondering what the reasoning is behind the dislike of too many features, and how people justify the "right" amount of features. I can think of at least one argument against too many features, and that's managing what features a team should use in production, but there are solutions to that and I think that's a weak argument for the original assertion, which was entirely unsubstantiated. I haven't used C++ or Java in over a decade, and I've never used Scala, so I don't have a horse in this race, but vague assertions deserve substantiation.
    - curun1r 11y ago
      For me, language design is a balance between being expressive and being readable. Coders love the ability to concisely express nuance and therefore gravitate towards expressive languages, but there's a hidden cost that most underestimate. And that cost is paid by all the readers of the code that do not share the same style and context of the author. Note that this includes the original author when they're revisiting code they haven't touched in months. Most modern languages can be seen to be somewhere on that continuum between expressive and readable. Languages like Go fall completely on the side of readable. I found that in my first few hours of Go, I could easily read through all the code that I found online and found it incredibly easy to reason about. But, as you'll hear time and again in critiques of the language, there's a lot of boilerplate that makes things explicit and many programmers dislike the lack of expressiveness. Which brings me to Scala. Scala is on the entirely opposite end of the spectrum. When I first dove into Scala, I was constantly having to look up language constructs to understand the code that I was reading. And, worse yet, there was often no keyword or other indicator to tell me which feature was being used. In short, it was a nightmare to learn to read. But I'm sure the author loved it. S/he could express what s/he wanted from the computer in a few short lines that were entirely comprehensible to h[er|im]. My own personal view is that it's a right tool for the job situation. I think Go is a great language for large teams with high turnover. The fact that you could onboard a new Go developer and s/he would be able to read everything in your codebase and start contributing on day 1 is a huge plus. But if you've got a small, cohesive team that can agree on the subset of Scala features and overall patterns to use when developing, Scala could be a good choice since it would allow the team to move very quickly. There's a cost to both and it's important to consider when choosing a language. The main difference is that people too often evaluate the cost of a language based on their experience writing it rather than reading it.
      - kbenson 11y ago
        I understand and agree with your point, but have always cast it in a slightly different light. I think some languages having longer or steeper learning curves than others, but when used effectively this can allow the language to be more expressive and efficient in developer time for both writing and reading. It's analogous to the communication in a field between an expert and novice, or between two experts. The experts can rely on their shared experience to succinctly explain a concept, which the novice requires detailed explanations for. This makes communication between experts highly efficient, but requires a lot of investment to get to that level of expertise. I find programming languages follow the same rules, but often you are communicating with yourself (sometimes time shifted by minutes, hours or days). If you are an expert in a language that allows complex concepts to be defined concisely, you can use those idiomatic constructs to express your intent and another expert may easily grasp that intent, but a novice may find that much harder to comprehend. Conversely, a language that does not allow complex concepts to be expressed concisely will be easier for a novice to understand, but there is an inherent loss in efficiency for experts in that language that must resort to continuously defining complex concepts with the simpler concepts the language supports (boilerplate, in this case). Neither type of language is inherently better than the other (as much as people like to assume so), they are just trade-offs that have different benefits and drawbacks based on the people or teams that use them. A team with low turnover and high experience could benefit greatly from the long-term use of a language that supports higher level concepts succinctly, while a a team with lower expertise or high turnover might find that extends the learning period of new hires. It's fairly easy to point out languages that have chosen one path over the other, such as Java and Haskell. I think an interesting case is Perl, which supports both, and I think that's a large source of the idea that Perl code is unreadable. It's made to be easy enough to understand in many cases at first glance, while also supporting a lot of higher level concepts. This can cause people that use it to experience very different levels of complexity in close proximity, which can be jarring for the novice, and sometimes the competent user as well.
      - meatysnapper 11y ago
        Go is definitely a good language for high turnover chop shops. A Cobol/Java for the 21st century, if you will.
- nine_k 11y ago
  Feature is not a good thing per se. A presence of feature is a cost the makers and the users pay to be able to do something efficiently. Good design has the smallest number of features making the greatest amount of things efficiently possible. Scheme and Forth are brilliant designs by this metric, Haskell, Python, and Go good ones, while C++ and Scala, well, not so much, frankly. BTW, Odersky himself admits it.
  - kbenson 11y ago
    If the cost is less than the benefit, aren't we overall in a better place? Can't some people value the gain in efficiency, or whatever else the feature provides more than the cost? This sounds suspiciously subjective, regardless of how many people assert that many features is a bad thing, or that it's a metric of "good design" and then list a few languages categorized fairly arbitrarily, IMO. It's perfectly fine to have an opinion, but it shouldn't be stated as fact without any substantiation (as in the GP) or with evidence consisting entirely of subjective elements unless those elements are further explored and explained in less subjective term (using "good language design" as evidence does not count as less subjective). > BTW, Odersky himself admits it. Was I supposed to know who that was referencing prior to googling? I'm not sticking up for Scala, I'm interested in exploring the concept of too many features as a negative in language design.
    - tormeh 11y ago
      The reason Scala has so many features is that it chooses to be 100% compatible with Java, which means it needs to be a superset of Java. Benefit greater than cost? Many would say that.
      - deleted 11y ago
        [deleted]
      - incepted 11y ago
        > The reason Scala has so many features is that it chooses to be 100% compatible with Java, Not sure what you mean, the ABI compatibility doesn't require any feature to work. Does Scala support higher kinded types to be compatible with Java? This does not make sense to me.
- cousin_it 11y ago
  Language design is an exercise in balance between features and guarantees. More features = fewer guarantees and vice versa.
  - kbenson 11y ago
    It's not readily apparent to me how a feature necessitates that a guarantee can no longer be kept. In fact, one feature of a language might be an additional guarantee about some aspect of it's function (e.g. Rust and it's memory ownership feature).
bad_user 11y ago
I'm a Scala developer and personally I believe that such claims are unwarranted, mostly coming from beginners with a superficial understanding of the language. Not only is Scala not a kitchen sink, but it actually cuts down on Java features that were a bad idea. This misunderstanding mostly happens because some people start learning Scala in the hope of finding a better Java. But Scala is not a Java++, but something else entirely, being the kind of language that makes sense outside the boundaries of the JVM. As a piece of advice, if you aren't interested in trolling, you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. That way, in case you have a point, then other people or even Scala's or Kotlin's language designers can learn from your feedback. And if you don't have a point, then you might get some useful piece of advice. On Kotlin - I don't like that it doesn't diverge enough. This is because when picking a non-mainstream language, you lose the advantages of mainstream languages, like easily available documentation, copy/paste-able samples, big developers pool, etc, etc... so the advantages of the non-mainstream language would better be worth it to balance the disadvantages ;-)
- deleted 11y ago
  [deleted]
- incepted 11y ago
  > you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. Sure, I could name things that I don't like but they will be by definition non falsifiable as well, so I don't really see the point of what you're asking. Overall, I just find the surface area of Scala way, way too big. I felt the same way about C++ compared to C in the 90s, hence my comparison. I've used Scala for five years and over that period of time, I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools. I'm still stuck with Scala at work but I'm really hoping Kotlin takes off because using it on my personal projects has been a breath of fresh air compared to Scala. It's like getting 90% of the power of Scala with 5% of the cognitive load.
  - whateveracct 11y ago

kbenson 11y ago

I'm not really sure how to interpret that. To you, what's the negative aspect of a feature? If features are things to avoid, what's the benefit of Kotlin over something with less features, like Java 6?

zck 11y ago
A car plus an airplane has downsides in both car and airplane mode that cars and airplanes do not have.
- kbenson 11y ago
  Cars and airplanes are things, not features. The ability to drive on roads and the ability fly don't necessarily entail the downsides of a car or of an airplane. I'm honestly wondering what the reasoning is behind the dislike of too many features, and how people justify the "right" amount of features. I can think of at least one argument against too many features, and that's managing what features a team should use in production, but there are solutions to that and I think that's a weak argument for the original assertion, which was entirely unsubstantiated. I haven't used C++ or Java in over a decade, and I've never used Scala, so I don't have a horse in this race, but vague assertions deserve substantiation.
  - curun1r 11y ago
    For me, language design is a balance between being expressive and being readable. Coders love the ability to concisely express nuance and therefore gravitate towards expressive languages, but there's a hidden cost that most underestimate. And that cost is paid by all the readers of the code that do not share the same style and context of the author. Note that this includes the original author when they're revisiting code they haven't touched in months. Most modern languages can be seen to be somewhere on that continuum between expressive and readable. Languages like Go fall completely on the side of readable. I found that in my first few hours of Go, I could easily read through all the code that I found online and found it incredibly easy to reason about. But, as you'll hear time and again in critiques of the language, there's a lot of boilerplate that makes things explicit and many programmers dislike the lack of expressiveness. Which brings me to Scala. Scala is on the entirely opposite end of the spectrum. When I first dove into Scala, I was constantly having to look up language constructs to understand the code that I was reading. And, worse yet, there was often no keyword or other indicator to tell me which feature was being used. In short, it was a nightmare to learn to read. But I'm sure the author loved it. S/he could express what s/he wanted from the computer in a few short lines that were entirely comprehensible to h[er|im]. My own personal view is that it's a right tool for the job situation. I think Go is a great language for large teams with high turnover. The fact that you could onboard a new Go developer and s/he would be able to read everything in your codebase and start contributing on day 1 is a huge plus. But if you've got a small, cohesive team that can agree on the subset of Scala features and overall patterns to use when developing, Scala could be a good choice since it would allow the team to move very quickly. There's a cost to both and it's important to consider when choosing a language. The main difference is that people too often evaluate the cost of a language based on their experience writing it rather than reading it.
    - kbenson 11y ago
      I understand and agree with your point, but have always cast it in a slightly different light. I think some languages having longer or steeper learning curves than others, but when used effectively this can allow the language to be more expressive and efficient in developer time for both writing and reading. It's analogous to the communication in a field between an expert and novice, or between two experts. The experts can rely on their shared experience to succinctly explain a concept, which the novice requires detailed explanations for. This makes communication between experts highly efficient, but requires a lot of investment to get to that level of expertise. I find programming languages follow the same rules, but often you are communicating with yourself (sometimes time shifted by minutes, hours or days). If you are an expert in a language that allows complex concepts to be defined concisely, you can use those idiomatic constructs to express your intent and another expert may easily grasp that intent, but a novice may find that much harder to comprehend. Conversely, a language that does not allow complex concepts to be expressed concisely will be easier for a novice to understand, but there is an inherent loss in efficiency for experts in that language that must resort to continuously defining complex concepts with the simpler concepts the language supports (boilerplate, in this case). Neither type of language is inherently better than the other (as much as people like to assume so), they are just trade-offs that have different benefits and drawbacks based on the people or teams that use them. A team with low turnover and high experience could benefit greatly from the long-term use of a language that supports higher level concepts succinctly, while a a team with lower expertise or high turnover might find that extends the learning period of new hires. It's fairly easy to point out languages that have chosen one path over the other, such as Java and Haskell. I think an interesting case is Perl, which supports both, and I think that's a large source of the idea that Perl code is unreadable. It's made to be easy enough to understand in many cases at first glance, while also supporting a lot of higher level concepts. This can cause people that use it to experience very different levels of complexity in close proximity, which can be jarring for the novice, and sometimes the competent user as well.
    - meatysnapper 11y ago
      Go is definitely a good language for high turnover chop shops. A Cobol/Java for the 21st century, if you will.
nine_k 11y ago
Feature is not a good thing per se. A presence of feature is a cost the makers and the users pay to be able to do something efficiently. Good design has the smallest number of features making the greatest amount of things efficiently possible. Scheme and Forth are brilliant designs by this metric, Haskell, Python, and Go good ones, while C++ and Scala, well, not so much, frankly. BTW, Odersky himself admits it.
- kbenson 11y ago
  If the cost is less than the benefit, aren't we overall in a better place? Can't some people value the gain in efficiency, or whatever else the feature provides more than the cost? This sounds suspiciously subjective, regardless of how many people assert that many features is a bad thing, or that it's a metric of "good design" and then list a few languages categorized fairly arbitrarily, IMO. It's perfectly fine to have an opinion, but it shouldn't be stated as fact without any substantiation (as in the GP) or with evidence consisting entirely of subjective elements unless those elements are further explored and explained in less subjective term (using "good language design" as evidence does not count as less subjective). > BTW, Odersky himself admits it. Was I supposed to know who that was referencing prior to googling? I'm not sticking up for Scala, I'm interested in exploring the concept of too many features as a negative in language design.
  - tormeh 11y ago
    The reason Scala has so many features is that it chooses to be 100% compatible with Java, which means it needs to be a superset of Java. Benefit greater than cost? Many would say that.
    - deleted 11y ago
      [deleted]
    - incepted 11y ago
      > The reason Scala has so many features is that it chooses to be 100% compatible with Java, Not sure what you mean, the ABI compatibility doesn't require any feature to work. Does Scala support higher kinded types to be compatible with Java? This does not make sense to me.
cousin_it 11y ago
Language design is an exercise in balance between features and guarantees. More features = fewer guarantees and vice versa.
- kbenson 11y ago
  It's not readily apparent to me how a feature necessitates that a guarantee can no longer be kept. In fact, one feature of a language might be an additional guarantee about some aspect of it's function (e.g. Rust and it's memory ownership feature).

bad_user 11y ago

I'm a Scala developer and personally I believe that such claims are unwarranted, mostly coming from beginners with a superficial understanding of the language. Not only is Scala not a kitchen sink, but it actually cuts down on Java features that were a bad idea. This misunderstanding mostly happens because some people start learning Scala in the hope of finding a better Java. But Scala is not a Java++, but something else entirely, being the kind of language that makes sense outside the boundaries of the JVM. As a piece of advice, if you aren't interested in trolling, you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. That way, in case you have a point, then other people or even Scala's or Kotlin's language designers can learn from your feedback. And if you don't have a point, then you might get some useful piece of advice. On Kotlin - I don't like that it doesn't diverge enough. This is because when picking a non-mainstream language, you lose the advantages of mainstream languages, like easily available documentation, copy/paste-able samples, big developers pool, etc, etc... so the advantages of the non-mainstream language would better be worth it to balance the disadvantages ;-)

deleted 11y ago
[deleted]
incepted 11y ago
> you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. Sure, I could name things that I don't like but they will be by definition non falsifiable as well, so I don't really see the point of what you're asking. Overall, I just find the surface area of Scala way, way too big. I felt the same way about C++ compared to C in the 90s, hence my comparison. I've used Scala for five years and over that period of time, I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools. I'm still stuck with Scala at work but I'm really hoping Kotlin takes off because using it on my personal projects has been a breath of fresh air compared to Scala. It's like getting 90% of the power of Scala with 5% of the cognitive load.
- whateveracct 11y ago