
Data-driven Scala Programming - francescogior
https://blog.buildo.io/data-driven-scala-programming-e50f07c4db35
======
rubenfiszel
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 error but the _quality_ of error that is an issue.

~~~
wonton2
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 a lot of time trying to free myself
from the ide.

~~~
rubenfiszel
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.

~~~
gipp
Those are only "benefits" if you don't have automatic imports, though. In an
IDE the neatness of your imports is a non-factor in deciding package
structure, and who cares about the size or structure of your import block? You
never need to look at it and your IDE probably folds up that block anyway.

I was a vim purist for a long time, but even in Python, where IDE
functionality is much more limited, I can't honestly compare the two
experiences and say I'm not much more productive in PyCharm w/vim plugin. I
can't fathom how _anyone_ writes Java/Scala in plain vim, and Ensime is a
cumbersome mess.

~~~
heavenlyblue
Speaking re. python:

IDEA also sorts imports alphabetically, separates system modules from non-
system modules and removes the names that are no longer used if configured
properly. How much time does someone spend doing this by hand (e.g. just
simply reading through the list of them)?

IDEA also allows to automatically make the code PIP8-ready by using
Ctrl+Shift+L.

I can refactor the name of the function with a basic shortcut, and I am 100%
sure, even if it touches >5 projects at the same time - IDEA will replace them
correctly. That could be done by a simple find-and-replace, but then I would
need to keep my attention on whether that was a correct replacement. How many
minutes a day do you spend trying to keep yourself aware of that?

There are literally so many details in working with moderately-complex Python
code (e.g. type hints or lack of them; function arguments; unresolved names)
that IDEA basically equals to a constant number of hours I save every day.

I am not going to argue - most of what I mention could be solved by automated
cli-based tools; and that's exactly what IDEA does under the hood. By it keeps
it all together in one place on my screen right now; here, rather than in a
set of disjoint interfaces.

I literally do not get why people still use vim/sublime/notepad++. That's like
cooking with a blunt knife. You may and will cook as good. But is it not
justifying your laziness to go out and buy a proper knife?

------
namuol
> That makes sense even if you never experienced how horrible writing
> JavaScript code is

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).

------
critium
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.

~~~
tasuki
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
<C-x><C-o> \- works great and is supremely useful.

------
bobbyi_settv
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".

~~~
harpocrates
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...

------
msangi
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.

------
javabean22
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.

~~~
msangi
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.

~~~
pkolaczk
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.

