#introductions Researching new ways to write software that make it easier for newcomers to understand rather than for insiders to maintain. Build easy, reward curiosity, encourage lots of forks, delete unused features, more antifragile society. http://akkartik.name/about
Current project: https://github.com/akkartik/mu
Rather than start with a desired syntax, Mu starts from the processor's instruction set and tries to get to _some_ safe and clear syntax with as few layers of translation as possible.
Distinguishing a program's return value from its side effects
https://archive.org/details/akkartik-2min-2021-04-10 (2-minute video)
Main project page: https://github.com/akkartik/mu
Okay, this is probably an even better example of their performance. I'm not an expert by any means, but dang, they all seem absolutely solid performers. Fanny playing "Blind Alley":
https://www.youtube.com/watch?v=bE3uwtegPEY
Imagine becoming a fan of a band 50 years too late. π
Just pushed to Uxn more progress in my in-Uxn assembler! Implemented so far:
β Load/store helpers
β Macro definitions
Missing are:
β Executing macros
β Literal data
β Opcodes
I'm sure you'll agree that not being able to write any actual code is a mere nitpick and I'm basically finished... #theWorkshop
Left: Lv2 Grape Hyacinth BULBLING
π± burrows deep
π· cute of flower
π» bees like me
Right: Lv40 Grape Hyacinth SORROWLORD
π mid-game boss
π inspires fear
π automatically splits into 50 bulbs as you dig it up
Distinguishing a program's return value from its side effects
https://archive.org/details/akkartik-2min-2021-04-10 (2-minute video)
Main project page: https://github.com/akkartik/mu
Mu's HLL is now Turing-complete, I think.
Things to notice:
* Wordstar-style menu at the bottom.
* List of available primitive functions in bottom left.
* List of globals on the left side that updates as I add definitions.
* Matching parens highlighted as I type.
* Drilling down into the trace to understand how the program was evaluated.
https://github.com/akkartik/mu/blob/main/shell/README.md
Main project page: https://github.com/akkartik/mu
Playing a videogame using voice
A feature of INTERCAL-72 not documented in the original manual was that it required a certain level of politesse from the programmer. If fewer than 1/5th of the program statements included the PLEASE qualifier, the program would be rejected as insufficiently polite. If more than 1/3rd of them included PLEASE, the program would be rejected as excessively polite.
I miss how old BIOS machines felt.
With UEFI, you really get the feeling there's something underneath, slightly slowing everything down and doing unnecessary things.
BIOSes just felt a lot closer to the machine, written in mostly pure assembly, minimizing code space as much as possible to save on ROM.
In, Through, and Beyond #Saturn's #Rings
#Astronomy #Picture of the Day
OMG, this comment wins the internet today.
"Reading code diffs is like examining your life as the changes that happen over time but not actually _examining_ your life. This is how you wake up one day and realize that you donβt like the person in the mirror, or that nobody else does."
https://news.ycombinator.com/item?id=26646153#26669166
Thanks @colby
@paul @akkartik great comment by dhosek on HN about code reading ("clubs") and the relationship to LP <https://news.ycombinator.com/item?id=26668822>
This (esp. "the biggest challenge is just finding a starting point") matches the lessons I've internalized over the last ~3 years. My main takeaways whether you're doing proper LP or not, is that just like a book you:
1. need to provide an obvious place to start, and
2. should write code top-down (see also <https://www.teamten.com/lawrence/programming/write-code-top-down.html>)
The #ForthBox record of design decisions is very educational: https://git.sr.ht/~vertigo/forthbox/tree/master/item/doc/adr
cc @vertigo
OK, say what you will for the logic behind the 9P protocol, but I will die on this hill.
#9P is pretty damn complex, in exactly the same sort of way that the SD protocol is complex.
There are a ton of websites talking about how awesome and simple it is; yet, precious few of these sites actually attempt to write their own implementation from scratch. Even Writing a 9P Server from Scratch relies heavily on pre-existing infrastructure.
It might be simple compared to NFS, AFS, or other distributed filesystems. But, in absolute terms, it's still damn complex.
In particular, my beefs include:
I can see the manage for clients to manage tags; but, WTF is up with Fids? Why do I have to manage them? The server is already stateful; it should be managing them for me.
Qids are useless as far as I can see. I can't tell why a client would ever want to know a Qid.
The error handling mechanism of the Twalk command is just ... bizarre. I think it's because it allows the client to determine where in the path component list the error lies. Wouldn't a simple ordinal in an Rerror message be as useful? KISS!!!
The Rerror message format is confining. It desperately needs to be redefined as follows, at the very minimum:
Rerror[1] tag[2] code[8] why[8] msg[s]
where code provides a meaningful-to-computers error code. The why field is qualified by code, and helps in diagnosing why the error occurred in the first place. (For Tripos users, these fields are equivalent to the res1 and res2 fields in an IORequest block.) msg would be as it currently is.
Implementing even the most basic version of Twalk is stupidly hard. So many details to keep straight in your head while coding its handler!
I've already written about 350 lines of 9P handling code, and it'll probably be closer to 450 to 500 lines after I've finished implementing Twalk. I haven't even come close to implementing support for read, write, open, close, stat, wstat, etc.
I have no confidence that I'm actually implementing this protocol correctly.
Very frustrating.
Barbarian Programmer.
Promiscuous dependencies are the root of all evil.