Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Rot and Classes of Rot Resistance

github.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Software Rot and Classes of Rot Resistance

#21

Post by martinfjohansen »

tluyben2 wrote: post #20
maxxxxx wrote: post #9

Is that just a commercial for this progsbase thing? I certainly like the assertion that that code won't rot for "centuries". Maybe a fizzbuzz implementation will survive this but even there I have my doubts.

There is already Haxe which is free and compiles to a lot of things.

As I explained in another response, progsbase is very different from Haxe. Haxe is an independent language. If you use Haxe, then you depend on the Haxe compiler. Progsbase is completely in other languages, meaning the progsbase tools are only support tools which gives you certain benefits such as being able to translate. You code remains pure Java which you develop with Java tools.

Re: Software Rot and Classes of Rot Resistance

#22

Post by martinfjohansen »

slededit wrote: post #16
martinfjohansen wrote: post #13

Earlier quoted context omitted.

The removed instructions were binary-coded-decimal instructions, push / pop of CS/DS/ES/SS. These are minor instructions, but if your program used them, that alone means it no longer works, and that was the point.

BCD instructions are slower than emulating them with more traditional operations and were rarely used in 32-bit software (16-bit is a different story). Most people would recompile their software and never experience this as an issue. The removal of the segment registers was the only one that really reduced capabilities - VMWare's original solution became impossible because of that. However they were replaced by hyper…

The WMWare example is very interesting!

Let me just note that the article does not propose a solution to VMWare's problem. It only notes that when instructions are removed, code using it stops working.

Re: Software Rot and Classes of Rot Resistance

#23

Post by slededit »

martinfjohansen wrote: post #22
slededit wrote: post #16

Earlier quoted context omitted.

BCD instructions are slower than emulating them with more traditional operations and were rarely used in 32-bit software (16-bit is a different story). Most people would recompile their software and never experience this as an issue. The removal of the segment registers was the only one that really reduced capabilities - VMWare's original solution became impossible because of that. However they were replaced by hyper…

The WMWare example is very interesting! Let me just note that the article does not propose a solution to VMWare's problem. It only notes that when instructions are removed, code using it stops working.

Instructions were never removed from 32-bit mode though. You can run your 32-bit programs the same as before, even on today's most modern processor. You just won't get any of that 64-bit goodness.

Re: Software Rot and Classes of Rot Resistance

#24

Post by tluyben2 »

quintiles wrote: post #4

Software dependencies really are the worst part of programming. It's probably the root cause og 75% of developer burnout, with the remaining 25% split between path resolution errors(relative or absolute, training slash or not?) off-by-one array index errors, nulls and simple typographical errors that cause the loss of hours of compiler time. This is very common! Common, but still total bullshit. It's THE barrier that…

> Software dependencies really are the worst part of programming

and yet we are making it worse instead of better and most people here tend to find that a good plan.

Re: Software Rot and Classes of Rot Resistance

#25

Post by tluyben2 »

martinfjohansen wrote: post #21
tluyben2 wrote: post #20

Earlier quoted context omitted.

There is already Haxe which is free and compiles to a lot of things.

As I explained in another response, progsbase is very different from Haxe. Haxe is an independent language. If you use Haxe, then you depend on the Haxe compiler. Progsbase is completely in other languages, meaning the progsbase tools are only support tools which gives you certain benefits such as being able to translate. You code remains pure Java which you develop with Java tools.

You would still need the compiler to be written in progsbase too: is it? As I am not quite sure (and you cannot gamble on it) that Java and Java tooling is still there in 100 years. Which then brings you back to Haxe ; kind of the same gamble there but that is open source which makes it longer lived generally anyway.

A language for the ages would be a Forth imho; you can write the language on the back of a beermath and it takes mere hours to implement on whatever system.

Re: Software Rot and Classes of Rot Resistance

#26

Post by martinfjohansen »

tluyben2 wrote: post #25
martinfjohansen wrote: post #21

Earlier quoted context omitted.

As I explained in another response, progsbase is very different from Haxe. Haxe is an independent language. If you use Haxe, then you depend on the Haxe compiler. Progsbase is completely in other languages, meaning the progsbase tools are only support tools which gives you certain benefits such as being able to translate. You code remains pure Java which you develop with Java tools.

You would still need the compiler to be written in progsbase too: is it? As I am not quite sure (and you cannot gamble on it) that Java and Java tooling is still there in 100 years. Which then brings you back to Haxe ; kind of the same gamble there but that is open source which makes it longer lived generally anyway. A language for the ages would be a Forth imho; you can write the language on the back of a beermath a…

> You would still need the compiler to be written in progsbase too: is it?

Currently no, but the progsbase language is very simple and contains only well-known constructs. So creating a compiler is very simple, it would take only a few days. This is like the point you make about forth, except forth contains less well known constucts.

> open source

The progsbase specification is also open: https://docs.progsbase.com/

Re: Software Rot and Classes of Rot Resistance

#27

Post by quintiles »

tluyben2 wrote: post #24
quintiles wrote: post #4

Software dependencies really are the worst part of programming. It's probably the root cause og 75% of developer burnout, with the remaining 25% split between path resolution errors(relative or absolute, training slash or not?) off-by-one array index errors, nulls and simple typographical errors that cause the loss of hours of compiler time. This is very common! Common, but still total bullshit. It's THE barrier that…

> Software dependencies really are the worst part of programming and yet we are making it worse instead of better and most people here tend to find that a good plan.

The idea points back to whether or not it’s okay to roll your own encryption. Take the most complicated thing, and then apply the principles for that thing to all other things.

Secure encryption is hard, so use a library. Parsing a web request is hard, so use a library. Disk I/O is hard, so use a library. Graphics is hard, so use a library. Caching is hard, so use a library. Databases are hard, so use a library. Authentication is hard, so use a library. UI/UX is hard, so use a library. A11Y is hard, so use a library. And so on.

Post reply on HN