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.

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.

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.

Second comment I have seen mentioning JavaBeans style getters and setters. What is the issue with it?

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

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.

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.

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.

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().)“

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.

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

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.

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.

Year the http stack was rewritten, But mvc handling was barley different between 4 and Core (besides namespaces)

Enjoy that. I’ve got a huge project which is wedged on 4.8 eternally.

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

That may work on the backend but not at all on the front-end. 20 years ago was the time of windows 2000 and Mac os 9. Not much about mobile applications. You could still use web technologies supported by internet explorer 5 though.

With a bit of squirming around, I've been able to write for Netscape2+/IE3+ and today's Chrome (and everything in between) at the same time.

Absent a link to support your claim, color me skeptical in the extreme that your "squirming" led to something remotely resembling a reasonably interactive, performant, maintainable web application. Perhaps you mean you've published some static HTML documents resembling a 1990's website?

The link is my profile.

It is a forum website with accounts, tagging, sorting, and moderation.

All these features are accessible to Netscape 2+ and IE3+, and also Opera 3+, Opera 12, Lynx, Links, w3m, NetSurf, Dillo, and many others, with and without JS enabled.

Accounts require cookies for now. Some enhancements require JS.

Mostly built by one dev in (copious) spare time.

My motivation is to preserve the knowledge of building compatible Web apps, to allow anyone to access my site, and to embarrass the big websites which complain if your Chrome is a couple versions behind.

I believe in aiming for 100%, not 95% accessibility, and here are some scenarios I've tested with:

* Older devices like my beloved iPads running iOS 7 and 8, which won't upgrade past that.

* Vision-impaired users with screen readers.

* Library computers stuch with IE and very old Firefox.

* Restricted access connections, browsing (and posting, and voting) via Google Translate.

* Slow connections and slow devices forced to browser without JS.

* Text-mode browsers Lynx and Links which were my only option at the time.

* Device without a keyboard available (I have several on-screen keyboards to choose from)

* Device without my keyboard layout of choice. With JS, I have two translit options at this time: phonetic-Cyrillic and Dvorak. NoJS support to come.

* Retro browsers from a long time ago with their unique beauty and features, e.g. Mosaic, IE3, Netscape, IE6, Opera 3, etc.

Some may consider these to be "edge cases" not worth a bother, at less than 0.1% of the visitors. I guess they might also consider a wheelchair ramp unnecessary, since it only gets used like once a year. I consider all these scenarios to be opportunities.

That's an impressive set of claims. But following your profile link (via bog-standard iOS 14, current Safari) triggered a prompt for credentials, with no hint as to their purpose or usage. That's as broken and inaccessible a UX as I've encountered in a long, long time.

The credentials are listed directly below the URL in my profile.

The site is just a demo for hackers and friends, not for general purpose use.

HTTP Basic auth helps prevent bot crawling, which the site is not yet optimized to cope with, while being by far the most supported auth scheme from mid-90s to today.

... not to mention use of a nsfw domain name which is its own form of poor UX and non-accessibility.

You're right. For now it is just a tech demo.

"Your website is almost here."

- dreamhost placeholder page

---

ps I'm really not trying to antagonize you; was genuinely curious about your claimed super-accessible website, and kept trying. Done now, have a great day and see you around HN.

Can you please remind me what website we're having this discussion on?

There's a big disconnect between many organizations that use libraries, compilers and tools from OS packages on stable Linux distributions, and the HN/SV crowd that uses docker, or pip/npm/go get/cargo even on production.

What's SV?

i think silicon valley.

hn has a big crowd of retro-lovers and nojs browsers.

Judging from the downvotes when suggesting to selectively disable js, that crowd is a small minority.

I comment on nojs matters often, and I've found that a lot depends on my tone and writing style.

If I'm terse and rude, I definitely get downvotes. If I'm verbose and explain my points, it's less likely, though still possible.

What about security vulnerabilities? Unless these are airgapped machines or otherwise not interoping with the rest of the world, you still need regular security patches to keep up with the latest ingenuity of hackers. And please don't say that old tech is immune to this, remember shellshock, rowhammer, goto-fail, spectre and many more.

As far as browsers go, when visiting my own trusted sites, I don't worry too much about vulnerabilities.

Most of the vulnerabilities are also JavaScript-driven, which is optional on my sites.

On the server side, of course, I use stuff which is still maintained and sometimes a multi-layer security approach.

There is no shortage of both established/mature and still-maintained tech around. Some examples I appreciate: GNU, POSIX, Linux, Perl, SQLite, PHP, Apache, Tcl.

For all of these examples there are many accessible resources with oodles of knowledge in many different convenient forms.

Newer stuff, where the main resources are Reddit and StackOverflow, and the writing is limited to just a couple of years, is nowhere near as rich or useful.

Many newer sites are also heavy and JavaScript-laden, both of which slows down access and skimming speed, if I can access them at all.

This is why I write Clojure. Lisp is Lindy. Lisp has been around for 60 years. 60 years from now, Lisp code will find a way to run.

What a stupid metric. 20 years is an insane amount of time in tech. HTML Canvas is only 16 years old.

Thank you for your feedback. I'm glad you think it's stupid.

I make some exceptions, and Canvas may be one of them in the future. It's not a hard limit, more like a guideline.

I want to make stuff that lasts at least as long, and that means I should use tech that's already been around that long, to take advantage of the Lindy Effect.

But can't that backfire? Python 2 just meets your criteria, but you shouldn't use it, vs Python 3 which is only 12 years old.

In what way is that a backfire? Python 2 was retired after 14 years. It began to show signs of impending retirement after about 9 years, in the form of fork of "new version", parallel to diminishing support of 2.x.

I saved myself a bunch of time on a rewrite.