4 ms·

I want to build software that lasts, but I don't think you really can at this point. We haven't even figured out fully how we should represent a string or date

I want to build software that lasts, but I don't think you really can at this point. We haven't even figured out fully how we should represent a string or date or number in software let alone have an enduring language or ABI. I feel like I am building everything on a foundation of sand at it will need to be rebuilt every 5 years, 10 if you're lucky. I do think it will change, but it will be awhile and by then it will probably just be a few big players making software anyway, kinda like car companies.

sgillen 6y ago
> I feel like I am building everything on a foundation of sand at it will need to be rebuilt every 5 years, 10 if you're lucky. This is exactly how I feel. I'm hoping at some point, the amount of churn will decrease, the community will figure out what problems it actually needs to solve, and come up with standardizedish practices for this. Obviously not all software can fit into this mold, but a lot of it probably can. To do that I think an important part is it "move fast and break things" to figure out what works and doesn't work in practice (in practice including how to actually manage people to build your software). I do think for that to happen we need to retain more knowledge between generations, I see a lot of rediscovery and reinvention of the wheel.
cmroanirgo 6y ago
I've got the same exe running in client installs since the late 90's. It's had a tweak or two here and there, but largely unchanged. I last recompiled it about 2yrs ago and had a fresh install of it about 6 months ago. It's not the prettiest thing and could have certain upgrades in light of new security practices (eg use new encryption algos & go thru an in-depth security audit). But to the clients, it's unbeatable and there's nothing remotely close to migrate to. Unbelievably, it's a vb6 app that I never bothered porting to dotnet. Even more unbelievably, it's a port of its predecessor, written in turbo pascal. As long as I can continue to find the dev environment installer, it's good to go. So. I think s large part of the problem is that ppl don't redirect their dev environment enough to keep an install disk, (if one was available in the first place). A second large problem is that modern development relies heavily on 3rd party library use, which means your software is reliant on more than one company for your binary. So. Find an environment that you can archive/keep, and ignore the not invented here rule to a large extent
- user5994461 6y ago
  >>> I've got the same exe running in client installs since the late 90's. That's on Windows that has stable API and ABI. The 90's is probably the limit because older software are 16 bits and don't work on current 64 bits Windows. On Linux all software break with each distro release because "core" libraries are unstable. Got executable and libraries compiled on RHEL 6 and most of them fail to load on RHEL 7 because something.so not found.
  - laumars 6y ago
    You can bundle the .so files in Linux just like you would bundle .dll files in Windows. Or statically compile if you don’t want dynamic libraries. Linux and Windows isn’t really any different there aside from Windows has more in the way of novice friendly tools to create redistributables. It’s also worth noting that you’re comparing Apples to Oranges in that Visual Basic 6 is a very different language to C++. VB6 has its own warts when it comes to archiving such as it’s dependence on OCX and how they require registering for use (they can’t just exist in the file system like DLL and SO libraries, OCX required their UUIDs loaded into Windows Registry first). To further my previous point, if you wanted to use another language on Linux, maybe one that targets the OS ABIs directly (eg Go), then you might find it would live longer without needing recompiling. Contrary to your statement about user space libraries, Linux ABIs don’t break often. Or you could use a JIT language like Perl or Python. Granted you are then introducing a dependency (their runtime environment being available on the target machine) but modern Perl 5 is still backwards compatible with earlier versions of Perl 5 released in the 90s (same timescale as the VB6 example you’d given except Perl is still maintained where as VB6 is not).
    - PaulDavisThe1st 6y ago
      Linux ABIs might not break often. But GTK, Qt, libwhatever ? More often than one would like.
      - laumars 6y ago
        I’d discussed that problem in the first paragraph of my post.
nradov 6y ago
Java has been around for 25 years with no significant changes in strings or numbers, and only one major change in dates. That has been good for backwards compatibility and code bases do last. But the 16 bit string character representation doesn't work well with modern Unicode. And the number representations lack a proper type hierarchy so you can't use polymorphism in numeric algorithms.
- vbezhenar 6y ago
  > But the 16 bit string character representation doesn't work well with modern Unicode. What do you mean? UTF-16 works well with all unicode characters. Some characters are encoded by two code units, but that's true for UTF-8 as well. ASCII strings are stored using 1-byte encoding on modern JVMs. I would prefer UTF-8, but hybrid ASCII/UTF-16 string works fine too.
  - nradov 6y ago
    The problem is that the internal character encoding is fixed to UTF-16 (although some JVMs use something else internally and then present a UTF-16 facade). A lot of Java code fails to correctly handle Unicode code points that don't fit into a single char. In retrospect string representation should have been more flexible and decoupled at the API layer from the underlying encoding.
    - LoSboccacc 6y ago
      I've never had any issue for as long as every I/O had their charset properly declared, do you have done samples to share?
      - maple3142 6y ago
        Maybe reversing or splitting a Unicode string (with surrogate pairs) may be a problem in Java. I am not familiar with Java, so I am not sure.
      - nradov 6y ago

sgillen 6y ago

> I feel like I am building everything on a foundation of sand at it will need to be rebuilt every 5 years, 10 if you're lucky. This is exactly how I feel. I'm hoping at some point, the amount of churn will decrease, the community will figure out what problems it actually needs to solve, and come up with standardizedish practices for this. Obviously not all software can fit into this mold, but a lot of it probably can. To do that I think an important part is it "move fast and break things" to figure out what works and doesn't work in practice (in practice including how to actually manage people to build your software). I do think for that to happen we need to retain more knowledge between generations, I see a lot of rediscovery and reinvention of the wheel.

cmroanirgo 6y ago

I've got the same exe running in client installs since the late 90's. It's had a tweak or two here and there, but largely unchanged. I last recompiled it about 2yrs ago and had a fresh install of it about 6 months ago. It's not the prettiest thing and could have certain upgrades in light of new security practices (eg use new encryption algos & go thru an in-depth security audit). But to the clients, it's unbeatable and there's nothing remotely close to migrate to. Unbelievably, it's a vb6 app that I never bothered porting to dotnet. Even more unbelievably, it's a port of its predecessor, written in turbo pascal. As long as I can continue to find the dev environment installer, it's good to go. So. I think s large part of the problem is that ppl don't redirect their dev environment enough to keep an install disk, (if one was available in the first place). A second large problem is that modern development relies heavily on 3rd party library use, which means your software is reliant on more than one company for your binary. So. Find an environment that you can archive/keep, and ignore the not invented here rule to a large extent

user5994461 6y ago
>>> I've got the same exe running in client installs since the late 90's. That's on Windows that has stable API and ABI. The 90's is probably the limit because older software are 16 bits and don't work on current 64 bits Windows. On Linux all software break with each distro release because "core" libraries are unstable. Got executable and libraries compiled on RHEL 6 and most of them fail to load on RHEL 7 because something.so not found.
- laumars 6y ago
  You can bundle the .so files in Linux just like you would bundle .dll files in Windows. Or statically compile if you don’t want dynamic libraries. Linux and Windows isn’t really any different there aside from Windows has more in the way of novice friendly tools to create redistributables. It’s also worth noting that you’re comparing Apples to Oranges in that Visual Basic 6 is a very different language to C++. VB6 has its own warts when it comes to archiving such as it’s dependence on OCX and how they require registering for use (they can’t just exist in the file system like DLL and SO libraries, OCX required their UUIDs loaded into Windows Registry first). To further my previous point, if you wanted to use another language on Linux, maybe one that targets the OS ABIs directly (eg Go), then you might find it would live longer without needing recompiling. Contrary to your statement about user space libraries, Linux ABIs don’t break often. Or you could use a JIT language like Perl or Python. Granted you are then introducing a dependency (their runtime environment being available on the target machine) but modern Perl 5 is still backwards compatible with earlier versions of Perl 5 released in the 90s (same timescale as the VB6 example you’d given except Perl is still maintained where as VB6 is not).
  - PaulDavisThe1st 6y ago
    Linux ABIs might not break often. But GTK, Qt, libwhatever ? More often than one would like.
    - laumars 6y ago
      I’d discussed that problem in the first paragraph of my post.

nradov 6y ago

Java has been around for 25 years with no significant changes in strings or numbers, and only one major change in dates. That has been good for backwards compatibility and code bases do last. But the 16 bit string character representation doesn't work well with modern Unicode. And the number representations lack a proper type hierarchy so you can't use polymorphism in numeric algorithms.

vbezhenar 6y ago
> But the 16 bit string character representation doesn't work well with modern Unicode. What do you mean? UTF-16 works well with all unicode characters. Some characters are encoded by two code units, but that's true for UTF-8 as well. ASCII strings are stored using 1-byte encoding on modern JVMs. I would prefer UTF-8, but hybrid ASCII/UTF-16 string works fine too.
- nradov 6y ago
  The problem is that the internal character encoding is fixed to UTF-16 (although some JVMs use something else internally and then present a UTF-16 facade). A lot of Java code fails to correctly handle Unicode code points that don't fit into a single char. In retrospect string representation should have been more flexible and decoupled at the API layer from the underlying encoding.
  - LoSboccacc 6y ago
    I've never had any issue for as long as every I/O had their charset properly declared, do you have done samples to share?
    - maple3142 6y ago
      Maybe reversing or splitting a Unicode string (with surrogate pairs) may be a problem in Java. I am not familiar with Java, so I am not sure.
    - nradov 6y ago