35 ms·

Java seems to rely a lot on IDE tools to autocomplete, autorefactor, generally shovel around all this boilerplate. It always seemed weird to me. Like if my ho

Java seems to rely a lot on IDE tools to autocomplete, autorefactor, generally shovel around all this boilerplate. It always seemed weird to me. Like if my house was really cluttered but instead of building shelves or closets into the house itself, I buy an elaborate conveyor belt and excavator system to rearrange all my things all the time so I can walk through all the mess.

itronitron 7y ago
I am sure many people feel the same way about Python and Javascript. What you described seems to be a result of building larger systems in which multiple people are contributing code.
- nurettin 7y ago
  I confirm this. I rename classes and move them around, and without a refactoring tool that renames files and changes imports automatically, life would be very hard. Before refactoring tools got to this level, I was running pytest to see what import statements got affected during my refactors.
  - dep_b 7y ago
    Would the language described in the article (Unitliy) be harder to refactor? Why? Python is not static typed, it won’t refactor as easily.
  - salawat 7y ago
    Uh. Question. Why are you executing tests to get the compiler to tell you what was effected instead of doing a top level recursive grep to identify any classes or configs with an explicit symbolic dependency? I mean, you get the same result, sure, but I find I can hardly ever rely on test coverage alone as an accurate safety net to clearly indicate whether I've reached an actual stopping point for a full refactor. This is one of the ways in which Java excels, in that that loop is fully accommodated for in most major IDE's. You can still get caught by surprise at runtime, but I've found that for a strongly typed language like Java, the syntax, and necessity of boilerplate makes most bugs obvious until you start getting overly dependent on frameworks you don't understand.
    - nurettin 7y ago
      I am not executing tests to perform import error detection. That was before refactoring tools got better. I was executing tests to check for import errors because it doesn't rely on full coverage on every method. It relies on all modules being imported by tested modules. That is easy to do even if you are too lazy to test every module. Just put an empty test function in all of them and pytest will detect them recursively. Given all that, I would avoid executing manual grep commands. However, you have a valid point for configuration files. Especially log configs need to be checked.
- root_axis 7y ago
  The criticism doesn't really apply to Python and JavaScript though. Not to say that Python and JavaScript don't have their own issues, but dependence on an IDE tightly coupled to the language semantics is not one of them.
  - ng12 7y ago
    I can't speak for Python but the JavaScript community has been investing heavily in TypeScript, and the desire for a more integrated IDE experience is a huge driver for that growth.
    - root_axis 7y ago
      Definitely true, though I think the problem is less severe with regard to TS because open source language-servers afford TypeScript IDE features universal availability which is not the case in JVM land. Also, consider the trend towards Kotlin in the Java world where a part of Jetbrain's business model relies on the fact that they created and maintain the language while also selling the IDE that makes the language practical to use (Kotlin being an amazing language notwithstanding).
    - jefflombardjr 7y ago
      Typescript: Putting the Java™ in Javascript
- SmellyGeekBoy 7y ago
  Last time I worked with Python or JavaScript I was using a very basic text editor. I'm not sure I'd be quite so brave with Java.
  - kjeetgill 7y ago
    I don't know about JS, but my python work is done in a repl like ipython in conjunction with a text editor. It gets me half of what I wanted from an IDE.
KorematsuFred 7y ago
Java is not a cluttered house, it a mega warehouse with over billion products lying around. No amount of organizing will make it simple for you top find what you want. Hence the conveyer belt instead of better organization.
skizm 7y ago
A code base is not like a house. There is no "done" state. You have to rearrange and extend code bases every few months due to changing business needs.
Spooky23 7y ago
That's a design feature. Java is the modern COBOL. The idea is that you hire an army of marginally qualified developers through an agency that are making $14-18/hr in the US and have them churn out code. To use your house example, it's like addressing clutter by having 5 children and making them clean.
- pjmlp 7y ago
  Cobol is the modern COBOL. https://en.wikipedia.org/wiki/COBOL#COBOL_2014 https://en.wikipedia.org/wiki/COBOL#COBOL_2014
btilly 7y ago
My comment for years has been that most programming languages are for humans first, and computers second. But Java is for tools first, humans second and computers third. The result is an excellent toolchain. But also you are completely unproductive unless you master said toolchain.
zozbot234 7y ago
This kind of automation depends on a language being easy to parse, and Java achieves this better than C/C++ or most scripting languages. The LSP (language server protocol) is a language-independent standard that can be used to enable this more generally, by connecting parsers/compilers/etc. with editors/IDE's.
raverbashing 7y ago
It's a nice analogy. And I agree with it. For me it seems weird that the Java IDE is "smarter" than the compiler. Then why can't the compiler abstract stuff... Like the 'auto' keyword that took how long to exist again?
- coding123 7y ago
  The compiler is not interacting with the user. The ide isn't smart enough to apply some refactoring without the users consent.
- phillipcarter 7y ago
  This is just one example of a general tension between compiling to produce an asset vs compiling as a service to provide data for tooling. The environments and things you optimize for are different, so you get differences like this. Compilers like what C# and F# use unify these into the same codebase (no presentation compiler) but the tradeoffs still exist.
dehrmann 7y ago
I agree that Java is almost unwritable without an IDE, but that strictness has led to Java having better IDEs than most languages. For large code bases, most languages get unmaintainable without an IDE, putting Java at an advantage. I'd still use Python for something simple that won't grow past a few thousand lines, though.
- mister_hn 7y ago
  Well, having tried both Eclipse and IntelliJ Ultimate, I can say that * Eclipse has a crappy UI and can't handle Java9+ code very well, but can handle large code bases * IntelliJ Ultimate has nice UI and assistance, but it totally fails with large code bases and still tricks you if you run code inside the IDE, especially when you want to use jigsaw modules and not classpath, as it uses by default Unfortunately, using Java with other editors (vim, VS Codium, etc) is just difficult
- wayoutthere 7y ago
  I think part of what's happening right now is that the IDE for most languages other than Java seem to be consolidating on VS Code as the lowest common denominator. This makes sense given how many projects these days are a hodgepodge of 3 or 4 different languages, but the fact that working with the JVM more or less requires a dedicated IDE makes Java a lot less attractive to most teams. (Yes, I know you can do Java in VS Code but I wouldn't want to manage a large Java codebase with it.)
  - JackFr 7y ago
    > I wouldn't want to manage a large Java codebase with it. Why not?
    - deleted 7y ago
      [deleted]
    - itronitron 7y ago
      probably because the code insight offered in VS Code is lagging behind what was available years ago in popular Java IDEs such as Eclipse and IntelliJ
eitland 7y ago
I dare anyone of you who thinks like this to study as much modern idiomatic Java as I've studied Python or Javascript. I'll give you this though: Old Spring and JSF code could be really bad, I remember updating two different XML files every time I changed something in a controller. Edit: even back then with all that boilerplate it was really nice compared to legacy Delphi where it took three full days with an expert to find and install all required dependencies before one could even start compiling the old source. By comparison my Java dev environment was up and running in less than half a day with Ant, and when we introduced Maven a few months later setip time for a new developer was mostly the time it took to check out code, install dev databases (yep, back in the days) and set necessary environment settings. (Protip: many people hate NetBeans but one thing it got more right than all other Java IDEs AFAIK was accepting the pom file as the truth instead of creating its own.
mdtusz 7y ago
I am a big fan of rust, but I am starting to feel like this is a thing with it too. Not to the same extent at all, but I often find myself writing what feels like scaffolding boilerplate code. That said, the code is usually there for a good reason and I'm extremely thankful for it in the instances where things are refactored and the compiler catches it, or some deviation from the norm comes up and the scaffold allows for doing things the way you need.
- marcus_holmes 7y ago
  ditto for Go. Huge fan, but it does involve a lot of boilerplate. Not that I think that's a bad thing. I prefer it to "magic" (I never got on with Rails because of this... what just happened? why did it do that? where does it say it should do that?). And you never know when you have a class/use case that needs the boilerplate to change. Having it the same 99% of the time so that you have the option to change it for that 1% edge case is a good thing, imho.
  - pm90 7y ago
    Go seems to have much less boilerplate than Java. I’m really glad that OOP was explicitly unsupported and the language designers opted for using interfaces instead.
    - kjeetgill 7y ago
      Interfaces are as much a part of OOP as inheritance. Go is as OOP heavy as Java. They differ mostly in how/when an "class" is bound to an interface. Java declares up front, Go does this implicitly at usage sites aka static duck-typing (which is great!). That said, I think OOP education focused a lot on inheritance during Java's rise and that was mostly a mistake in hindsight.
    - ickyforce 7y ago
      > Go seems to have much less boilerplate than Java Maybe if you compare to Java from 10y ago. Have you ever tried to print a map in an alphabetical order of its keys? The only thing more verbose in Java are getters/setters which hopefully will disappear once records are available.
axaxs 7y ago
This is exactly why I've always had a strong aversion to Java. I like 'easy to remember' languages, with a strong preference towards Go and Python, and -somewhat- C though I don't use it often. In any of these languages, I can use an IDE with nice integrations, or if I want to write a quick one off, I can drop into vim and pound out a 50 liner and run it. This is an absolute nightmare to attempt in Java.
jayd16 7y ago
Java doesn't have a preprocessor macros so everything is generated explicitly. Its not that unique of a concept.
- iampims 7y ago
  It has build-time annotations though, which often serve the same purpose.
pashky 7y ago
On the other hand consider this: suppose you’ve built retail business out of your house, then it grew well. And now all those conveyor belts come in very handy, right? Sometimes project is big enough to have a lot of code, boilerplate or not. And then all that IDE automation suddenly becomes essential. I’ve been to some huge Scala codebases, it was much harder to navigate or make changes there than shove around Java cruft with IDE.
tyingq 7y ago
I can't imagine writing Java in a plain vim session. You would need a photographic memory.
- peterashford 7y ago
  Coding Java was what made me stop using Emacs for everything and switch to IDEs. It's a much better experience
  - tyingq 7y ago
    I imagine you have an old keyboard somewhere where the "." key is worn smooth with no "." visible. Maybe the tab key on your current keyboard is now in similar condition.
whalesalad 7y ago
This is a trend I see reemerging with the hyper focus on VSCode. At some point people won’t be able to work on their projects without it. That might not be a good thing... as we have seen with Java. I like being able to consider a shell to be the lowest common denominator for a codebase. If basic shell commands, environment variables, a vanilla vim/nano editor etc... can’t be used to hack on your system then I think it’s far too coupled to tooling.
- rmangi 7y ago
  why are people afraid of modern text editors? Why cling to 1980s technology?
  - epicide 7y ago
    I don't think it's necessarily (just) for a love of 80s editors. I think it's more of a litmus test that your developer experience is too tightly coupled with specific tooling. i.e. if you can't (realistically) choose your own tools, then your experience with the ecosystem is that of your experience with the tool. No tool can be a good experience for everybody.
    - pjmlp 7y ago
      Well some people would advertise UNIX as an IDE and then just try to turn into POSIX anything that they use, hardly any different.
      - epicide 7y ago
        I think you may be projecting others' arguments onto the parent. I did not read it as "everything should support the UNIX IDE" as much as expressing a preference for it and that it's a red flag if you can't even use standard vanilla tools (e.g. grep) to do basic things in an ecosystem. I think it's fair to say that you should be able to edit code in your editor of choice and not have a terrible time.
        7y ago
dcolkitt 7y ago
In some ways the Java philosophy seems like the antithesis of the Unix philosophy. Instead of a lot of small, fast, composable tools that do one thing and do it well, Java culture mostly promotes giant self-contained systems that capture everything in a sprawling OO type system. This distinction is reflected in even small design details. For example Java programs are comparatively slow to boot up. If you're mostly used to the Unix way of repeatedly piping the STDIN/STDOUT of small utilities in an interactive command line, this is painfully inconvenient. But if your workflow involves a monolithic server that manages every component of the business logic in a single process, then 5 second boot times aren't really a big deal. Because maybe you bounce the server once a week at most.
- zten 7y ago
  Yes! Things like Spring Boot are actually a reaction to the days of Java EE and the web of Java-centric technologies. This always confused me as a newer developer. Vendors competed with each other with different JavaEE implementations (WebSphere, Glassfish etc) that all conformed to the same interface and provided everything including the kitchen sink, but what really differentiated the products were vendor-specific features that require you to go outside the interface, but if you tried to use that stuff, another senior developer would tell you that we can't marry our implementation to a specific vendor... meanwhile, literally every company you go to uniformly uses Spring and Hibernate, and both will inevitably require you to not pretend that they're dumb implementations of javax.inject and javax.persistence.
  - imtringued 7y ago
    And Micronaut is a reaction to Spring Boot bloat... And GraalVM native image is a solution to Micronaut bloat... When does it finally end?
- pjmlp 7y ago
  THE UNIX FOSS philosophy, hardly seen in commercial settings.
- dionian 7y ago
  back in the day when i started java, which was its early days(90's), we didnt even have a package manager type solution for java libraries (i.e. maven) - UNIX had a massive head start on java in some respects
alasdair_ 7y ago
I agree, it’s verbose. That being said, The boilerplate often helps when reading unfamiliar code. More importantly, the IDE support is fantastic, especially on large codebases. An example: if I want to refactor a simple thing like Rename a method called “doFoo()” I can do this trivially. Now, this seems simple but it’s not - I only want to refactor uses of this particular method, NOT any other methods that happen to be called “doFoo()” on unrelated classes or interfaces. Moreover, I want the refactor to intelligently work on everything, including inherited classes, abstract classes and interfaces, while correctly ignoring the stuff i mentioned previously. None of this matters much if you have a small codebase and a fee developers, but on a huge codebase with many developers, all that boilerplate lets people quickly understand new code and easily refactor that code while being sure they did not break anything.
- jonfw 7y ago
  I absolutely agree, and that is why Java is a great choice for monolithic applications. It's verbose and it's extremely flexible. The real reason to move away from Java is to move towards different software architectures (microservices!)
  - alasdair_ 7y ago
    >The real reason to move away from Java is to move towards different software architectures (microservices!) This is a SpringBoot microservice: @RestController public class BasicController { @RequestMapping(value="/{id}", method = RequestMethod.GET) public String get(@PathVariable("id")Integer id) { return doStuff(id); } } I'm not sure it's any more verbose than the equivalent Ruby on Rails microservice (for example).
- runT1ME 7y ago
  >The boilerplate often helps when reading unfamiliar code I don't believe this to be true at all, especially for large code bases. Often the people who support this position have not worked on 100k, 500k, 1m LOC applications I've found. Boilerplate makes it much more difficult to read and scan large swatehs of code. I think when people say boilerplate 'helps', they often noticing a correlation between the fact that many strongly typed systems happen to have excess boilerplate. I believe it's the typing that helps, not the boilerplate.
pjmlp 7y ago
As proven by Xerox PARC, EHTZ, Apple, Borland and Microsoft tooling as well. The best programming languages for developer productivity are those that are designed with tooling in mind, instead of grammar + semantics and then we see later how everything evolves.
MichaelMoser123 7y ago
my question is how do you make sense of a seemingly endless stacktrace? (really curious, it's some time since i did something in java) Another problem i had with java: most projects are impossible to understand by looking at the source code, as they tend to do things like Spring or EJB: with delayed loading where class names are specified in some configuration files - and it is often hard to figure out how the system is initialized. That leads to another question: Is it possible to learn about an unfamiliar java project from source code in this day and age? i mean they used to say that perl is a write only language; but enterprise java isn't very readable either.
- aembleton 7y ago
  > Is it possible to learn about an unfamiliar java project from source code in this day and age? Yes it is, but it helps a lot if you're familiar with the framework and the original developer used sensible conventions. I guess that's the same with any language though.

itronitron 7y ago

I am sure many people feel the same way about Python and Javascript. What you described seems to be a result of building larger systems in which multiple people are contributing code.

nurettin 7y ago
I confirm this. I rename classes and move them around, and without a refactoring tool that renames files and changes imports automatically, life would be very hard. Before refactoring tools got to this level, I was running pytest to see what import statements got affected during my refactors.
- dep_b 7y ago
  Would the language described in the article (Unitliy) be harder to refactor? Why? Python is not static typed, it won’t refactor as easily.
- salawat 7y ago
  Uh. Question. Why are you executing tests to get the compiler to tell you what was effected instead of doing a top level recursive grep to identify any classes or configs with an explicit symbolic dependency? I mean, you get the same result, sure, but I find I can hardly ever rely on test coverage alone as an accurate safety net to clearly indicate whether I've reached an actual stopping point for a full refactor. This is one of the ways in which Java excels, in that that loop is fully accommodated for in most major IDE's. You can still get caught by surprise at runtime, but I've found that for a strongly typed language like Java, the syntax, and necessity of boilerplate makes most bugs obvious until you start getting overly dependent on frameworks you don't understand.
  - nurettin 7y ago
    I am not executing tests to perform import error detection. That was before refactoring tools got better. I was executing tests to check for import errors because it doesn't rely on full coverage on every method. It relies on all modules being imported by tested modules. That is easy to do even if you are too lazy to test every module. Just put an empty test function in all of them and pytest will detect them recursively. Given all that, I would avoid executing manual grep commands. However, you have a valid point for configuration files. Especially log configs need to be checked.
root_axis 7y ago
The criticism doesn't really apply to Python and JavaScript though. Not to say that Python and JavaScript don't have their own issues, but dependence on an IDE tightly coupled to the language semantics is not one of them.
- ng12 7y ago
  I can't speak for Python but the JavaScript community has been investing heavily in TypeScript, and the desire for a more integrated IDE experience is a huge driver for that growth.
  - root_axis 7y ago
    Definitely true, though I think the problem is less severe with regard to TS because open source language-servers afford TypeScript IDE features universal availability which is not the case in JVM land. Also, consider the trend towards Kotlin in the Java world where a part of Jetbrain's business model relies on the fact that they created and maintain the language while also selling the IDE that makes the language practical to use (Kotlin being an amazing language notwithstanding).
  - jefflombardjr 7y ago
    Typescript: Putting the Java™ in Javascript
SmellyGeekBoy 7y ago
Last time I worked with Python or JavaScript I was using a very basic text editor. I'm not sure I'd be quite so brave with Java.
- kjeetgill 7y ago
  I don't know about JS, but my python work is done in a repl like ipython in conjunction with a text editor. It gets me half of what I wanted from an IDE.

KorematsuFred 7y ago

Java is not a cluttered house, it a mega warehouse with over billion products lying around. No amount of organizing will make it simple for you top find what you want. Hence the conveyer belt instead of better organization.

skizm 7y ago

A code base is not like a house. There is no "done" state. You have to rearrange and extend code bases every few months due to changing business needs.

Spooky23 7y ago

That's a design feature. Java is the modern COBOL. The idea is that you hire an army of marginally qualified developers through an agency that are making $14-18/hr in the US and have them churn out code. To use your house example, it's like addressing clutter by having 5 children and making them clean.

pjmlp 7y ago
Cobol is the modern COBOL. https://en.wikipedia.org/wiki/COBOL#COBOL_2014 https://en.wikipedia.org/wiki/COBOL#COBOL_2014

btilly 7y ago

My comment for years has been that most programming languages are for humans first, and computers second. But Java is for tools first, humans second and computers third. The result is an excellent toolchain. But also you are completely unproductive unless you master said toolchain.

zozbot234 7y ago

This kind of automation depends on a language being easy to parse, and Java achieves this better than C/C++ or most scripting languages. The LSP (language server protocol) is a language-independent standard that can be used to enable this more generally, by connecting parsers/compilers/etc. with editors/IDE's.

raverbashing 7y ago

It's a nice analogy. And I agree with it. For me it seems weird that the Java IDE is "smarter" than the compiler. Then why can't the compiler abstract stuff... Like the 'auto' keyword that took how long to exist again?

coding123 7y ago
The compiler is not interacting with the user. The ide isn't smart enough to apply some refactoring without the users consent.
phillipcarter 7y ago
This is just one example of a general tension between compiling to produce an asset vs compiling as a service to provide data for tooling. The environments and things you optimize for are different, so you get differences like this. Compilers like what C# and F# use unify these into the same codebase (no presentation compiler) but the tradeoffs still exist.

dehrmann 7y ago

I agree that Java is almost unwritable without an IDE, but that strictness has led to Java having better IDEs than most languages. For large code bases, most languages get unmaintainable without an IDE, putting Java at an advantage. I'd still use Python for something simple that won't grow past a few thousand lines, though.

mister_hn 7y ago
Well, having tried both Eclipse and IntelliJ Ultimate, I can say that * Eclipse has a crappy UI and can't handle Java9+ code very well, but can handle large code bases * IntelliJ Ultimate has nice UI and assistance, but it totally fails with large code bases and still tricks you if you run code inside the IDE, especially when you want to use jigsaw modules and not classpath, as it uses by default Unfortunately, using Java with other editors (vim, VS Codium, etc) is just difficult
wayoutthere 7y ago
I think part of what's happening right now is that the IDE for most languages other than Java seem to be consolidating on VS Code as the lowest common denominator. This makes sense given how many projects these days are a hodgepodge of 3 or 4 different languages, but the fact that working with the JVM more or less requires a dedicated IDE makes Java a lot less attractive to most teams. (Yes, I know you can do Java in VS Code but I wouldn't want to manage a large Java codebase with it.)
- JackFr 7y ago
  > I wouldn't want to manage a large Java codebase with it. Why not?
  - deleted 7y ago
    [deleted]
  - itronitron 7y ago
    probably because the code insight offered in VS Code is lagging behind what was available years ago in popular Java IDEs such as Eclipse and IntelliJ

eitland 7y ago

I dare anyone of you who thinks like this to study as much modern idiomatic Java as I've studied Python or Javascript. I'll give you this though: Old Spring and JSF code could be really bad, I remember updating two different XML files every time I changed something in a controller. Edit: even back then with all that boilerplate it was really nice compared to legacy Delphi where it took three full days with an expert to find and install all required dependencies before one could even start compiling the old source. By comparison my Java dev environment was up and running in less than half a day with Ant, and when we introduced Maven a few months later setip time for a new developer was mostly the time it took to check out code, install dev databases (yep, back in the days) and set necessary environment settings. (Protip: many people hate NetBeans but one thing it got more right than all other Java IDEs AFAIK was accepting the pom file as the truth instead of creating its own.

mdtusz 7y ago

I am a big fan of rust, but I am starting to feel like this is a thing with it too. Not to the same extent at all, but I often find myself writing what feels like scaffolding boilerplate code. That said, the code is usually there for a good reason and I'm extremely thankful for it in the instances where things are refactored and the compiler catches it, or some deviation from the norm comes up and the scaffold allows for doing things the way you need.

marcus_holmes 7y ago
ditto for Go. Huge fan, but it does involve a lot of boilerplate. Not that I think that's a bad thing. I prefer it to "magic" (I never got on with Rails because of this... what just happened? why did it do that? where does it say it should do that?). And you never know when you have a class/use case that needs the boilerplate to change. Having it the same 99% of the time so that you have the option to change it for that 1% edge case is a good thing, imho.
- pm90 7y ago
  Go seems to have much less boilerplate than Java. I’m really glad that OOP was explicitly unsupported and the language designers opted for using interfaces instead.
  - kjeetgill 7y ago
    Interfaces are as much a part of OOP as inheritance. Go is as OOP heavy as Java. They differ mostly in how/when an "class" is bound to an interface. Java declares up front, Go does this implicitly at usage sites aka static duck-typing (which is great!). That said, I think OOP education focused a lot on inheritance during Java's rise and that was mostly a mistake in hindsight.
  - ickyforce 7y ago
    > Go seems to have much less boilerplate than Java Maybe if you compare to Java from 10y ago. Have you ever tried to print a map in an alphabetical order of its keys? The only thing more verbose in Java are getters/setters which hopefully will disappear once records are available.

axaxs 7y ago

This is exactly why I've always had a strong aversion to Java. I like 'easy to remember' languages, with a strong preference towards Go and Python, and -somewhat- C though I don't use it often. In any of these languages, I can use an IDE with nice integrations, or if I want to write a quick one off, I can drop into vim and pound out a 50 liner and run it. This is an absolute nightmare to attempt in Java.

jayd16 7y ago

Java doesn't have a preprocessor macros so everything is generated explicitly. Its not that unique of a concept.

iampims 7y ago
It has build-time annotations though, which often serve the same purpose.

pashky 7y ago

On the other hand consider this: suppose you’ve built retail business out of your house, then it grew well. And now all those conveyor belts come in very handy, right? Sometimes project is big enough to have a lot of code, boilerplate or not. And then all that IDE automation suddenly becomes essential. I’ve been to some huge Scala codebases, it was much harder to navigate or make changes there than shove around Java cruft with IDE.

tyingq 7y ago

I can't imagine writing Java in a plain vim session. You would need a photographic memory.

peterashford 7y ago
Coding Java was what made me stop using Emacs for everything and switch to IDEs. It's a much better experience
- tyingq 7y ago
  I imagine you have an old keyboard somewhere where the "." key is worn smooth with no "." visible. Maybe the tab key on your current keyboard is now in similar condition.

whalesalad 7y ago

This is a trend I see reemerging with the hyper focus on VSCode. At some point people won’t be able to work on their projects without it. That might not be a good thing... as we have seen with Java. I like being able to consider a shell to be the lowest common denominator for a codebase. If basic shell commands, environment variables, a vanilla vim/nano editor etc... can’t be used to hack on your system then I think it’s far too coupled to tooling.

rmangi 7y ago
why are people afraid of modern text editors? Why cling to 1980s technology?
- epicide 7y ago
  I don't think it's necessarily (just) for a love of 80s editors. I think it's more of a litmus test that your developer experience is too tightly coupled with specific tooling. i.e. if you can't (realistically) choose your own tools, then your experience with the ecosystem is that of your experience with the tool. No tool can be a good experience for everybody.
  - pjmlp 7y ago
    Well some people would advertise UNIX as an IDE and then just try to turn into POSIX anything that they use, hardly any different.
    - epicide 7y ago
      I think you may be projecting others' arguments onto the parent. I did not read it as "everything should support the UNIX IDE" as much as expressing a preference for it and that it's a red flag if you can't even use standard vanilla tools (e.g. grep) to do basic things in an ecosystem. I think it's fair to say that you should be able to edit code in your editor of choice and not have a terrible time.
      - 7y ago

dcolkitt 7y ago

In some ways the Java philosophy seems like the antithesis of the Unix philosophy. Instead of a lot of small, fast, composable tools that do one thing and do it well, Java culture mostly promotes giant self-contained systems that capture everything in a sprawling OO type system. This distinction is reflected in even small design details. For example Java programs are comparatively slow to boot up. If you're mostly used to the Unix way of repeatedly piping the STDIN/STDOUT of small utilities in an interactive command line, this is painfully inconvenient. But if your workflow involves a monolithic server that manages every component of the business logic in a single process, then 5 second boot times aren't really a big deal. Because maybe you bounce the server once a week at most.

zten 7y ago
Yes! Things like Spring Boot are actually a reaction to the days of Java EE and the web of Java-centric technologies. This always confused me as a newer developer. Vendors competed with each other with different JavaEE implementations (WebSphere, Glassfish etc) that all conformed to the same interface and provided everything including the kitchen sink, but what really differentiated the products were vendor-specific features that require you to go outside the interface, but if you tried to use that stuff, another senior developer would tell you that we can't marry our implementation to a specific vendor... meanwhile, literally every company you go to uniformly uses Spring and Hibernate, and both will inevitably require you to not pretend that they're dumb implementations of javax.inject and javax.persistence.
- imtringued 7y ago
  And Micronaut is a reaction to Spring Boot bloat... And GraalVM native image is a solution to Micronaut bloat... When does it finally end?
pjmlp 7y ago
THE UNIX FOSS philosophy, hardly seen in commercial settings.
dionian 7y ago
back in the day when i started java, which was its early days(90's), we didnt even have a package manager type solution for java libraries (i.e. maven) - UNIX had a massive head start on java in some respects

alasdair_ 7y ago

I agree, it’s verbose. That being said, The boilerplate often helps when reading unfamiliar code. More importantly, the IDE support is fantastic, especially on large codebases. An example: if I want to refactor a simple thing like Rename a method called “doFoo()” I can do this trivially. Now, this seems simple but it’s not - I only want to refactor uses of this particular method, NOT any other methods that happen to be called “doFoo()” on unrelated classes or interfaces. Moreover, I want the refactor to intelligently work on everything, including inherited classes, abstract classes and interfaces, while correctly ignoring the stuff i mentioned previously. None of this matters much if you have a small codebase and a fee developers, but on a huge codebase with many developers, all that boilerplate lets people quickly understand new code and easily refactor that code while being sure they did not break anything.

jonfw 7y ago
I absolutely agree, and that is why Java is a great choice for monolithic applications. It's verbose and it's extremely flexible. The real reason to move away from Java is to move towards different software architectures (microservices!)
- alasdair_ 7y ago
  >The real reason to move away from Java is to move towards different software architectures (microservices!) This is a SpringBoot microservice: @RestController public class BasicController { @RequestMapping(value="/{id}", method = RequestMethod.GET) public String get(@PathVariable("id")Integer id) { return doStuff(id); } } I'm not sure it's any more verbose than the equivalent Ruby on Rails microservice (for example).
runT1ME 7y ago
>The boilerplate often helps when reading unfamiliar code I don't believe this to be true at all, especially for large code bases. Often the people who support this position have not worked on 100k, 500k, 1m LOC applications I've found. Boilerplate makes it much more difficult to read and scan large swatehs of code. I think when people say boilerplate 'helps', they often noticing a correlation between the fact that many strongly typed systems happen to have excess boilerplate. I believe it's the typing that helps, not the boilerplate.

pjmlp 7y ago

As proven by Xerox PARC, EHTZ, Apple, Borland and Microsoft tooling as well. The best programming languages for developer productivity are those that are designed with tooling in mind, instead of grammar + semantics and then we see later how everything evolves.

MichaelMoser123 7y ago

my question is how do you make sense of a seemingly endless stacktrace? (really curious, it's some time since i did something in java) Another problem i had with java: most projects are impossible to understand by looking at the source code, as they tend to do things like Spring or EJB: with delayed loading where class names are specified in some configuration files - and it is often hard to figure out how the system is initialized. That leads to another question: Is it possible to learn about an unfamiliar java project from source code in this day and age? i mean they used to say that perl is a write only language; but enterprise java isn't very readable either.

aembleton 7y ago
> Is it possible to learn about an unfamiliar java project from source code in this day and age? Yes it is, but it helps a lot if you're familiar with the framework and the original developer used sensible conventions. I guess that's the same with any language though.