For someone who keeps bringing up this accusation, you seem to be reliably glossing over my core concern. Most critically: if a decision has already been made, then humoring folks with a discussion that goes nowhere isn’t considering feedback, it’s putting on a show. This isn’t something that even needs to be done maliciously or intentionally, confirmation bias is something that has to be actively avoided, and we’ve seen plenty of things that certainly look like that’s what’s going on.
“This is not ready for prime-time” is valid feedback, and concrete concerns were raised, repeatedly. SIP are not universally adopted, so discarding was absolutely a plausible outcome (until further clarification was provided). Putting it under an experiment flag was raised because we can see there is potential here, however it’s objectively an immature feature, so we felt a soft launch was a reasonable suggestion.
This isn’t what he wrote, and completely changes it from “we should be way beyond considering more changes” to “we’re still considering more changes, provided they’re sufficiently well reasoned”, which is pretty much the exact opposite meaning.
Simply because the discussion and suggestions are completely irrelevant if no change was ever on the table. My kids can suggest and discuss all they’d like and I may even acknowledge any particularly well reasoned points, but if the decision that there will be no desert tonight was already made, there will be no desert.
You’re missing some important context:
That means that, if this goes out, it’s going to be taught as The Way to at least all the new Scala devs who pass through the Coursera course or Scala Center language tutorials, which means ongoing impact in one of two directions: either it will propagate into every codebase, or those who find it hard to work with will have to actively work to help new devs unlearn this habit during onboarding. It’s already hard enough to help them unlearn bad Java habits - and it’s not like it’s exactly easy to find Scala developers to begin with - so any increase in recruiting or onboarding difficulty is going to cause an increase in the cost to adopt or just stay with Scala that we can ill afford. It’s also going to cause a bunch of arguments about code style, and that’s another area where Scala already has a really bad reputation - this thread is going to happen over and over and over again, in pretty much every company that uses Scala, and that is not a good look for the language.
This is not something that’s going to be off in a corner somewhere, it’s probably the single most immediately noticeable user-facing change. It’s concerning that one of the strongest arguments for keeping this feature in (the cost of reworking the course materials and books) implies that, despite feedback which can be charitably characterized as “mixed”, short-term documentation costs (steep though they may be) are considered more important than long term increases in total cost of ownership.
If this get’s a soft launch, what exactly is the downside?
- Work will need to be redone that either never should have been done, or should have been done with the understanding that it was relying on an experimental feature that could be changed or deprecated at any time (just like everyone who wrote macro tutorials in the beginning)
- Early adopters will have to add a compiler or language flag, something that they’ve demonstrated consistent willingness to do.
If this does go in, we’re rolling the dice for next to zero demonstrable gain. There’s been no indication that this will bring in anyone new, or make it easier to sell adopting Scala, or really do anything other than “look cool”, and there have been several credible warning signs that this is going to make it harder to convince an engineering team to adopt Scala.