10 ms·

This. Far from being a fanboy of Java (and I write JS for a living), but you can generally quickly understand what's going on with the boring code, and can refa

This. Far from being a fanboy of Java (and I write JS for a living), but you can generally quickly understand what's going on with the boring code, and can refactor mercilessly. Whereas in huge JS codebases relying on framework magic you can really have hard time to understand what's going on without plugging a debugger (and even then it's still not easy). Trying to refactor legacy code that relies on `this` and prototypes is a nightmare.

eecc 7y ago
Magik? Has anyone mentioned Spring yet?
- jdmichal 7y ago
  Spring magic is both relatively straight-forward to understand, and actually relies on heavy typing for autowiring.
  - eecc 7y ago
    Uh right, sure. But then there's the Spring lifecycle to take into consideration and it may happen that your annotations may or may not work. It depends (of course it's not totally aleatory, there's some logic behind it, usually obvious after several hours debugging ;) Another honorable mention is Spring Boot @Conditional for which adding a minor little diversion from defaults will turn a functioning happy project in a dysfunctional nightmare. :'(
    - jdmichal 7y ago
      I agree with you completely on that. I'll clarify that, to me, there's a difference between straight-forward and obvious. And Spring is terrible at being obvious. Some annotation on a class 5 transitive dependencies deep can affect your code. It's definitely really deep into "spooky action at a distance", and that's always a nightmare for debugging. But once you see all the pieces, it's (usually) relatively straight-forward to describe what is happening.
    - ubu7737 7y ago
      Spring is semi-magical but when you learn the whole thing it gives you godlike abilities.
      - eecc 7y ago
        Really? Try Clojure then
gldalmaso 7y ago
The worst experience I had refactoring JS was the need to change functions that were used elsewhere from plain to async. I really hoped to have had a strong IDE that could assure me the affected code was as intended and did not have the flow completely break because a promise was returned where none was expected before. I distinctively thought "I wish this was Java". Some of the affected code was already in Typescript and that did help a bit, but I was still not too confident because I still didn't trust the IDE completely (Typescript support was comparatively new). I have even come to question if we should make all our javascript apis async from the start to avoid this scenario though it seems a rather extreme guideline. We didn't really do that, but I still dread this type of refactoring.
_zamorano_ 7y ago
This! I sometimes wonder if JS programmers know that with C#/VS you can just change the name of a class, and without doing anything else (not even replacing), all involved names just change, and everything works 100%, without writing any test. And the same goes for moving a method to another class, or renaming member variables, modules, files... everything just works and is instantaneous. To me, not being able to aggresively refactor withour worrying something will break somewhere is like backwards and old school (in the bad way) When a project evolves, a class, a struct... grows and suddenly a name, perfectly fine at the beggining, does not make sense any longer. With C#/VS you just change and 2 seconds later you're still working.
- STRiDEX 7y ago
  renaming a class in vscode works in js and ts via typescript language service.
  - _zamorano_ 7y ago
    Honest question: By "works" you mean you have 100% guarantee nothing will break nowhere?
    - treve 7y ago
      Edge cases exist. I'd assume that Java and c# will also have edge-cases when things like reflection come into play.
      - Filligree 7y ago
        Certainly, but reflection is almost never used. I don't think I've touched a single real-life codebase where it would get in the way in this manner. The same can't be said for languages like JS.
        smhinsey 7y ago
        Even reflection is going to vary based on your IDE. If you use ReSharper or Rider, a safe rename refactoring will locate and optionally update string references as well. I don't know if VS itself has adopted this feature.
jacobush 7y ago
Same for Python codebases. Which I wrote myself. Last year. And now hate.
erik_seaberg 7y ago
Boilerplate is the enemy. IDEs can easily write piles of it, but offer very little help reading any of it, and editing it is a trap. Anything that can be generated behind the scenes, compiled, and thrown away should be.
- TeMPOraL 7y ago
  Indeed, IDEs are still oriented towards writing code, not reading it. I'm yet to find a good tool that would help with exploring and familiarizing yourself with a large codebase. Soucetrail comes the closest, but it has like 5% of the features I'd like to see in it. (My dream code exploring tool would be a cross between an IDE and a tablet&pen friendly PDF reader. I should be able to navigate through files using all the semantics-aware IDE goodies, the tool should also understand version control, but it should also be able to generate and manipulate structural graphs (as in, boxes and arrows), as well as let me highlight, draw and freehand over the code.)
  - LameRubberDucky 7y ago
    UML?
tlarkworthy 7y ago
Sadly in practice, runtime dependency injection swaps compile errors for runtime errors. I hate DI!
lallysingh 7y ago
I disagree. The cognitive overhead of sifting through so much boilerplate hides a lot of bad code. The identifiers and logic seem reasonable in an island surrounded by getters, setters, builders, injection annotations, overloads, and trivial constructors. But in context of the actual code invoking it, also surrounded in an ocean of boilerplate, the code does the wrong thing. The overhead has significant cost for trivial gains. The costs result in overly complicated systems to solve simple problems. Most of the complexity in these systems is for dealing with complexity brought in by the ecosystem, not the problem domain.

eecc 7y ago

Magik? Has anyone mentioned Spring yet?

jdmichal 7y ago
Spring magic is both relatively straight-forward to understand, and actually relies on heavy typing for autowiring.
- eecc 7y ago
  Uh right, sure. But then there's the Spring lifecycle to take into consideration and it may happen that your annotations may or may not work. It depends (of course it's not totally aleatory, there's some logic behind it, usually obvious after several hours debugging ;) Another honorable mention is Spring Boot @Conditional for which adding a minor little diversion from defaults will turn a functioning happy project in a dysfunctional nightmare. :'(
  - jdmichal 7y ago
    I agree with you completely on that. I'll clarify that, to me, there's a difference between straight-forward and obvious. And Spring is terrible at being obvious. Some annotation on a class 5 transitive dependencies deep can affect your code. It's definitely really deep into "spooky action at a distance", and that's always a nightmare for debugging. But once you see all the pieces, it's (usually) relatively straight-forward to describe what is happening.
  - ubu7737 7y ago
    Spring is semi-magical but when you learn the whole thing it gives you godlike abilities.
    - eecc 7y ago
      Really? Try Clojure then

gldalmaso 7y ago

The worst experience I had refactoring JS was the need to change functions that were used elsewhere from plain to async. I really hoped to have had a strong IDE that could assure me the affected code was as intended and did not have the flow completely break because a promise was returned where none was expected before. I distinctively thought "I wish this was Java". Some of the affected code was already in Typescript and that did help a bit, but I was still not too confident because I still didn't trust the IDE completely (Typescript support was comparatively new). I have even come to question if we should make all our javascript apis async from the start to avoid this scenario though it seems a rather extreme guideline. We didn't really do that, but I still dread this type of refactoring.

_zamorano_ 7y ago

This! I sometimes wonder if JS programmers know that with C#/VS you can just change the name of a class, and without doing anything else (not even replacing), all involved names just change, and everything works 100%, without writing any test. And the same goes for moving a method to another class, or renaming member variables, modules, files... everything just works and is instantaneous. To me, not being able to aggresively refactor withour worrying something will break somewhere is like backwards and old school (in the bad way) When a project evolves, a class, a struct... grows and suddenly a name, perfectly fine at the beggining, does not make sense any longer. With C#/VS you just change and 2 seconds later you're still working.

STRiDEX 7y ago
renaming a class in vscode works in js and ts via typescript language service.
- _zamorano_ 7y ago
  Honest question: By "works" you mean you have 100% guarantee nothing will break nowhere?
  - treve 7y ago
    Edge cases exist. I'd assume that Java and c# will also have edge-cases when things like reflection come into play.
    - Filligree 7y ago
      Certainly, but reflection is almost never used. I don't think I've touched a single real-life codebase where it would get in the way in this manner. The same can't be said for languages like JS.
      - smhinsey 7y ago
        Even reflection is going to vary based on your IDE. If you use ReSharper or Rider, a safe rename refactoring will locate and optionally update string references as well. I don't know if VS itself has adopted this feature.

jacobush 7y ago

Same for Python codebases. Which I wrote myself. Last year. And now hate.

erik_seaberg 7y ago

Boilerplate is the enemy. IDEs can easily write piles of it, but offer very little help reading any of it, and editing it is a trap. Anything that can be generated behind the scenes, compiled, and thrown away should be.

TeMPOraL 7y ago
Indeed, IDEs are still oriented towards writing code, not reading it. I'm yet to find a good tool that would help with exploring and familiarizing yourself with a large codebase. Soucetrail comes the closest, but it has like 5% of the features I'd like to see in it. (My dream code exploring tool would be a cross between an IDE and a tablet&pen friendly PDF reader. I should be able to navigate through files using all the semantics-aware IDE goodies, the tool should also understand version control, but it should also be able to generate and manipulate structural graphs (as in, boxes and arrows), as well as let me highlight, draw and freehand over the code.)
- LameRubberDucky 7y ago
  UML?

tlarkworthy 7y ago

Sadly in practice, runtime dependency injection swaps compile errors for runtime errors. I hate DI!

lallysingh 7y ago

I disagree. The cognitive overhead of sifting through so much boilerplate hides a lot of bad code. The identifiers and logic seem reasonable in an island surrounded by getters, setters, builders, injection annotations, overloads, and trivial constructors. But in context of the actual code invoking it, also surrounded in an ocean of boilerplate, the code does the wrong thing. The overhead has significant cost for trivial gains. The costs result in overly complicated systems to solve simple problems. Most of the complexity in these systems is for dealing with complexity brought in by the ecosystem, not the problem domain.