the future of programming is a gigantic fruit machine pipeline and running down the isle pulling each lever in turn until you win, and people endlessly sharing strategies
so we can put a skin on a database, collect metrics, and show targeted gambling adverts. can't wait
sorry i read a very bad blog post about our new agentic future and the need for better sandboxing because the guy couldn't get the computer to stop deleting the code over and over and yeah i simply haven't been kicked in the head enough for this future
call me old fashioned but i don't really think the future of programming is per-request billing to defence contractors set on destroying the internet
or at least, a future we should aspire to
the thing about saying "one day they'll learn" is that the reason we have stories like "the hare and the tortoise" is that people don't
no-one loses on a scratch card once and thinks "i should stop here"
we have a whole "you lose 100% of the scratchcards you don't buy" mentality here
if people learned from consequence the world would be a much nicer place
like i have seen two blog posts about harnesses and at best it seems like people trying to paper over the cracks, a tacit admission that the tools cannot work without strict guidance, but the unkind reading is a gambler battling probability
the problem is, being heavily stochastic, it's really easy to trick yourself into believing that your nudges will work every time, or they have impact, or combine independently, and build superstitions
the code doesn't have to work every time, so
it's funny how i got told "you will be left behind" and as it turns out the skill you need to develop is simply spending more tokens when any problems occur
code not good? add more agents. spend more tokens
code still not good? stuff things in context window. call it a skill. spend more tokens
code still bad? break down the problem, spoonfeed computer line by line until code good, pretending you haven't been tricked tom sawyer style into doing the work and spending more tokens as a result
can't believe they've enshittified programming, thought we were a bit further down the list given the progress on other fronts
"why did you get into computers, tef?"
mostly by accident. i was more interested in mathematics as a teen, and ended up doing computer stuff at school as it was easy and let me avoid writing prose
"how did that work out, tef?"
well, my code never went anywhere, but my prose about code went viral a few times, and now my whole career is turning into writing prose for no-one to read, to build code no-one understands, so it's going well thanks for asking
of immediate fascination to me in that article is a single line:
"Originally I programmed in Rascal, a language developed at Reed College which was sort of a cross between C and Pascal."
Rascal turns out to be short for "Real-Time Pascal" - an entire software development kit programmed by Richard Crandall, Scott Gillespie and Greg Stein. there is very, very little known about it - aside from a handful of games (like Billiard Parlour - screenshot attached) and applications written with it in the mid 80s. it was sold by MetaResearch of portland OR in the 80s, and then completely disappeared.
worse, a copy of the (interpreter?) compiler/sdk/ide has never surfaced. reed college apparently has copies of it in its special collections! sadly, i'm nowhere near reed college.
the finding aid page is fascinating:
https://archivesspace.reed.edu/repositories/2/resources/41
a deep search of discmaster turned up exactly one artifact which was interesting: the world's only surviving Rascal source code! it at least gives us a peek at what programming in Rascal was like.
https://discmaster.textfiles.com/view/14165/MacTech-vol-1-12.toast/Source/MacTech®%20Magazine/Volume%2002%20-%201986/02.08%20Aug%2086.sit/02.08%20Aug%2086/pascal/Rascal%20source/KeyboardSleuth.src
(* Include files and constants *)
(*$U+*) (* Turn on full Uses *)
Uses __Windows, __QuickDraw,uToolIntf,uOSIntf,uPackIntf,__PackTraps;
Link __NoSysCall,__PackTraps; (* Make small stand-alone application *)
(* This is to Rascal procedure _EVENT what the first parameter
of GetNextEvent is to other languages
*)
EventMask 10; (* mouseDown(2) + keyDown(8) *)
CONST
Key1Trans = $29E; (* Low Memory Globals *)
Key2Trans = $2A2;
EOL = 13; (* end of line file delimiter (RETURN) *)
(********************************* ASCII values **************************)
Space = $20; (* *)
(* The following are Key #10, where US,UK "/" is (key # differs in US)
*)
Slash = $2F; (* / UK *)
Minus = $2D; (* - German, Spanish, Swedish *)
Equals = $3D; (* = French *)
Ograve = $98; (* Italian *)
Eaigu = $8E; (* French Canadian *)
"is this an industry term?" someone asks on a thread but the answer "alas all ETL pipelines are built from first principles and invent their own names for things, like a tower of babel"
the tldr is
- a treap is a random binary tree where every key has a rank attached
- you can cut a treap into disjoint subsets
- one type is to break it up by into parent/child (mst, btreap)
- another type is to break up into siblings (prolly)
- these are compatible approaches
- varying rank can control tree height
- varying how parent/child break up controls total number of nodes
- and varying sibling breaks can control node size
in no-one but me cares news, i worked out a way to express the different approaches in a far more general form and realised how to combine things to get the properties i want
i'm too smart to be gamified says man pouring money into computer
can't remember the source of the quote but it felt pretty bell labs and it went something like "i opened up x11 and all i found was code copying things between structs, over and over"
Hohokum is
1) still one of the best chill out games made in the past twenty years, maybe ever
2) absolutely gorgeous to look at and listen to
3) less than three quid on the Steams for a couple more weeks.
thank you to everyone who has read my posts and tried to explain them back to me in their own words, at least you're not linking to wiki, but, also
the question i've been asking myself is this: if you picked n nodes from a tree uniformly, and used them to break up the tree into some number of subtrees
what selection method would give the best (b-tree shaped) results:
- pick a random node, all children are subnodes
- give each node a random color and combine nodes of the same
methods based on counting or existing tree shape would work too, but i want something history independent, or insertion order doesn't matter
i'm currently working out the practicalities of "how do i split a binary tree into smaller subtrees"
ideally it would be into a very low height tree with nodes approximately the same size, but practically speaking, any division of the tree will improve matters
with a skip-tree/merkle search tree, you end up with a very bottom heavy tree, with high fan out, but you can bound the height to encourage more branching earlier on
which is what i'd like to improve upon
hell used to be other people
someone has told me to uninstall windows and it's "i have been using linux since 1996, i have seen horrors beyond your comprehension" like xmodelines and ndiswrapper, i have served my time