6 ms·

> programming languages where if you write code now - you will be able to compile and use that code ten years from now (a software lifecycle eternity) Fun fact

by Ginden 5y ago

> programming languages where if you write code now - you will be able to compile and use that code ten years from now (a software lifecycle eternity) Fun fact: code written in JavaScript in 1995 will work in 2021, after 26 years. If you are talking about "good practices" - few weeks ago I worked with C code from 2001 and it was just awful. Yes, it compiles - but it wouldn't pass any modern code review.

rmbyrro 5y ago
Out of curiosity: would the 1995 JS code pass any modern code review?
- casion 5y ago
  JS from 2003 passed code review for me a few months ago... so, yes... maybe.
  - deleted 5y ago
    [deleted]
- np_tedious 5y ago
  Probably depends what it's doing. If it's interacting with HTML and manipulating the DOM then probably not
  - helsontaveras18 5y ago
    How do modern frameworks display content? Must be interacting with HTML and manipulating the DOM in some way.
    - lostcolony 5y ago
      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.
      - kgwgk 5y ago
        https://news.microsoft.com/2001/02/19/microsoft-mobile-explorer-3-0-provides-tomorrows-wap-2-0-functionality-today/ https://news.microsoft.com/2001/02/19/microsoft-mobile-explo...
        lostcolony 5y ago
        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.
- deleted 5y ago
  [deleted]
- mr_toad 5y ago
  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’.
  - FpUser 5y ago
    >"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.
koonsolo 5y ago
Maybe the C code was just badly written
- dankoncs 5y ago
  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://en.cppreference.com/w/c/language/behavior - https://wiki.sei.cmu.edu/confluence/display/c 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.
  - throwawayapples 5y ago
    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.
  - Asooka 5y ago
    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.
- voxl 5y ago
  Maybe it's next to impossible to write C code that isn't badly written
  - FpUser 5y ago
    Or maybe we have too many developers that treat language of their choice as a religion.
musicale 5y ago
> 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.
- lostcolony 5y ago
  That's the DOM manipulation and browser behaviors, not Javascript itself.
  - kwhitefoot 5y ago
    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.
    - lostcolony 5y ago
      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.
- Ginden 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - musicale 5y ago
    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.
kazinator 5y ago
Ah, but code written in Common Lisp in 2021 will usually work in 1995, after -26 years. :)
- throwawayapples 5y ago
  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.
  - kazinator 5y ago
    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.
    - pfdietz 5y ago
      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.
- pfdietz 5y ago
  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.
hajile 5y ago
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)

by Ginden 5y ago

rmbyrro 5y ago

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

casion 5y ago
JS from 2003 passed code review for me a few months ago... so, yes... maybe.
- deleted 5y ago
  [deleted]
np_tedious 5y ago
Probably depends what it's doing. If it's interacting with HTML and manipulating the DOM then probably not
- helsontaveras18 5y ago
  How do modern frameworks display content? Must be interacting with HTML and manipulating the DOM in some way.
  - lostcolony 5y ago
    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.
    - kgwgk 5y ago
      https://news.microsoft.com/2001/02/19/microsoft-mobile-explorer-3-0-provides-tomorrows-wap-2-0-functionality-today/ https://news.microsoft.com/2001/02/19/microsoft-mobile-explo...
      - lostcolony 5y ago
        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.
deleted 5y ago
[deleted]
mr_toad 5y ago
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’.
- FpUser 5y ago
  >"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.

koonsolo 5y ago

Maybe the C code was just badly written

dankoncs 5y ago
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://en.cppreference.com/w/c/language/behavior - https://wiki.sei.cmu.edu/confluence/display/c 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.
- throwawayapples 5y ago
  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.
- Asooka 5y ago
  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.
voxl 5y ago
Maybe it's next to impossible to write C code that isn't badly written
- FpUser 5y ago
  Or maybe we have too many developers that treat language of their choice as a religion.

musicale 5y ago

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

lostcolony 5y ago
That's the DOM manipulation and browser behaviors, not Javascript itself.
- kwhitefoot 5y ago
  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.
  - lostcolony 5y ago
    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.
Ginden 5y ago
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.
- deleted 5y ago
  [deleted]
- musicale 5y ago
  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.

kazinator 5y ago

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

throwawayapples 5y ago
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.
- kazinator 5y ago
  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.
  - pfdietz 5y ago
    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.
pfdietz 5y ago
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.

hajile 5y ago

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)