Live data from Hacker News

Data-driven Scala Programming

blog.buildo.io

21–26 of 26 posts

Re: Data-driven Scala Programming

#21
post #5

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

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 c…

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?

Re: Data-driven Scala Programming

#22

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…

A little more regarding that error from the same site:

"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

Re: Data-driven Scala Programming

#23
post #5

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

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 c…

I find Java unusable w/o an IDE. However there certainly are languages that are easier to work with w/o one. Go being one example. Depends on design and available tooling. OT: For automatic imports (and formatting) run `goimports` or configure to run automatically on file save. Congratulations, here's also your error stack traces. (EDIT: I mean syntax errors) An IDE, in that case, isn't at all an obvious improvement. Quite to the contrary I find.

Re: Data-driven Scala Programming

#24
post #3

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…

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…

Because IDEs are bloated and buggy

Re: Data-driven Scala Programming

#25

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…

> do you really need to analyze compilation logs to arrive to the conclusion that you should use an IDE and that types are helpful ?

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

Re: Data-driven Scala Programming

#26

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.

> "Pretty often"?

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.

Post reply on HN