Live data from Hacker News

Data-driven Scala Programming

blog.buildo.io

11–20 of 26 posts

Re: Data-driven Scala Programming

#11
Im curious as to how he's using vim + ensime. I've been trying off and on for the last 2 years to figure out a good workflow using ensime but i typically end up just turning it off after a few days. EnType only works for me when its completely obvious. EnImport seems kind of useless. After these 2, i just give up, tbh.

Still, I wont give up my text editor :) Any emacs folk like to comment on its usefulness? Its seems more fully implemented there.

Re: Data-driven Scala Programming

#12

Seeing type errors logged is only "good" if they are catching actual bugs. A large amount of Scala type errors aren't bugs I would have had in Python; they're hoops I wouldn't have needed to jump through like worrying about whether a parameter should be a "Long" or an "Int".

Actually, those are the type errors I _like_ having (and don't always have: Scala will implicitly convert `Int` to `Long`), although I concede this is a matter of opinion. However, I am definitely less impressed by the unhelpful type errors one gets when implicits somehow fail...

Re: Data-driven Scala Programming

#13
post #11

Im curious as to how he's using vim + ensime. I've been trying off and on for the last 2 years to figure out a good workflow using ensime but i typically end up just turning it off after a few days. EnType only works for me when its completely obvious. EnImport seems kind of useless. After these 2, i just give up, tbh. Still, I wont give up my text editor :) Any emacs folk like to comment on its usefulness? Its seems…

I've been using vim + ensime for a while.

- EnType is slow and only works when obvious

- EnImport ... never worked for me, but I'd _love_ it! Perhaps there's something I'm missing. How do you add imports?

- The automatic typechecker sometimes works sometimes doesn't. Shows unused imports which is somewhat neat.

However, ensime's killer feature for me is fully contextual completion with - works great and is supremely useful.

Re: Data-driven Scala Programming

#14
Stopped reading right here:

> The second error, “Type mismatch”, appeared 1771 times in the logs. That’s good news. It means the type system is working well: it catches type errors pretty often. Cool! I can finally honestly claim that I use Scala for a good practical reason.

That’s good news? Why? How? "Pretty often"? Comparing to what? Maybe it is, maybe it isn't. I don't know. 1771. Ok then.

Re: Data-driven Scala Programming

#15
post #3

Earlier quoted context omitted.

I have always wondered why anyone would not use an IDE. I have tried to start using editors like vim and sublime. But I just think it makes me type endlessly and wait for compile to see my typos and so on, when in intellij or netbeans you type a few letters and get code completion and automatic imports. This blogpost, however, is the first concrete evidence that I havent really missed anything, and I should not spend…

There is some benefits to not have automatic imports is that it incentivize to keep everything tidy under package object such that you only need a few meaningful imports. It is easy to notice automatic import because the header is an import hell. But sublime, emacs and vim all support autocompletion (through ensime) so it is not really an advantage of intellij or netbeans.

You can configure IDEA to import only the things you absolutely need to import. So I don't know what you mean.

Re: Data-driven Scala Programming

#16

Stopped reading right here: > The second error, “Type mismatch”, appeared 1771 times in the logs. That’s good news. It means the type system is working well: it catches type errors pretty often. Cool! I can finally honestly claim that I use Scala for a good practical reason. That’s good news? Why? How? "Pretty often"? Comparing to what? Maybe it is, maybe it isn't. I don't know. 1771. Ok then.

Why not?

I think it's fair to assume that programmers starts the compilation either when they believe their code is correct or when they do want to get an "hint" from the compiler.

Either way, they get a valuable feedback from the compiler and that happens multiple times per day.

Re: Data-driven Scala Programming

#17
This is a neat idea.

I wonder if this can be extended to analyse unit test failures.

I'd guess one can get some interesting information from what tests fail more often. I'm thinking of being able to spot bad tests because they're too brittle or spotting bad code because it's too fragile.

Re: Data-driven Scala Programming

#18

I don't mean to sound rough but do you really need to analyze compilation logs to arrive to the conclusion that you should use an IDE and that types are helpful ? There is also no real hint into why getting this error: "Too many arguments for method parameters" is inherently bad. I assume that it is not informative enough and that you'd prefer getting a type error instead ? In that case it is not the quantity of erro…

You are right, the conclusions might seem obvious, but nevertheless it is a great step forward that finally somebody in IT has taken the effort to make a statement about developer productivity that is based on empirical data.

Too many discussions on this subject are just based on intuitions and gut feelings, really amazing if you consider how much of an exact science IT is otherwise. I hope there will be more of this kind of fact based research in the future. I can think of a few more subjects, e.g. productivity gains by switching from an imperative to a functional language.

Re: Data-driven Scala Programming

#19
post #16

Stopped reading right here: > The second error, “Type mismatch”, appeared 1771 times in the logs. That’s good news. It means the type system is working well: it catches type errors pretty often. Cool! I can finally honestly claim that I use Scala for a good practical reason. That’s good news? Why? How? "Pretty often"? Comparing to what? Maybe it is, maybe it isn't. I don't know. 1771. Ok then.

Why not? I think it's fair to assume that programmers starts the compilation either when they believe their code is correct or when they do want to get an "hint" from the compiler. Either way, they get a valuable feedback from the compiler and that happens multiple times per day.

Static type systems sometimes refuse to compile otherwise valid code. Type error is compiler telling "I can't prove this code correct with regard to some class of problems I'm supposed to catch". It does not necessarily prove the code is incorrect and would fail at runtime.

Therefore a high number of type errors may also mean the type system is very strict and getting in the way very often.

BTW I prefer the type system to be a bit too strict rather than not catching obvious bugs and then having to struggle with a debugger.

Re: Data-driven Scala Programming

#20
post #3

Earlier quoted context omitted.

I have always wondered why anyone would not use an IDE. I have tried to start using editors like vim and sublime. But I just think it makes me type endlessly and wait for compile to see my typos and so on, when in intellij or netbeans you type a few letters and get code completion and automatic imports. This blogpost, however, is the first concrete evidence that I havent really missed anything, and I should not spend…

There is some benefits to not have automatic imports is that it incentivize to keep everything tidy under package object such that you only need a few meaningful imports. It is easy to notice automatic import because the header is an import hell. But sublime, emacs and vim all support autocompletion (through ensime) so it is not really an advantage of intellij or netbeans.

Well, I dunno; writing Elm means I get a compiler warning about unused imports, which a lot of compilers can do. Automatic handling of imports coupled with easy pruning of unused ones seems like a complete win to me, what's the downside?
Post reply on HN