101–110 of 193 posts
What a strong ad for Java
stuff written for java 0.9 (1996), even with the default package (no namespaces), still runs normally. 2011 is past java 7.
Seriously though, this seems to be due to happenstance (well, commercial interest motivating great continuous engineering effort), rather than by design (forward-thinking) though; unlike, say, IBM's Technology Independent Machine Interface of AS/400.
Not to be snarky but 2011 is yesterday for programming, no major shift. I'd imagine almost all code written there would be able to run today.
You've had a very different experience of the past 13 years if you've experienced no major shifts. Even the past year has had a whole big change with the advent of LLMs, nevermind the rise of the web, VSCode, typescript, rust, and more. In 2011, Java was on version 7. We're on 22 now in 2024. There have been some paradigm shifts in Java during that time. Streams (Java 8), Lambda expressions (Java 9), the var keyword…
In the IDE technology, the jump was even larger. In 2011, I was using Intellij 10, now I'm on version 2024.
> There have been some paradigm shifts in Java during that time. Streams (Java 8), Lambda expressions (Java 9), the var keyword (Java 10), Records (Java 14), switch and yield (Java 12/14), instanceof (Java 16).
The only listed Java feature which represented a paradigm shift was lambda expressions (which were released in v8, not v9), the rest are minor features.
Earlier quoted context omitted.
Perl /4/ in 2002? When I learned perl in like 1995, 5 had been out for a bit already and it was hard to find a system with 4 installed... (perl 4 didn't have built in support for OO; did you roll your own system?)
To be fair it is perl, there was probably a library for it.
Don't remember anyone doing OO back then with it, either. Would be interested to know how that worked...
Earlier quoted context omitted.
that should be the norm. the reality is that is a strong ad against almost all modern frameworks, that may live for as little as a football season
Not really. Not automatically, anyway. Realistically, code lasting forever is, the majority of the time, some engineer’s nerdy wet dream almost completely devoid from any real-world requirements. “This code should last 20 years” should, for most people, be fairly low on the list of desires for a technology stack. In the vast majority of cases, the processes that the software seeks to automate will have been thrown ou…
Earlier quoted context omitted.
Interestingly, i have a similar story. I created a database publishing platform exactly that time, a was given full control. I created it in Java, and added a JavaScript engine for scripting templates. The initial product was also side in a few months. It also runs to this day. The war file could be run by any Java server. The code, while old, was in a reasonable state, given some of the migrations. I never thought a…
There's nothing more permanent than a temporary fix put in while waiting for a permanent fix for a problem.
"Nothing more permanent than the temporary"
Earlier quoted context omitted.
In the Java world, sure. Other programming language ecosystems tend to have tons of churn. For an anecdote, every TypeScript project I find from 2021 or earlier is simply impossible to build nowadays, meanwhile the ClojureScript code I dealt with in a previous job was able to survive 8 years worth of updates to libraries and the core language. I frequently ran into code that was last modified around 2013 because it j…
> every TypeScript project I find from 2021 or earlier is simply impossible to build nowadays, This is the fault of all the bullshit tools that were never any good to begin with (Webpack, Babel, etc) and the Node ecosystem generally causing pain. If you had a package-lock.json you should (in theory) be able to install all of those and it should work. Of course, this relies on dependencies of dependencies actually fol…
not sure how one can have a problem running something if it installs all the same dependencies and using the same scripts
Not to be snarky but 2011 is yesterday for programming, no major shift. I'd imagine almost all code written there would be able to run today.
In the Java world, sure. Other programming language ecosystems tend to have tons of churn. For an anecdote, every TypeScript project I find from 2021 or earlier is simply impossible to build nowadays, meanwhile the ClojureScript code I dealt with in a previous job was able to survive 8 years worth of updates to libraries and the core language. I frequently ran into code that was last modified around 2013 because it j…
As a bonus -- IDEs seem to work faster with Maven, I assume because parsing declarative pom.xml is faster than parsing and running imperative build.gradle.
My earliest "large" program which I can remember was a drawing program I wrote in GW BASIC. You could draw figures, change brushes, I think it had a crude filling function and a few other things. In my innocence, I backed it up onto 5.25" floppy disks, labelled them neatly and put them in a box. This was in the late 1980s. Fast forward to 2024, I still have the disks but no drive to read them. On the other hand, the…
Are you me ? I wrote an exact program like this in GW Basic back in the day. I remember adding the ability to draw coloured lines but I had no way to verify since my computer monitor was one of those with green coloured pixels. Finally got to see everything in full colour at my school lab and was so thrilled. Those were the days ...