eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Server stats:

221
active users

#literateprogramming

1 post1 participant0 posts today

#programming #systemsProgramming #software #commonLisp #sitcalc #emacs #eepitch

screwlisp.small-web.org/comple

I relate #Sandewall's call for situation calculus actions and the shared environment / database to be moved into the kernel viz my #literateProgramming emacs useage.

People always said emacs /was/ the operatingsystem, didn't they.

Particularly, computer programs various send requests for actions to the emacs server where they are also seen playing out at they actually happen in real time.

screwlisp.small-web.orgMy eepitch-send, actions and the situation calculus

@mdhughes
What were you sharing about your conversations with Knuth viz #literateProgramming or otherwise? Were you saying that it was specifically in the context of his book that web was important?

The way eev resolves repl vs literate is that you only write in your literate document, and the repl updates on the other half of the screen without your cursor entering it.

#programming #softwareEngineering article screwlisp.small-web.org/progra #commonLisp #asdf #systemsProgramming #series #pathnames #packaging

Really simple... Sort of... But so intricate to write. I deal with (writing a smidge of #interactive #lazyEvaluation #functionalProgramming ) :

- Tangling markdown into an asdf :class :package-inferred-system lisp system
- Doing so with scan-file and collect-file from series
- Working with lisp’s make-pathname directories.

screwlisp.small-web.org:screwlisps-knowledge/tangle common lisp asdf package markdown tangling and lisp pathnames
Continued thread

Some more info & illustration of the lens axis used above (excerpt from the #LiterateProgramming source code of the much older #Clojure version of thi.ng/viz)

This axis type uses circular interpolation to create the non-linear mapping:
docs.thi.ng/umbrella/math/func

There will also be an alternative/similar version using the generalized Schlick formula:
docs.thi.ng/umbrella/math/func

Source code link of the animation below:
github.com/thi-ng/geom/blob/fe

Rather than considering even just once the needs & massive benefits for creators and maintainers, current open source software infrastructure, support tools, but also developer culture itself is completely biased and optimized purely for the benefit of consumers/users. Choosing a non-standard project structure (in my case a mature Google-style monorepo with almost 200 largely independent, but related projects/libraries/tools) is increasingly actively punishing my work and efforts in a variety of ways, e.g.

- non-supportive UIs for improved browsing/overviews of monorepos
- harmed discovery via search & metadata limitations
- wrong, misleading and downgraded project ranking calculations (npm)
- misleading/broken automated project analysis (GitHub)
- lack of support by documentation tooling (TypeDoc)
- lack of support by package managers (Zig) and/or hosting platforms

All of these (and more) factors are actively hurting, disqualifying & even completely nullifying much of my time & energy spent on these projects, making my dream goal of working on open source fulltime increasingly intangible (because the above factors all have an actively downgrading effect which makes these project seem lower quality/relevance). To some extent this is purely because this work is stored in a project structure which is optimized for maintenance & automation. Technically, we're speaking about _one_ additional level of nesting. An extra subdirectory! Otherwise, not any different than a "normal" repo. Still — BOOM — confusion, inflexibility & punishment ensues! 😫😭

So many external aspects and people do not give a damn that a monorepo setup like this and the custom tooling created to automate the maintainance and cross-linking of all these ~360 packages (incl. example projects) are _the only sane way_ for me as a single person to efficiently manage & release a codebase of this magnitude.

I was aware of some misunderstandings about monorepos on purely social/human level, but never saw it coming that the more I was expanding and deepening this work, the more this structure and scope would hurt the project & my goals, because 3rd party infrastructure is just as weirded out by such a "blasphemy" as some people are...

I'd genuinely like to hear ideas what I could/should do to escape the vicious circle created by the above factors, which is a real motivation killer... I really do wonder how other maintainers (esp. would like to hear from indie devs)
handle projects & codebases of this scale without running into these issues...

Thank you for any insights!

Ps. I really seem to have a feeble for "think different" and going against the grain with these things (or maybe being too early?). The first set of 20+ thi.ng libraries for Clojure/ClojureScript were mostly written in a #LiterateProgramming format, often combining source code with diagrams & tables — this too led to many complaints and was partially to blame for not gaining much traction, even though these projects were singular offerings to that language community at the time (and funnily only became more popular _after_ 6-7 years, once I'd already left Clojure behind... go figure!)

thi.ngOpen source building blocks for computational design. Est. 2006thi.ng is a set of ~350 complementing code libraries & projects, a long-term effort devoted to Computational Design in its many forms.