Mark "Justin" Waks
2 min readFeb 19, 2019

--

I think you’re missing the core of my point, which is that every feature is, more or less by definition, bad. Every feature is something that has to be learned; every feature interacts with other features in ways that are often unexpected; every feature needs to be documented; every feature needs to be maintained.

That’s the heart of the principle “every feature must fight for its life”. Each feature must add enough positives, that aren’t sufficiently expressed in other ways, to outweigh the original sin of its own complexity. That’s a basic tenet of good product design, and programming languages are products.

You’re focused on “dropping” as fundamentally bad. In a point release, I might well agree with you, but in a major language version transition — which will have incompatibilities (of which this is one of the smaller ones) — I don’t. This is the time when it is appropriate to step back and ask what the language should look like, overall, and really move in that direction.

(Side note: I’d take the dropping-as-bad point more seriously if it wasn’t for Scalafix, but the presence of automated tools to evolve from Scala 2 to Scala 3 changes the equation a lot. One relevant question that I don’t know the answer to yet is whether dropping early-initialization will be an automateable change.)

You’re being a bit too blithe about the costs here, IMO. Documentation is a cost to the community. Adding a feature to the new compiler (which, remember, is being rewritten more or less from scratch) and maintaining it going forward is a cost to the community. (Often a multiplicative cost, due to feature interactions.) Having to teach this feature in the future (NB: I do Scala training, among other things) is a cost to the community. All of those costs are ongoing, pretty much forever — they’re not one-and-done payments. That ongoing cost is the relevant factor here.

So this is the time when every feature ought to be examined and evaluated. Most of them are providing enough value to be kept, although many are being refactored, and a number are being removed. All of those have their defenders, folks who find them convenient — but that has to be weighed against the overall cost to the Scala community.

And mind — I’m not coming down one way or t’other about early initialization per se. I just think, in principle, it’s entirely appropriate to re-examine everything at this juncture, and trim out the bits that aren’t pulling their weight.

--

--

Mark "Justin" Waks
Mark "Justin" Waks

Written by Mark "Justin" Waks

Lifelong programmer and software architect, specializing in online social tools and (nowadays) Scala. Architect of Querki (“leading the small data revolution”).

No responses yet