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?
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.
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.
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.
For the sentence "Scala is compatible with Java", there is almost no interpretation of "compatible" that would make the sentence untrue.
If you work alone, you're right. Problems start when working in a team. The average lifetime of a codebase is about a decade, in which time it is read and touched by many hands, and falls under several management administrations. We know that languages that are too feature-rich can prove troublesome under these conditions.
> sounds suspiciously subjective
Of course its's subjective -- like many things that have to do with the choice of languages -- but unlike many other debates, we actually have some very good data on this: C++. For a few years, C++ was considered a blessing. Expressive, sophisticated, powerful. But after a few years, as codebases started to mature, the industry as a whole discovered that maintaining C++ codebases is a nightmare. Every team had its own style and its own subset of features it chose to use. Some features (like operator overloading and esp. cast and assignment operators) while useful, ended up making long-lasting, large-project collaboration extremely costly. Java's design was very much a reaction to C++, eliminating features right and left, and declaring from the get-go that it aims to be less expressive and more verbose. It worked. The question now is whether any new "rich" language would share C++'s troubles or not, and that is indeed subjective (so far). But at least we know that sometimes a combination of too many features can be really bad, especially when working in large teams.
BTW, today C++ is quite effective because it's become a (relative) niche language (even according to its creator). Niche languages are used by specialized teams that are good at enforcing discipline, and/or tend to be smaller.
I also think that complex languages may be harder for teams with high turnover or a lower average skill set within that language (and as such the average allowed complexity per expression may play a role in this). I went into some depth on this in a cousin thread[1], but my conclusion may not be quite the same as yours. Part (well, most actually) of my original question on this topic was to ask for clarification, because I thought the assertion was inherently ambiguous.
That said, if you have actual numbers or studies to bolster your statements about C++ I would love to see them. What you assert is a common refrain here, but I'm truly not sure how much of it is confirmation bias and squeaky wheel. There are plenty of C++ supporters as well as detractors, but I'm not sure how to sort through the noise here to get an accurate assessment of the landscape. Interestingly, my relative distance from C++ may actually help here since my own experiences may not sway me as much, but that might be entirely overshadowed by C++'s similarities and differences to other languages that I like or dislike in some aspect that I am more familiar with.
In the end, since it's not as simple as "less features us better, more features is worse" (otherwise we would all be writing assembly), I suspect there are a few other important axes of comparison that actually describe the situation better, and language features is a useful abstraction but only over a very short range of values, outside of which it becomes increasingly useless as a metric for how hard or easy it is to manage a codebase.
> BTW, today C++ is quite effective because it's become a (relative) niche language (even according to its creator). Niche languages are used by specialized teams that are good at enforcing discipline, and/or tend to be smaller.
Is it? I know there have been other systems eating into the market share for C++ for a while, but my impression has always been that it's still extremely popular in certain segments where there hasn't been much new competition for a while. E.g. high performance computation, cutting edge/AAA games, etc.
"Extremely popular in certain segments" is typical of "niche languages" -- those segments are its niche(s).
If the niche is well-defined, the size doesn't really matter in many respects, because its effectively a completely different market, and it doesn't matter whether that markets large or small in terms of what goes on outside that market.
Arguably, assembly is the most feature-full language - everything is possible. But those features are very expensive, which is why it's only used where there is no alternative.
That is, both C and Perl can implement Hash data objects, but C requires a library or implementation, and Perl makes it a core data type of the language.
And C, Java, Perl, etc, also don't have anything like "enter supervisor mode". But if the CPU supports it, assembly will let you do it.
Note that most real-world case studies were done in the late '90s-early '00s so they are not that easy to find. A quick Google search, however, came up with this[1].
> There are plenty of C++ supporters as well as detractors
It's not about C++ supporters and detractors today. It is an undisputed fact is that the industry as a whole abandoned C++ (except for its relevant niches) and practically no one has looked back.
> In the end, since it's not as simple as "less features us better, more features is worse"
I'm not saying it is simple. I am saying that we have one experiment with conclusive results. Perhaps there are other variables, but given the strength of the results, the burden of proof -- IMO -- lies with those who claim that their super-feature-rich language will not meet the same fate.
> it's still extremely popular in certain segments
It is, and those are its niches. They form a largeish share of the market, but not anywhere as large as the segments that used C++ in the 90s or the segments that use, say, Java today. It is most certainly no longer a general-purpose cross-market industry-wide language.
[1]: http://www.lanl.gov/projects/CartaBlanca/webdocs/PhippsPaper...
> the burden of proof -- IMO -- lies with those who claim that their super-feature-rich language will not meet the same fate.
All you are doing is reducing the discussion to something so hand-wavey that it can't be argued anymore. I'm interested in how much is too much and what type of features increase tihs load. I assert that some features don't increase errors, but in fact decrease them (e.g. Java's automatic memory management), and if that's true, than the statement "more features is worse than less features" is trivially proven false. Is it really that hard to move the argument beyond the simplistic point of view that "features" are the problem?
It is handwavy because designing languages is an art, but usually providing too many ways to achieve the same thing or allowing code that hides its operation (or appears to violate the "normal" language semantics while looking innocuous) is, in general, bad (for large teams), as it hinders readability. Of course, things need to be balanced, and you have to consider what kind of projects the language is for, what would be the "average" code size, etc..
And I've been trying to get people to at least define what they are talking about in every single comment I made. Kudos to you for doing so. :)
> Automatic memory management is what's known as an extra-linguistic feature.
While that makes your position easier to support (but it's not what the original comment stated, which is why I asked for clarification from them), I'm not sure I buy it entirely. I need an explanation why a language with more language level abstractions is worse than one with less, given that you can enforce the restriction of some abstractions. Why is artificially limiting yourself the better solution than enforcing restraint, which leaves the possibility to work outside those constraints when the conditions are correct?
[1]: This is less true of C++ today, when it's mostly a specialist language used by specialist teams working in fields that have always required a lot of restraint. They know how to do restraints (well, at least better than the industry at large).
So? the language's themselves change over the time frame you are looking at. You seem to be arguing that having the language enforce it is better than policy, but name one language that's seen any serious use that hasn't seen change to add new features over the last then years, of the exact sort you are saying cause problems. So we're supposed to entrust this to a third party that really doesn't care about our specific needs. The Java standards committee doesn't know who you are. And if they do, you are not a representative case of the vast majority of Java programmers. I would rather control my future, so I choose freedom with restraint.
I'm really not buying your C++ is niche argument. C++ is one of the top 3-5 languages in the world in every metric. Java is more popular, but not being the most popular has nothing to do with being niche. C++ is still in massive use in almost every industry. That is not niche. Using C++ as your go-to example and basing your argument on having lost so much market share as to be a niche language isn't really moving the discussion along. Shops switched to Java from many languages, not just C++, and for many reasons, not just because C++ features caused problems. That argument is far too simplistic and ignores far too many things for me to give it much credence.
If you see how Bjarne Stroustrup[1] describes C++ today, you'll probably agree that it's a niche language (he sees it that way today).
> That argument is far too simplistic and ignores far too many things for me to give it much credence.
Of course. But ignore it at your peril. If you want to use a language that is similar to C++ in many respects (many of the same respects that the industry complained about), you should at least acknowledge the risk and try to be damn sure that this is what you want or be sure that this wasn't a contributing factor to C++'s fall from dominance.
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.
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.
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.