7 ms·

One of the reasons I’m very for open-source (including all my code) is for the reason that porting is easier. It seems like the gripe should not be with Apple c

One of the reasons I’m very for open-source (including all my code) is for the reason that porting is easier. It seems like the gripe should not be with Apple changing processors (or OS’s or hardware features or ...), but rather that (especially commercial) software is so fragile to medium-term environmental change. Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. High-level programming language code, on the other hand, is much more resilient. It’s also a reason I use Lisp: the spec doesn’t change and won’t change. Stuff runs forever.

ssivark 6y ago
Bingo! It’s boil-the-ocean level crazy to attempt to recreate the environment for a particular file, when the sensible approach would be to just have the file format and it’s reader/viewer software be open so it can be recompiled or ported to any new platform. The blame/responsibility lies not with those innovating on hardware, but those who have created brittle software systems which have no ability to adapt to the changing environment. Yet another example of how holding binary artifacts is not functional equivalent to “owning” software.
- rubyfan 6y ago
  agree, the authors mention of hacking around activation servers on legacy products is as much the problem as anything. it’s an odd sort of expectation that we’d have to be able to emulate 3+ generations of hardware on top of one another just to access an old file. Should we expect to be able to do this as hardware gets more sophisticated? I’m not convinced we should.
- naravara 6y ago
  This is probably a path dependent outcome from the process that brought us the the "personal computing" era. It really kicked into gear and achieved ubiquity with Microsoft selling both the main operating system AND the "standard" productivity software suite that was the primary reason people owned computers. MS made their money back then selling upgrades to Microsoft Office that broke backwards compatibility. Part of the strategy was owning the environment so they could work in some amount of engineered obsolescence into the software lifecycle. Of course, because Microsoft was a multi-headed chimera, Windows itself bent over backwards to keep everything not Office chugging along forever.
goatinaboat 6y ago
Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. High-level programming language code, on the other hand, is much more resilient. That’s a modern phenomenon. AS/400 or Solaris binaries were different.
- kazinator 6y ago
  Binaries on Microsoft Windows are more resilient than some GNU/Linux source code.
  - jdc 6y ago
    Except it's really the OS doing cartwheels to keep them going.
    - pdimitar 6y ago
      At one point I stopped caring how they do it. I just want them to do it. We can't all be everywhere at the stack at the same time. We have work to do.
    - kazinator 6y ago
      Or maybe it's the OS refraining from doing cartwheels that keeps them going.
      - jdc 6y ago
        You're right in that a stable ABI goes a long way to keep old binaries working! My point is about this sort of thing: > [...] anybody who has read the Old New Thing blog (https://blogs.msdn.microsoft.com/oldnewthing/ https://blogs.msdn.microsoft.com/oldnewthing/) or Raymond Chen's chapter on Windows backwards compatibility (http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch01.pdf http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech..., PDF) will be both impressed and horrified at the lengths the Windows team went to in order to avoid breaking programs. https://news.ycombinator.com/item?id=13450629 https://news.ycombinator.com/item?id=13450629
ghaff 6y ago
Which was, in fact, a lot of the impetus behind open source generally early on. And even the less formal sharing of Unix source code given that it was written in a high-level language and could therefore be relatively easily ported to new systems.
heavyset_go 6y ago
> Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. Depends on the platform. I can run statically compiled Linux binaries that were released 20 years ago just fine. Similarly, I'm able play Windows games that were released over 20 years ago.
- reikonomusha 6y ago
  These are examples of binaries that explicitly don’t depend on so much of their surroundings. They depend on the existence of a processor and a binary executable format, and perhaps some very basic syscalls that had no business changing.
- bzzzt 6y ago
  Maybe the binary runs, but for any non-trivial I/O (GUI, 3D, specialized input devices) you're still dependent on specific interfaces which are probably not the same anymore. Case in point: try running any of the Loki Linux game ports from 20 years ago on a modern distribution...
- setr 6y ago
  Not by accident... Linux, windows and intel have put in a lot of effort to ensure this holds, specifically because binaries are so incredibly fragile — hell, you’d have the same trouble Mac is having now if you tried to swap out to AMD on any OS; or tried to swap out OS on same hardware. Really, you should generally be under the presumption that changing anything at all could screw up anything and everything; it’s really a marvel of human engineering anytime software runs successfully
- Volt 6y ago
  And when your Linux environment moves to ARM?
sidpatil 6y ago
"Adapting old programs to fit new machines usually means adapting new machines to behave like old ones." Epigram 120, Alan Perlis. http://www.cs.yale.edu/homes/perlis-alan/quotes.html http://www.cs.yale.edu/homes/perlis-alan/quotes.html
- throwaway201103 6y ago
  This is how IBM mainframes are still able to run COBOL binaries from many decades ago
- Pet_Ant 6y ago
  > adapting new machines to behave like old ones There is a great DailyWTF somewhere about a company that was using an early IBM mainframe, which when it died, instead of porting their code to the newer mainframe, the wrote an emulator. And when AIX came around they wrote a mainframe emulator to run their old emulator... This maybe the story I was misremembering the details of?: https://thedailywtf.com/articles/No_Need_to_Change_It!_ https://thedailywtf.com/articles/No_Need_to_Change_It!_
peterwwillis 6y ago
Right... Let me know how Python 2.7 code runs ina few years.
- peterburkimsher 6y ago
  Indeed. The most stable long-term is probably a small C program, designed for pipes with stdin as input, and stdout as output. UNIX philosophy is great for longevity. "Everything is a file" only works when TXT is the file format though. When things build up to PostScript or PDF, or Claris... then things get out of hand too quickly.
- Shish2k 6y ago
  … why would it not run fine? Python 2.7 is “no longer receiving updates”, not “ceasing to exist”. You can still download source code back to Python 1.5.1 if you really want to run code with old syntax (Which I just did for fun - the C code needed one tweak to avoid conflicting with a recently introduced standard library function; the python code was fine)
- simonh 6y ago
  Id be very surprised, shocked if I cant run a vanilla stdlib only Python 2.7 script on all the major platforms in 10 years time, even 20 years time.
- m-p-3 6y ago
  If the code isn't going to change, you could statically compile it and it will run just fine.
lenkite 6y ago
Will Lisp ever specify concurrency as part of the specification ? Standard well-supported concurrency is vital for any modern-day programming language. Without that, common LISP is relegated to the realm of gradually dying languages.
- pdimitar 6y ago
  Exactly the reason I dipped my toes in Racket, loved it, then went back to Elixir (and Rust). Without a good runtime / libraries to tackle concurrency and parallelism in a transparent way -- as Erlang/Elixir and other BEAM VM languages do -- the other traits of a language take a back seat.
mark_l_watson 6y ago
+1 right on. I would like to see more companies open source their commercial products after maintaining them is not cost effective. I would like to see mostly open source code, period. re: Lisps: I have been using Common Lisp since 1982 (and other Lisps before that) and I love it that my old code and archives of other peoples’ Common Lisp code usually runs with no problems.

ssivark 6y ago

Bingo! It’s boil-the-ocean level crazy to attempt to recreate the environment for a particular file, when the sensible approach would be to just have the file format and it’s reader/viewer software be open so it can be recompiled or ported to any new platform. The blame/responsibility lies not with those innovating on hardware, but those who have created brittle software systems which have no ability to adapt to the changing environment. Yet another example of how holding binary artifacts is not functional equivalent to “owning” software.

rubyfan 6y ago
agree, the authors mention of hacking around activation servers on legacy products is as much the problem as anything. it’s an odd sort of expectation that we’d have to be able to emulate 3+ generations of hardware on top of one another just to access an old file. Should we expect to be able to do this as hardware gets more sophisticated? I’m not convinced we should.
naravara 6y ago
This is probably a path dependent outcome from the process that brought us the the "personal computing" era. It really kicked into gear and achieved ubiquity with Microsoft selling both the main operating system AND the "standard" productivity software suite that was the primary reason people owned computers. MS made their money back then selling upgrades to Microsoft Office that broke backwards compatibility. Part of the strategy was owning the environment so they could work in some amount of engineered obsolescence into the software lifecycle. Of course, because Microsoft was a multi-headed chimera, Windows itself bent over backwards to keep everything not Office chugging along forever.

goatinaboat 6y ago

Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. High-level programming language code, on the other hand, is much more resilient. That’s a modern phenomenon. AS/400 or Solaris binaries were different.

kazinator 6y ago
Binaries on Microsoft Windows are more resilient than some GNU/Linux source code.
- jdc 6y ago
  Except it's really the OS doing cartwheels to keep them going.
  - pdimitar 6y ago
    At one point I stopped caring how they do it. I just want them to do it. We can't all be everywhere at the stack at the same time. We have work to do.
  - kazinator 6y ago
    Or maybe it's the OS refraining from doing cartwheels that keeps them going.
    - jdc 6y ago
      You're right in that a stable ABI goes a long way to keep old binaries working! My point is about this sort of thing: > [...] anybody who has read the Old New Thing blog (https://blogs.msdn.microsoft.com/oldnewthing/ https://blogs.msdn.microsoft.com/oldnewthing/) or Raymond Chen's chapter on Windows backwards compatibility (http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch01.pdf http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech..., PDF) will be both impressed and horrified at the lengths the Windows team went to in order to avoid breaking programs. https://news.ycombinator.com/item?id=13450629 https://news.ycombinator.com/item?id=13450629

ghaff 6y ago

Which was, in fact, a lot of the impetus behind open source generally early on. And even the less formal sharing of Unix source code given that it was written in a high-level language and could therefore be relatively easily ported to new systems.

heavyset_go 6y ago

> Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. Depends on the platform. I can run statically compiled Linux binaries that were released 20 years ago just fine. Similarly, I'm able play Windows games that were released over 20 years ago.

reikonomusha 6y ago
These are examples of binaries that explicitly don’t depend on so much of their surroundings. They depend on the existence of a processor and a binary executable format, and perhaps some very basic syscalls that had no business changing.
bzzzt 6y ago
Maybe the binary runs, but for any non-trivial I/O (GUI, 3D, specialized input devices) you're still dependent on specific interfaces which are probably not the same anymore. Case in point: try running any of the Loki Linux game ports from 20 years ago on a modern distribution...
setr 6y ago
Not by accident... Linux, windows and intel have put in a lot of effort to ensure this holds, specifically because binaries are so incredibly fragile — hell, you’d have the same trouble Mac is having now if you tried to swap out to AMD on any OS; or tried to swap out OS on same hardware. Really, you should generally be under the presumption that changing anything at all could screw up anything and everything; it’s really a marvel of human engineering anytime software runs successfully
Volt 6y ago
And when your Linux environment moves to ARM?

sidpatil 6y ago

"Adapting old programs to fit new machines usually means adapting new machines to behave like old ones." Epigram 120, Alan Perlis. http://www.cs.yale.edu/homes/perlis-alan/quotes.html http://www.cs.yale.edu/homes/perlis-alan/quotes.html

throwaway201103 6y ago
This is how IBM mainframes are still able to run COBOL binaries from many decades ago
Pet_Ant 6y ago
> adapting new machines to behave like old ones There is a great DailyWTF somewhere about a company that was using an early IBM mainframe, which when it died, instead of porting their code to the newer mainframe, the wrote an emulator. And when AIX came around they wrote a mainframe emulator to run their old emulator... This maybe the story I was misremembering the details of?: https://thedailywtf.com/articles/No_Need_to_Change_It!_ https://thedailywtf.com/articles/No_Need_to_Change_It!_

peterwwillis 6y ago

Right... Let me know how Python 2.7 code runs ina few years.

peterburkimsher 6y ago
Indeed. The most stable long-term is probably a small C program, designed for pipes with stdin as input, and stdout as output. UNIX philosophy is great for longevity. "Everything is a file" only works when TXT is the file format though. When things build up to PostScript or PDF, or Claris... then things get out of hand too quickly.
Shish2k 6y ago
… why would it not run fine? Python 2.7 is “no longer receiving updates”, not “ceasing to exist”. You can still download source code back to Python 1.5.1 if you really want to run code with old syntax (Which I just did for fun - the C code needed one tweak to avoid conflicting with a recently introduced standard library function; the python code was fine)
simonh 6y ago
Id be very surprised, shocked if I cant run a vanilla stdlib only Python 2.7 script on all the major platforms in 10 years time, even 20 years time.
m-p-3 6y ago
If the code isn't going to change, you could statically compile it and it will run just fine.

lenkite 6y ago

Will Lisp ever specify concurrency as part of the specification ? Standard well-supported concurrency is vital for any modern-day programming language. Without that, common LISP is relegated to the realm of gradually dying languages.

pdimitar 6y ago
Exactly the reason I dipped my toes in Racket, loved it, then went back to Elixir (and Rust). Without a good runtime / libraries to tackle concurrency and parallelism in a transparent way -- as Erlang/Elixir and other BEAM VM languages do -- the other traits of a language take a back seat.

mark_l_watson 6y ago

+1 right on. I would like to see more companies open source their commercial products after maintaining them is not cost effective. I would like to see mostly open source code, period. re: Lisps: I have been using Common Lisp since 1982 (and other Lisps before that) and I love it that my old code and archives of other peoples’ Common Lisp code usually runs with no problems.