Hacker News Reader

As a fellow emigrant of `Scala is the best island` forced off for pragmatic reasons.

I've been around scala long enough to see the rise and fall of multiple expeditions into the bowels of the OSGI eclipse cave of horrors (Sean McDirmid / Miles Sabin etc). Before switching horses and settling in Intellij for several years. So I understand where you are coming from.

I've since jumped ship again to vscode (along with typescript), and in my humble experience / opinion, vscode & it's language server protocol (LSP), alleviates quite a bit of this. It abstracts away a lot of common operations from a language to the languages compiler, while providing a consistent front-end. I think if scala eagerly adopts supporting this it would be a good thing. Having a language server protocol applies back-pressure in a certain sense on language features, if you are going to add them, then the tooling (and LSP) needs to support them.

Not sure if you read it in the article, but Scala 3 will have LSP support (if it doesn't already).

It already has support although it is not complete: http://dotty.epfl.ch/docs/usage/ide-support.html

Could you expand on what this all is? I'm not familiar with what benefits an LSP provides. What is the world like before and after LSP support?

It moves code completion and refactoring into a dedicated process behind the LSP API, which is maintained by the language devs. As a consequence the IDE automatically keeps up with language changes.

I understand your strategic motivation, but to convince people your language is best, saying "my language is better than X" can be a very bad tactic. The reason is that most programmers aren't big PL fans, and that, to be honest, language choice (among various more-or-less suitable options) has a negligible -- if any -- effect on a business's bottom line. The biggest effect is on programmer enjoyment, as there are (perhaps unfortunately) many programmers who feel that their programming language does affect their satisfaction from programming. Such a preference for a language is often largely personal, but you can make your language more or less attractive to certain crowds. Creating a combative, competitive atmosphere, often results in a very fervent community, but usually not a large one, as such an atmosphere doesn't have a broad appeal. To increase the appeal of a language, the best things you can do is create great tooling, lots of useful libraries, and a friendly community.

In addition, an argument for "my language is better than X" can usually be easily countered with an argument for the opposite, creating a net result that doesn't help your goals. Debates are sometimes interesting and informative, but they're not effective marketing.

> language choice (among various more-or-less suitable options) has a negligible -- if any -- effect on a business's bottom line.

That's just, like, your opinion, man.

(By which I mean: I disagree, and we both know there's no clear evidence one way or another)

> To increase the appeal of a language, the best things you can do is create great tooling, lots of useful libraries, and a friendly community.

I do what I can, but a bad language can do those just as easily as a good language - tooling and libraries are much more a function of big-corp backing than they are of good language design. It's remarkable how much Scala has managed to achieve in those areas without having a big name behind it, but there's no competing with the amount of programmer-hours the likes of e.g. Google can pour in. The only way Scala can hope to win is on actual language design merit (and maybe winning popularity on that is impossible, but given how well Scala has managed to do so far, I remain hopeful).

> In addition, an argument for "my language is better than X" can usually be easily countered with an argument for the opposite, creating a net result that doesn't help your goals. Debates are sometimes interesting and informative, but they're not effective marketing.

A genuinely better language should have at least a slightly better chance of winning a debate over which language is better. If we don't believe that then we have no hope of ever learning truths, and may as well pick languages to use at random (or I guess go with whatever Google picked).

> I disagree, and we both know there's no clear evidence one way or another

I think that the lack of evidence in favor of a strong effect is normally counted in favor of the null hypothesis. It may not feel fair, but the burden of proof is solely on those who claim a strong effect exists, not on those who don't.

> but a bad language can do those just as easily as a good language

Again, the burden of proof is solely on those who claim there is such a thing as a good language with a strong effect. If you can't display an effect, or claim that others can also induce it by other means is a win for the null hypothesis. If you claim there is such a thing as a "bad" language, and there is no evidence this is true, doing so will harm your cause.

> A genuinely better language should have at least a slightly better chance of winning a debate over which language is better.

I just don't think that a debate is the right way to establish an empirical claim. It's ok to engage in a debate - even a heated one - but the lack of evidence should at least encourage humility. My point is just that an imagined "win" at a debate only harms your mission. If it convinces anyone, which is highly doubtful, it's probably not the people you want, anyway. An approach that says, "I think this is cool. I like it and it helps me and may help you, too" is so much more effective at marketing than "my way is best" especially if the evidence is not on your side.

> if the language is to live, I have to convince other people it's the best

Aren't JVM languages interoperable - because they use the same classfile/byte code format?

What does it matter if the jar is written in java or scala, as long as it is possible to use the external interface from any of these languages?

No single person can maintain an entire ecosystem around a language. And programming languages have strong network effects. If I think a language is dying then I won’t want to use it because I’ll worry about future support. It becomes a self fulfilling prophecy and a negative feedback loop.

Yes and no.

JVM languages can usually use other JVM libraries, but they often aren't idiomatic to that language. Scala can use JVM libraries, but it often feels wrong or cumbersome, e.g. Java is full of mutable builder classes, which I've never once encountered in "native" Scala.

The other way around, in Scala you have to be careful if you want your library to be usable from other JVM languages. There's certain Scala features you just cannot use.

This is a problem that Kotlin actively markets itself with, they promise 100% Java compatibility all the time, going as far as encouriging to mix Kotlin and Java code in a single project.

What Scala features can't you use?

implicits mainly, these are objects looked up by the compiler for various purposes e.g. Typeclasses, or how to serialize a specific object to JSON.

The Scala 2.8-2.12 collection library was impossible to call from Java, one of the reasons for an upcoming redesign in 2.13.

Real example from my experience: you use a Scala Map and pass it to something like FreeMarker, expecting that it will work like Java Map there. It will not and depending on your test coverage and SQA capabilities, you may notice it very quickly or very late (you'll get no compile error, since template engines usually accept generic objects and then analyze their type via reflection).

Why would you expect this to work? In fact given that API a map from another java library(say guava) would have crashed you just as well

Well, I wouldn't even try to have a source code written in two different languages in the same component. But I've seen this problem in someone else's real code, which was probably caused by a not really well-thought migration of Java code to Scala. Basically, a developer replaced one Map with another, fixed all the places where API was different on source code level and a number of tests. However, interoperability issues like this one may be hard to catch in general (even with good test coverage and regular code reviews) and they show the complexity of the problem, that requires certain level of development skills and discipline to do it right.

You are right, this particular example is more of case against reflection rather than anything else. Having said that, Scala maps actually are tricky to use from java. In general scala does a better job in compatibility when it comes to reuse of java code from scala, but not the other way around

You still can get into trouble with Kotlin, hence why they have an interoperability guide in Android.

https://android.github.io/kotlin-guides/interop.html

> Aren't JVM languages interoperable - because they use the same classfile/byte code format?

Up to a point - libraries from another paradigm tend not to be idiomatic, but I could live with that. I'm more worried about tooling availability - I talked about IDE support in particular, and it's also things like profilers and monitoring/instrumentation.

The bytecode is the same but not the standard library of classes. Scala uses different collection classes, Option instead of Optional, companion objects instead of static classes, etc...

In my experience mixing scala and java in a single codebase is inelegant, with plenty of conversion code at the boundaries.

I'm not sure I see anything in that post that's tied to scala in particular, or even really visual programming. Are you referring to the hints? The parameter names hints seem to be result of having functions in general, and type hinting look like a direct result of static typing; I like the idea, but it doesn't appear to me to be tied to Scala the language at all.

It looks like its just tied to the jetbrains ide

The macro expansion is more tightly tied to Scala itself, as are things like showing implicit parameters. To a certain extent the things you mention are generic things, but Scala pushes type inference further than other languages that that IDE supports and makes more use of static types in general, so the IDE might well not have bothered with the type hints without Scala. Likewise Scala makes fuller use of named parameters than many languages (in Java parameters have names but you can't pass them with name=value syntax).