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 error but the quality of error that is an issue.
But sublime, emacs and vim all support autocompletion (through ensime) so it is not really an advantage of intellij or netbeans.
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.
Yes you do. That's the point of the article - we should apply basic scientific method to programming (that's what distinguishes us from magicians).
> There is also no real hint into why getting this error...
This part of the story is better explained here https://blog.buildo.io/http-routes-at-buildo-1424250c41d3
"Spray-routing uses a cool and crazy DSL to write routes in Scala, based on the magnet pattern. Despite it being all nice and flexible, it’s also extremely frustrating to debug."
From, "What's Wrong With Routes?" https://blog.buildo.io/http-routes-at-buildo-1424250c41d3
Please don't do this sort of thing; all it will do is cause people to dig their heels in and fuel the idea that FP is too "dogmatic" or such.
I know you're joking, but I hear this refrain far too often while reading "persuasive" FP articles. This sort of jest just comes off as smug when it's not clear that you're "in the trenches" with JS (or other non-FP coders).
Still, I wont give up my text editor :) Any emacs folk like to comment on its usefulness? Its seems more fully implemented there.
- 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 <C-x><C-o> - works great and is supremely useful.
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.
> 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.
20 times a day in my case and 45 in case of another guy. If we suppose you code actively 6 hours a day it's like being interrupted 7.5 times a hour. That's "often" when compared to other errors.
> "Comparing to what?"
To other kinds of compilation errors (I think this point was clear in the article)
> "That’s good news"
If the compiler doesn't catch errors, most of them will go in production (you're usually not unit-testing all the possible type errors). I'm appealing to common sense here - It would be interesting to see if data confirm this.
This is a blog post, not a scientific paper. This is far from complete - it's just meant to be a good starting point. Factchecking everything is stated here would require an entire research team.
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.
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.
