5 ms·

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.