4 ms·

Try that with .net. They fucked it up at least four times in that 20 year period and there’s lots of garbage information around now. Realistically the best app

by qz2 6y ago

Try that with .net. They fucked it up at least four times in that 20 year period and there’s lots of garbage information around now. Realistically the best approach for stability is to pick mature technology and that means stable, well designed and slow moving. Things like enterprise Linux distributions, Postgres, Go etc.

ivan_gammel 6y ago
Java is mature to the point when legacy is considered a best practice even when it’s not (e.g. JavaBeans style getters and setters). Old and mature may sometimes mean that you will work with the efficiency of developers from 20 years ago. I personally prefer an approach with controlled risks, doing as much experimentation as possible on a solid foundation. Scala won’t fit here as it pretends to be a platform, but this allows to avoid J2EE quagmire with smaller or better designed frameworks and libraries.
- qz2 6y ago
  Java is a mysterious one really. It’s probably the most complete stack of all but you’re right about the legacy. I find it difficult to evaluate which technologies are risky with it now because some of it is throughly abandoned.
- eecks 6y ago
  Second comment I have seen mentioning JavaBeans style getters and setters. What is the issue with it?
  - ywei3410 6y ago
    There's nothing specifically wrong with it; just that dogma without understanding why you're doing it is always problematic. If your coding rules state that /every/ object with any properties needs an associated getter/setter/Builder/Factory for any code then it quickly leads to a huge amount of code and indirection to do the most trivial of tasks - made worse by the fact that Java doesn't have first-class macros. In regards to getters and setters specifically; this stackoverflow post is quite good [1]. If those reasons don't apply then it just ends up complicating the solutions for very little benefit. [1] https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors https://stackoverflow.com/questions/1568091/why-use-getters-...
    - ivan_gammel 6y ago
      Actually there is something specific: while individual field accessors may make sense in some use cases (ActiveRecord or bidirectional UI mapping), the naming convention for them chosen in JavaBeans (“get/setXxx”) is too verbose and doesn’t make sense at all. Compare: 1. a.getFoo().getBar() vs a.foo().bar() or a.foo.bar 2. a.setFoo(1); a.setBoo(“moo”); vs a.foo(1).boo(“moo”); or a.onSomeEvent(1, “moo”); JavaBeans are often used in reflective mapping, but nothing prevents from using simpler convention the same way.
      - ywei3410 6y ago
        That's a fair point. I hadn't considered the names at all; I suppose one could argue that a three letter prefix is the least of Java's verbosity woes.
      - forgotmypw17 6y ago
        In my opinion, the three extra characters are worth it for reducing ambiguity. For example, it's clear to me what setFoo() and getFoo() does, but what about foo()? Does that return the value of foo() or does it run a process called foo()? JavaScript has a different but also unambiguous way of doing it, with a.foo used for properties, and a.foo() used for function. foo() is neither here nor there.
        ivan_gammel 6y ago
        The contexts in which this question would make sense are very rare, so no, it does not worth it. Let me also quote Brian Goetz on this topic: „No discussion involving boilerplate (or any question of Java language evolution, for that matter) can be complete without the subject of field accessors (and properties) coming up. On the one hand, accessors constitute a significant portion of the boilerplate in existing code; on the other hand, the JavaBean-style getter/setter conventions are already badly overused. Mutability may drag with it encapsulation, and encapsulation plus transparency may in turn drag accessors with them, but we should be mindful of the purpose of these accessors; it is not to abstract the representation from the API, but at most to enable rejection of bad values and provide syntactic uniformity of access. (Without rehashing the properties debate, one fundamental objection to automating JavaBean-style field accessors is that it would take what is at best a questionable -- and certainly overused -- API naming convention and burn it into the language. Unlike the core methods like Object.equals(), field accessors do not have any special treatment in the language, and so names of the form getSize() should not either. Also, while equally tedious, writing (and reading) accessor declarations are not nearly as error-prone as equals().)“
gnud 6y ago
I'm in a .net shop, and I've avoided most of the drama by sticking with .net 4.6/4.7 until now, and just ignoring anything to do with "core". I'm sticking my toes in the water with the new .net 5 now, hope I've waited long enough.
- merb 6y ago
  that wasn't a good move since 3.0 it's really really stable, heck even 2.1 and 3.0 barley changed. 5.0 is basically just a package upgrade (well npgsql+efcore has had some trouble, but that took only a few days) also if you did not use webforms it was basically also just a rename of using statements and impl classes between 4.7 and 2.x
  - gnud 6y ago
    If it's true that there's no real difference in libraries between 4.7 and 2.1, that makes me even more sure I made the right choice. I skipped a load of stress, and didn't even miss any important new knowledge.
    - qz2 6y ago
      There are a lot of changes. Don’t assume that poster is correct. A lot of the core HTTP stack has changed and a whole chunk of third party libraries are abandoned or rewritten entirely for .net core. Anything async is likely to be a complete pain in the ass.
      - merb 6y ago
        Year the http stack was rewritten, But mvc handling was barley different between 4 and Core (besides namespaces)
- qz2 6y ago
  Enjoy that. I’ve got a huge project which is wedged on 4.8 eternally.
forgotmypw17 6y ago
I should clarify, I meant stuff that's remained stable without many breaking changes for 20 years.

by qz2 6y ago

ivan_gammel 6y ago

Java is mature to the point when legacy is considered a best practice even when it’s not (e.g. JavaBeans style getters and setters). Old and mature may sometimes mean that you will work with the efficiency of developers from 20 years ago. I personally prefer an approach with controlled risks, doing as much experimentation as possible on a solid foundation. Scala won’t fit here as it pretends to be a platform, but this allows to avoid J2EE quagmire with smaller or better designed frameworks and libraries.

qz2 6y ago
Java is a mysterious one really. It’s probably the most complete stack of all but you’re right about the legacy. I find it difficult to evaluate which technologies are risky with it now because some of it is throughly abandoned.
eecks 6y ago
Second comment I have seen mentioning JavaBeans style getters and setters. What is the issue with it?
- ywei3410 6y ago
  There's nothing specifically wrong with it; just that dogma without understanding why you're doing it is always problematic. If your coding rules state that /every/ object with any properties needs an associated getter/setter/Builder/Factory for any code then it quickly leads to a huge amount of code and indirection to do the most trivial of tasks - made worse by the fact that Java doesn't have first-class macros. In regards to getters and setters specifically; this stackoverflow post is quite good [1]. If those reasons don't apply then it just ends up complicating the solutions for very little benefit. [1] https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors https://stackoverflow.com/questions/1568091/why-use-getters-...
  - ivan_gammel 6y ago
    Actually there is something specific: while individual field accessors may make sense in some use cases (ActiveRecord or bidirectional UI mapping), the naming convention for them chosen in JavaBeans (“get/setXxx”) is too verbose and doesn’t make sense at all. Compare: 1. a.getFoo().getBar() vs a.foo().bar() or a.foo.bar 2. a.setFoo(1); a.setBoo(“moo”); vs a.foo(1).boo(“moo”); or a.onSomeEvent(1, “moo”); JavaBeans are often used in reflective mapping, but nothing prevents from using simpler convention the same way.
    - ywei3410 6y ago
      That's a fair point. I hadn't considered the names at all; I suppose one could argue that a three letter prefix is the least of Java's verbosity woes.
    - forgotmypw17 6y ago
      In my opinion, the three extra characters are worth it for reducing ambiguity. For example, it's clear to me what setFoo() and getFoo() does, but what about foo()? Does that return the value of foo() or does it run a process called foo()? JavaScript has a different but also unambiguous way of doing it, with a.foo used for properties, and a.foo() used for function. foo() is neither here nor there.
      - ivan_gammel 6y ago
        The contexts in which this question would make sense are very rare, so no, it does not worth it. Let me also quote Brian Goetz on this topic: „No discussion involving boilerplate (or any question of Java language evolution, for that matter) can be complete without the subject of field accessors (and properties) coming up. On the one hand, accessors constitute a significant portion of the boilerplate in existing code; on the other hand, the JavaBean-style getter/setter conventions are already badly overused. Mutability may drag with it encapsulation, and encapsulation plus transparency may in turn drag accessors with them, but we should be mindful of the purpose of these accessors; it is not to abstract the representation from the API, but at most to enable rejection of bad values and provide syntactic uniformity of access. (Without rehashing the properties debate, one fundamental objection to automating JavaBean-style field accessors is that it would take what is at best a questionable -- and certainly overused -- API naming convention and burn it into the language. Unlike the core methods like Object.equals(), field accessors do not have any special treatment in the language, and so names of the form getSize() should not either. Also, while equally tedious, writing (and reading) accessor declarations are not nearly as error-prone as equals().)“

gnud 6y ago

I'm in a .net shop, and I've avoided most of the drama by sticking with .net 4.6/4.7 until now, and just ignoring anything to do with "core". I'm sticking my toes in the water with the new .net 5 now, hope I've waited long enough.

merb 6y ago
that wasn't a good move since 3.0 it's really really stable, heck even 2.1 and 3.0 barley changed. 5.0 is basically just a package upgrade (well npgsql+efcore has had some trouble, but that took only a few days) also if you did not use webforms it was basically also just a rename of using statements and impl classes between 4.7 and 2.x
- gnud 6y ago
  If it's true that there's no real difference in libraries between 4.7 and 2.1, that makes me even more sure I made the right choice. I skipped a load of stress, and didn't even miss any important new knowledge.
  - qz2 6y ago
    There are a lot of changes. Don’t assume that poster is correct. A lot of the core HTTP stack has changed and a whole chunk of third party libraries are abandoned or rewritten entirely for .net core. Anything async is likely to be a complete pain in the ass.
    - merb 6y ago
      Year the http stack was rewritten, But mvc handling was barley different between 4 and Core (besides namespaces)
qz2 6y ago
Enjoy that. I’ve got a huge project which is wedged on 4.8 eternally.

forgotmypw17 6y ago

I should clarify, I meant stuff that's remained stable without many breaking changes for 20 years.