> Fun fact: code written in JavaScript in 1995 will work in 2021, after 26 years.

Sure, as long as you run it in Netscape Navigator 2.0.

In 2021 you're lucky if a JavaScript web app that worked fine on Tuesday still works on Wednesday. And shocked if it works in any browser other than Chrome.

It's plainly untrue. I worked on ECMAScript proposals and TC39 takes backwards compatibility really seriously.

Browsers too take backwards compatibility very seriously and features stop working almost only if these are serious security holes.

You're right about backward compatibility - and yet so many things break anyway. And many web apps of the past only worked on Internet Explorer (much in the way that modern web apps only work on Chrome.)

However, the thing that broke Tuesday's app on Wednesday was probably a library or framework change.

That's the DOM manipulation and browser behaviors, not Javascript itself.

If you divorce JavaScript from the Dom you have removed it's entire reason for existence. So the dom is effectively part of the language. Just as the standard library is effectively part of C or Nim, etc. Without them they are considerably less useful.

You remove the reason -for its creation-. Not its reason for existence; Node is a thing, and doesn't touch the DOM. So, no, it's not effectively part of the language.

Ah, but code written in Common Lisp in 2021 will usually work in 1995, after -26 years.

:)

Aside from CL implementation bugs. The implementations had lots of them back then, even the commercial ones. Nowadays, they are much better. Decades of effort to make an implementation bug free and shiny will have its effect.

That really is amazing. Is it true, even "usually", for most types of code? Both forwards and backwards compatibility.. it's like the holy grail.

For most types of code, other than things like code which has dependencies on implementation internals (like extensions in SBCL for instance), or uses FFI to access platform libraries that didn't exist in 1995; that sort of thing.

ANSI CL was last ratified in 1994; there has been no standard language change, and the community language improvements are just macro libraries. You should be able to take your alexandria utilities library, or optima pattern matching or whatever back to 1995.

There are a few community improvements that are language extensions. The standard had no notion of multithreading, MOP was not in the standard, and packages really needed some way to avoid collisions of short package names (which lead to the de facto standardized package local nicknames.) Pathnames may also have seen some de facto standardization; they were poorly specified in the standard.

Maybe the C code was just badly written

Yep.

Use some of the -W* flags (-Wall -Wpedantic -Wconversion, ...) and specify the standard -std=c90.

Avoid undefined behaviors:

- https://en.cppreference.com/w/c/language/behavior

- https://wiki.sei.cmu.edu/confluence/display/c

(Also use cppcheck, valgrind, gdb, astyle, make, ...)

Done.

Fun fact: JS and C are both standardized by ISO.

And always use "-fwrapv -fno-strict-aliasing -fno-delete-null-pointer-checks". Those are source of the hardest to reason about UB and the small performance benefit is not worth the risk. I would love to always be certain I haven't accidentally hit UB, but that's equal to the halting problem, so for peace of mind, I just ask the compiler for a slightly safer variant of the language.

P.S. and old code definitely needs them, as at the time compilers didn't optimize so aggressively and lots of code does weird stuff with memory, shifts, etc.

Have a look at Apache 1 (C) or KDE 1 (C++); it'd be interesting to see what you think of those codebases, and they can certainly predate 2001.

Maybe it's next to impossible to write C code that isn't badly written

Or maybe we have too many developers that treat language of their choice as a religion.

>To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

-- https://www.bell-labs.com/usr/dmr/www/chist.html

Unfortunately since 1979, majority of C devs think they know better.

C code is of course close to the hardware, which as always, has benefits and drawbacks.

I was pretty sure that there were some subtle changes in ES5 and ES6 that were technically not backwards compatible (done because very little code depended on those behaviors)

Out of curiosity: would the 1995 JS code pass any modern code review?

I’d imagine it would get pinged for using var instead of let or const. And depending on who’s doing the review they might not like ‘new’.

>"I’d imagine it would get pinged for using var instead of let or const."

This single thing in isolation should never cast code as good or bad.

JS from 2003 passed code review for me a few months ago... so, yes... maybe.

Probably depends what it's doing. If it's interacting with HTML and manipulating the DOM then probably not

How do modern frameworks display content? Must be interacting with HTML and manipulating the DOM in some way.

It's not whether they do, it's how they do.

For instance, in 2003 there was no such thing as a mobile phone; passing code review today is probably going to entail either being responsive, or directing to a mobile version when accessed from a mobile device.

Okay, I will clarify my hyperbole in the face of the pedantic - mobile phones did not provide ubiquitous, standardized approaches to browsing the web, such that UX guidelines for the web did not include them; media queries and such did not exist except as drafts, etc etc.