Data-driven Scala Programming
blog.buildo.io
Data-driven Scala Programming
1–10 of 26 posts
Re: Data-driven Scala Programming
#2I 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.
Re: Data-driven Scala Programming
#3I 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…
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.
Re: Data-driven Scala Programming
#4I 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…
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.
Re: Data-driven Scala Programming
#5Earlier 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.
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.
Re: Data-driven Scala Programming
#6Earlier 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.
One practical effect I've seen with this in Scala is that IDE users seem to be more averse to typeclasses and other implicit heavy stuff. These things can't be autoimported so you have to do it manually. People who don't use IDEs are used to importing things by hand anyways
Re: Data-driven Scala Programming
#7Earlier quoted context omitted.
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.
One practical effect I've seen with this in Scala is that IDE users seem to be more averse to typeclasses and other implicit heavy stuff. These things can't be autoimported so you have to do it manually. People who don't use IDEs are used to importing things by hand anyways
reasonable given one should be averse to them even with all the IDE aids (at least in the sense to be judicious when using them). the scala plugin simply cannot handle many parts of the language anyway
Re: Data-driven Scala Programming
#8Earlier quoted context omitted.
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.
One practical effect I've seen with this in Scala is that IDE users seem to be more averse to typeclasses and other implicit heavy stuff. These things can't be autoimported so you have to do it manually. People who don't use IDEs are used to importing things by hand anyways
If typeclasses are well-designed, they can be auto-imported. Sadly, it's not a common design in practice.
Re: Data-driven Scala Programming
#9> 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).
Re: Data-driven Scala Programming
#10Seeing 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".