Login
You're viewing the mastodon.coffee public feed.
  • arclightarclight@oldbytes.space
    Aug 19, 2026, 4:51 AM

    Well, my recovery of TACT3 is broken and I'm not sure it's worth attempting to fix. On the upside it does seem to read and echo the main scenario input correctly. The problem is in the radioactive decay chains. Only one of about a dozen seems to be read in correctly. Maybe that can be isolated to the preprocessor and inventory library reader. However I had to hack on most of the math routines because of stupid F66 array dimensioning issues.

    Most of the problem is due to not having any usable test cases until now. I need to rethink whether this project is worth continuing or if possibly I need to revert the whole repo to square one and see if I can get the tests running with the minimally recovered code (or the original DOS executable under DOSBOX or Wine).

    Demoralizing. Maybe I can salvage the input processor and figure out how to replace the ancient LINPACK/EISPACK routines. That needs to happen anyway. Or I could just punt and try reimplementing in Python. That's a waste of time because I'd be debugging new code with no pedigree and at the end I'd have yet another undeployable unmaintainable urine-soaked bag of parts just like every other Python application I build. None of them survive the passage of time and instability of the Python ecosystem. The big selling point of keeping the code in Fortran is that you get a single easily deployable binary that can be reliably regenerated for the forseeable future - it's basically bulletproof for software lifecycle management. I'm confident the code will compile and run in 5 days, 5 weeks, 5 months, or 5 years. I have zero faith Python code will properly rebuild a month from now.

    FWIW, last week's trip to Albuquerque was to look at the dev and release process for a very large Fortran code that's been under continuous development since the mid-1980s. It's in pretty decent shape, far better than most codes I work with. Their release process is mature and sensible (GitLab + CI pipelines for Mac, Windows, and Linux). I just wish the other codes owned by the regulator were anywhere near the quality of this code.

    💬 1🔄 0⭐ 0

Replies

  • AI6YR Benai6yr@m.ai6yr.org
    Aug 19, 2026, 4:56 AM

    @arclight Good point on FORTRAN being able to continue running forever. Python definitely is not a "write once and never touch it again" language, sadly. Very handy for quick stuff, but it (like most modern languages) is extremely dependent on libraries people have written not changing at someone's random whim.

    💬 2🔄 0⭐ 0
  • ☮ ♥ ♬ 🧑‍💻peterrenshaw@ioc.exchange
    Aug 19, 2026, 4:59 AM

    @ai6yr Python and strings.

    Fortran was designed for number crunching (FORMula TRANslation) and does it well. Python with it’s numerous string libraries, non typed 😝 works but you can get into trouble quickly.
    nu@arclight@oldbytes.space

    💬 0🔄 0⭐ 1
  • arclightarclight@oldbytes.space
    Aug 19, 2026, 5:16 AM

    @ai6yr Python is useful for disposable prototypes. Even sticking with the standard library, you're at the mercy of Python's build and packaging infrastructure. That more than anything else torches a project. You follow best practices to define your project with pyproject.toml and week to week tool authors add new conflicting standards and deprecate standards without providing replacements or a migration path. Too much critical build and packaging and software engineering infrastructure is outside core Python and there's seemingly no coordination between tool authors to avoid breaking changes. It's intractable chaos and it's made the language basically useless to me.

    💬 0🔄 0⭐ 0