3 ms·

I can't speak for jlarocco, but my concern is not directly the import statements, but rather, what those import statements imply. That repo has 1,290 files. Ex

by jabr 14y ago

I can't speak for jlarocco, but my concern is not directly the import statements, but rather, what those import statements imply. That repo has 1,290 files. Excluding file pathnames containing 'test', there are 601 files. Of those, 430 are .java files. Java is complicit in that crime, but Enterprise Java is the bigger culprit. The library makes doing a map on an array cleaner for me, but behind the scenes it is using a dozen "factories", a bunch of "builders", several "strategies", and a handful of "visitors", "bridges", and "proxies". And guilt by association is valid here. We bleed over whether semicolons are needed in some languages, but Java is off limits for needing 10-fold more (auto-generated?) boilerplate code for something most languages handle out of the box?

mkramlich 14y ago
Yep. Don't forget Aspects! "But, but... a good IDE can make all this boilerplate be less painful!" Of course, you could just not have the boilerplate, abstraction and over-complexity to begin with, use a simpler language & ecosystem like Python, and just code in vi.
- arcdrag 14y ago
  "I don't want to learn how to use an IDE" is the same argument as "I don't want to learn how to use vi". There are a lot of reasons to hate Java...I don't want to use a bloated IDE is a pretty weak one in an age of 8 core processors and 32 GB of ram. Also, many Java shops do so because few other languages are an option when you need 200+ trained developers, as few cities even have 200 experienced Python devs. Then there's performance, as Java performs an order of magnitude faster than Python for many operations.
  - mkramlich 14y ago
    The vast majority of dev workstations in the real world have far less than 8 cores and 32 GB of memory. Also it's not about "bloat" in some abstrance sense, I've found, but rather about the noticeably slower interactivity, the mysterious delays, the mysterious crashes, and the overwhelming surplus of unnecessary visual/cognitive vomit occupying the screen real estate at any time. Oh and Byzantine IDE configuration option panels. And the always-harder-to-automate nature of GUI interfaces. And the local drive bias. And every other "feature" they add that you're supposed to appreciate as some new gift from the gods turns out to be something you could already do, for free, on the command-line or with a vi/emacs-style terminal-friendly UI. I have a lot of experience working in both paradigms and I know which one I've found to be better. I think the last fast/simple/non-crashy/non-visual-vomit IDE I experienced was TurboC in the early 90's. It's been mostly downhill ever since. I think a lot of shops that think they need 200 developers, and thus it's easier to get Java than Python developers and thus should use Java, etc., may have made a base assumption after which all following deductions are dependent. If instead of starting with assumption you need 200 developers you instead think we only want a few smart/elite developers, then you can have a smaller total headcount, a less enterprisey tech stack, and less mindless process and makework. I've seen and heard of small teams that run circles around large bloated enterprise shops for just these kinds of factors. Also I guarantee you that in the vast majority of real world programming situations needed by large companies the software is mostly not CPU-bound but rather IO-bound, and any greenfield or maintenance development is mostly bug-bound or developer-hour-and-quality-availability-bound and bureaucracy-bound. CPU time is cheap and lots of ways to parallelize, defer and cache. Software developers are not cheap. Well, worse software developers can be "cheaper" superficially but end up being more expensive due to being slower, dumber or less knowledgable of implementation options, and needing much more of them. CEO salaries and their royal court are extremely NOT cheap.
UK-AL 14y ago
Many people find those patterns help them understand the code. I often see terrible bespoke code, where half the problems could fixed using a design pattern where those problems have already been considered. It works both way, there are many acceptable times to use a design pattern, and many non-acceptable times.

by jabr 14y ago

mkramlich 14y ago

Yep. Don't forget Aspects! "But, but... a good IDE can make all this boilerplate be less painful!" Of course, you could just not have the boilerplate, abstraction and over-complexity to begin with, use a simpler language & ecosystem like Python, and just code in vi.

arcdrag 14y ago
"I don't want to learn how to use an IDE" is the same argument as "I don't want to learn how to use vi". There are a lot of reasons to hate Java...I don't want to use a bloated IDE is a pretty weak one in an age of 8 core processors and 32 GB of ram. Also, many Java shops do so because few other languages are an option when you need 200+ trained developers, as few cities even have 200 experienced Python devs. Then there's performance, as Java performs an order of magnitude faster than Python for many operations.
- mkramlich 14y ago
  The vast majority of dev workstations in the real world have far less than 8 cores and 32 GB of memory. Also it's not about "bloat" in some abstrance sense, I've found, but rather about the noticeably slower interactivity, the mysterious delays, the mysterious crashes, and the overwhelming surplus of unnecessary visual/cognitive vomit occupying the screen real estate at any time. Oh and Byzantine IDE configuration option panels. And the always-harder-to-automate nature of GUI interfaces. And the local drive bias. And every other "feature" they add that you're supposed to appreciate as some new gift from the gods turns out to be something you could already do, for free, on the command-line or with a vi/emacs-style terminal-friendly UI. I have a lot of experience working in both paradigms and I know which one I've found to be better. I think the last fast/simple/non-crashy/non-visual-vomit IDE I experienced was TurboC in the early 90's. It's been mostly downhill ever since. I think a lot of shops that think they need 200 developers, and thus it's easier to get Java than Python developers and thus should use Java, etc., may have made a base assumption after which all following deductions are dependent. If instead of starting with assumption you need 200 developers you instead think we only want a few smart/elite developers, then you can have a smaller total headcount, a less enterprisey tech stack, and less mindless process and makework. I've seen and heard of small teams that run circles around large bloated enterprise shops for just these kinds of factors. Also I guarantee you that in the vast majority of real world programming situations needed by large companies the software is mostly not CPU-bound but rather IO-bound, and any greenfield or maintenance development is mostly bug-bound or developer-hour-and-quality-availability-bound and bureaucracy-bound. CPU time is cheap and lots of ways to parallelize, defer and cache. Software developers are not cheap. Well, worse software developers can be "cheaper" superficially but end up being more expensive due to being slower, dumber or less knowledgable of implementation options, and needing much more of them. CEO salaries and their royal court are extremely NOT cheap.

UK-AL 14y ago

Many people find those patterns help them understand the code. I often see terrible bespoke code, where half the problems could fixed using a design pattern where those problems have already been considered. It works both way, there are many acceptable times to use a design pattern, and many non-acceptable times.