Hacker News Reader

Comment by yohanatan | Hacker News Reader

Couldn't you just use Scala as a better Java in that case? Or do you just generally like wasting lots of vertical space on braces & monstrously verbose and sparsely distributed code chock full of boilerplate?

Also, this isn't about 'technology': both languages run on the JVM and are capable of utilizing it equally. Rather, this is about information density of source code; i.e., the signal:noise ratio. And, if you hire experienced programmers then no learning will be necessary and they can do what they want to do 'with technology' much more quickly with more powerful tools in their hands.

View on HN

You must not have used a modern IDE. IDEs such as IntelliJ can fold a lot of boilerplate [1]. Besides that, modern Java IDEs offer so much functionality for refactoring, code generation, etc., that it's often hard to be more productive in other languages (I have used C++, Python and Haskell for years, but I am more productive in Java after using it for work the last 1.5 years).

Scala simply doesn't have the same level of support in IDEs as Java does.

[1] http://confluence.jetbrains.com/display/IntelliJIDEA/Folding

No, I've used plenty of modern IDEs. In fact I use IntelliJ for writing Scala and most of the features you list are implemented for it too. But, as others pointed out, even if your IDE can generate ungodly amounts of code for you, you will eventually have to read and maintain that monstrosity (i.e., it's not truly 'hidden').

Too true. Lombok <URL: http://projectlombok.org/ > is a much nicer approach.

That does look nice!

When you are looking for bugs, you still have to read all the code. Whether it was auto-generated or folded by the IDE doesn't give any benefit here.

You don't, really. Bugfixing by whole-program code inspection is incredibly inefficient and quickly because impractical with large codebases.

I've found its far better to hunt down bugs using a combination of debuggers, stacktraces, divide-and-conquer, log statements, assertions, and unit tests. I've gotten bugfix rates as high as 5 bugs/day in a fairly complex library (an HTML5 parser in C) using these techniques.

I think you're missing the fact that you can use all of those same techniques in languages without all the noise. You can also use a plain old editor with such languages (which can be handy if debugging/writing code on a headless server).

And, some languages make writing most of that sort of bug nigh impossible to begin with.

Let's just say that I'm happily using a language where I don't really have to search for bugs in the first place ...

You're basing your business case on Java having some vertical space wasted on braces instead of availability of programmers and ease of inter-op with existing libraries? No words.

Scala can consume any Java library with ease. The programmers I am interested in hiring can program in any language but choose to use the most powerful ones because they are vastly more productive in such than the hordes of 'freely available' mediocrity out there.

Scala's reduction of code size is way overrated, IMO. We're not talking Clojure level succinctness, and you'll be very lucky to get a 30-50% reduction (as compared to, say, Clojure's 5x-10x). In addition, that reduction is -- as you state yourself -- mostly of boilerplate code, which is "cheap" and doesn't tend to have lots of bugs. OTOH, it comes at a cost of very high language complexity, interop, and maintainability. So you pay hard currency for reduction of boilerplate (a mere annoyance).

I would certainly consider Kotlin, though. Kotlin reduces the boilerplate but doesn't add much complexity, and doesn't hurt interop in the least. So you pay cheap for the (modest) benefits. This seems like a much better deal for me.

My experience directly contradicts your claim. I have consistently seen code size reduced by 40-70% by switching from Java to Scala (and that's without doing anything fancy).

If you get only 30-50% code size reduction, then you don't write real Scala, but some kind of Java with Scala-like syntax. Stay with Kotlin then, Scala is no good for you.

Let me clarify: we just recently implemented Spark-Cassandra connector in Scala, basing on the previous similar work done for Hadoop-Cassandra in Java and the reduction in size was about 3x and up to 5x in concurrent code; however it is still hard to measure properly, because the new driver offers more functionality than the original. Of course YMMV, but writing in Scala is not just getting rid of meaningless boilerplate.

Wow, and pron is spreading FUD again.

Getting a bit desperate that absolutely no one cares about Kotlin?

It is because I belong to that tiny group of developers who do care about programming languages that I even mention it. But I care a lot more about software in general, and if you look at the industry at large, absolutely no one (for all intents and purposes) cares about any language other than Java, C, C++, JavaScript and C# (plus some Matlab and maybe R, I guess). So I do have some strong opinions, but I put them in perspective. Until IBM, Oracle, Microsoft, SAP and a couple of large defense contractors -- all the true big players in software -- put their weight behind one or two "new" languages, all arguments over PL merits are kind of moot. Frankly, I don't blame the big guys for not switching languages just yet. None of the challenger languages have shown such incredible advantages -- in correctness, performance or time to market -- to justify such a costly switch (certainly no world-changing benefits as C and Java offered). In fact, some technical leads in prominent SV companies have told me that their main reason for picking a non-mainstream language wasn't technical: it was to appease their novelty seeking developers. I think there are two languages that might make a real difference -- Clojure and Haskell -- and they are, unfortunately, still far from conclusively proving their case. If Rust makes it to the embedded space, it could prove a real contender, too. In general, most new languages overpromise and underdeliver.

A) appeasing novelty seeking developers is not a negative. If a company using a particular language can attract developers that are more productive in a novel language than those other developers they might find in a "mainline" language. That is certainly a win.

B) You left out at least 3 major languages that are hugely represented in large enterprises. Visual Basic (especially in the Access/Excel variety), SQL (in it's standard and non-standard formats) and COBOL. Those languages also offered huge advantages that any language trying to gain widespread appeal might want to study. That said, I certainly am not taking any job that is majority VB, SQL, or COBOL coding and none of the best developers I know (selection bias could be an issue) will either.

If a company using a particular language can attract developers that are more productive in a novel language than those other developers they might find in a "mainline" language. That is certainly a win.

I don't think it is. Those CTOs/lead developers told me that the "novel language" teams are just as productive as other teams, and, in fact, tend to be less disciplined (and I'm talking top tier, millions-of-customers, technologically advanced, SV companies here). The only reason they allow those new languages is to attract young developers who get their kicks out of a new PL. If anything, this shows that some developers are immature, or that tech companies aren't doing stuff that's challenging and interesting enough on its own that developers need occupy themselves with the novelty of the language rather than with the novelty of the problem.

IBM, Oracle, Microsoft and SAP is not the end of all IT. Don't underestimate the long-tail. Anyways, there are already quite a few big names using Scala. So this is not "absolutely no one". And you forgot about Google and Python in your list.

Thought about it. I've heard a lot about Scala's learning curve, but I don't think it'd be a huge problem in my case since I already know Haskell. I am a little worried about finding Scala programmers, but there's a decent-sized community around the language. And it can use Java libraries fine, and you can write native Scala code for Apache Spark.

The deciding factor against it, for me, is that Java/anything interop on the JVM is quite easy, but Scala/anything interop is hard. That makes it relatively easy to create a mixed-language Java/Jython system or Java/Clojure system, or even Java/Jython/Clojure, but very hard to do a Scala/Jython system. And even with its advanced features, I doubt that Scala beats Python for quick & dirty prototyping. I've got a bunch of past experience in multi-language scripting + compiled core systems, and I know the benefits of doing a system at scale like that. The value proposition of Scala (and to some extent Go and Haskell) is that you get one language that is both fast and concise, but in my experience you want to separate that out into scripting and core languages, because the styles of programming themselves are very different.

Yea, I second what froaway said. 'Scripting' in Scala is quite easy and works like you would hope it would. Integration w/ the shell is quite nice and it's as concise as Python, Ruby et al and yet also typesafe. Win-win.

Also, I wouldn't worry too much about finding Scala programmers-- in my opinion, what you want to find rather is good programmers. And, good programmers can pick up Scala (or any other language) in short order.

I think Scala especially excels at prototyping.

I use it from quick and dirty scripts and ad-hoc data-processing (the stuff you would usually use Perl/bash/...) over exploratory programming, database work (SQL) and architecture sketches (GUI tools) to full-blown (web) applications (JavaEE, Python, Ruby, ...) and browser scripting (usually JavaScript).

I miss none of the "standard" technologies.

Reply on news.ycombinator.com