On braces and indentation-based syntax

[shelby3]

@morgen-peschke

Bifurcating the developer pool has never ended well, even for languages with a much larger mindshare than Scala currently enjoys.

Last I checked the Scala developer pool was so minuscule (on the verge of extinction) it needs any boost it can get. I believe the braceless syntax might provide that boost. It will also further differentiate it from Kotlin which has been eroding Scala’s market share. We need Scala to survive. It has come very close to dying from my perspective. Thus Scala needs a larger ecosystem, so arguing to hang on to the current measily ecosystem instead of trying to expand the ecosystem doesn’t make sense to me. Besides those who absolutely need Scala’s unique features are not so fragile as to abandon it because of the new optional syntax. What they going to migrate to, Haskell? Haskell also has a non-braced syntax.

I am not well versed in Python’s history but wouldn’t the lack of static typing play a significant factor there, because there’s facets of the styling you can’t really get unambiguously right without it. How can one cite Python of an example of what not to do when it has 30% market share compared to Scala’s 0.63% and Kotlin’s 1.44%?

Scala is not going to be the better Java. Kotlin has that locked up. Scala needs another niche.

Do you want Scala to die just because of your intransigence about braces? Will you be happy then? I want Scala to thrive.

@morgen-peschke

That’s … cute. C level execs don’t really care about the technical details of a company they’re looking to acquire, they care about retention, risk, and the cost of hiring. A company built on a Java stack won’t hesitate to acquire a company that’s running a Python stack (or vice versa) because either language is relatively easy to hire for and they expect the mindshare loss to be a Ship of Theseus situation.

They are going to be a bit less interested in picking up company that is built on a tech stack that relies on less familiar languages, and Scala currently still qualifies - but being a JVM language is helpful here because the CTO’s can reassure them that everything will still play nicely together.

They’re going to get really skittish if Scala develops a reputation as “the language with developers that tend to leave en-masse when acquired” - my intuition is that you’ll lose people a lot faster when a single commit can entirely rewrite the code in the disfavored style, rather than the slow process of porting existing software to an entirely new language, however this is untested intuition at the moment.

@shelby3

As for a Sr. Engineer he will choose the company that employs the coding style he prefers. I do not see any problem.

The problem is they’re already annoyingly difficult to hire for, so reducing the pool of interested candidates further is a Really Bad Idea.

Everything here screams for creating a version of Scala that has a larger developer pool. What is your proposal? Scala 2 status quo?

The popularity of Python seems to be a good target. If you can mostly make Scala code resemble the advantages of Python but then add type classes and static typing, you’ve carved out a niche that nobody else has, especially not on the JVM.

Your argument distills down to let’s keep our horrible situation intact and take no steps to attempt to rectify it. You want to preserve what appears to be nearly entirely non-existent. Scala already is a no-go for corporations. We know that. And the only way to change that is to broaden the developer pool.

@morgen-peschke

@shelby3

They must not need Scala features much. Maybe this is a good filter for users who really need Scala and thus will be its most ardent supporters. I absolutely need type classes and anonymous unions, so Java is not an option for me regardless.

It’s all nice-to-have stuff. There isn’t an algorithm in existence that can be implemented in Scala but not Java. It can be a lot easier, faster, and more pleasant to program in Scala, but let’s not delude ourselves here - if companies can’t reliably hire Scala devs that work well with the existing teams, they’re not going to use Scala. Splitting the developer pool is going to exacerbate this issue.

I bet there won’t be any splitting because the supply of junior devs will expand and overwhelm the small pool of laggard diehards who refuse to adopt the sanctioned braceless default. Those junior devs will eventually become senior devs. We need to recruit junior devs at a faster rate. The braceless style and building libraries to be more friendly to Python developers might be a strategy for achieving that goal. Stuck in the mud with the status quo is not a plan.

Afaik, it’s not possible to adequately simulate type classes well in a language without higher kinds and implicits. There is the Lightweight technique for mapping the Functor onto a phantom type, but this is really a can of worms that doesn’t really work well generally. You can implement any algorithm without typeclasses or with some kludge but you really lose the entire raison d’etre of typeclasses. Maybe big corporations don’t care about how much productivity they waste as long as they can hire enough coders. Scala may never have any USP for corporations. But a stuck-in-the-mud minuscule developer pool is not helping.