Empiricist Old-Testament Vajrayana, battered enough by life to have grown-up some, in my nearly-6-decades, autistic geek, philosopher who finds that Western philosophers are nowhere near at the level of correct-thinking of the Vajrayana stuff, & will be tearing-into Marx, etc, for their brainos ( Marx found that capitalism alienated workers, so he replaced capitalism with communism, which somehow “didn’t” alienate workers?? I’ve already cracked the underlying error, but that is a long article. It’ll happen. & so will the dismantling of the other philosophers’ bogons, the whole lot of 'em. : )

  • 0 Posts
  • 2 Comments
Joined 1 year ago
Cake day: March 27th, 2025
  • Paragone@piefed.social
    toProgramming@programming.dev•Looking for good software architecture resources!English
    0·
    10 days ago

    This is a bit beyond architecture, but being competent to build a mathematically bug-free API is probably something that few programmers would even bother trying to compete-against…

    https://leanpub.com/algebra-driven-design

    I think there is a fundamental mis-framing, throughout the entire software/development understanding…

    I think that the architecture needs to be simultaneously agilely-devloped, but into an executable-model, a kind of toy-implimentation, so it is easy to change the architecture, low-cost, BEFORE one converts it into load-bearing, & therefore unchangeable architecture ( architecture’s the hardest thing to change, as it’s most-fundamental )

    So, I think that the proper way is to do it in 2 stages:

    1. agilely develop the architecture, until ALL required-kinds-of-function are working, in the toy-model, & one has re-architected it so that the structure is right, & then
    2. set about converting it from the high-level-language to whatever production-language it is that is efficiency-optimal, for production-scale.

    This is part of an idea from years ago: I read in a Wiley GAAP book that I happened to be glancing into, that it’s a violation of GAAP to prototype any project in any language other than the final-implimentation-language, & expense that prototype.

    Which is totally insane!

    Prototype in the highest-level-language you can, to get the domain+architecture right, then reimpliment what you have to in the most production-efficient/effective language for that project.

    GAAP ( of that year ) is categorically wrong: it penalizes optimal-prototyping.

    It was years-later before I discovered that an English mathematician ( roundish ginger, worked in Glasgow, no idea what his name was, sorry ) had studied the difference between complex projects which worked vs ones which died, & it was the visual-spacial-representation-of-the-model, & the complete-coverage executable-model which made the successes win.

    So, I just put those ideas together.

    _ /\ _

  • Paragone@piefed.social
    toProgramming@programming.dev•A Sane Directory Structure for Software ProjectsEnglish
    0·
    10 days ago

    < sigh >

    There WAS a video on yt by a Norwegian man on why OO languages push people into spreading side-effects throughout the code, whereas in Haskell, side-effects are optimally conserved to Main.hs

    I can’t find that video, now.

    He was on stage, a talk of some kind, not as formal as a university-lecture, so it was some conference, of some kind… ( in case anybody else finds it )

    I think that that principle is contradicting what the article is saying… ( skimmed the rest, I think he’s generally right, but burying side-effects seems to be wrong, from Haskell’s perspective, & I think Haskell’s right, generally. )

    _ /\ _