2024-04-09 01:22:35 <KipIngram   > I love the sort of cleverness they had to deply back then to get things done.
2024-04-09 01:22:44 <KipIngram   > Very "where there's a will, there's a way."
2024-04-09 01:24:52 <HappyEclipseDay> some would say clever thinkers, clever doers, are long gone.
2024-04-09 01:28:46 <KipIngram   > I think there's definitely been a tendency in that direction.  There's less NEED to be clever - we're largely able to just throw resources at things these days.
2024-04-09 01:29:28 <Al2O3       > KISS is kinda a dead idea.
2024-04-09 01:30:12 <KipIngram   > Yeah, and one fallout from that is that we can't seem to create a secure bug free system to save our lives.
2024-04-09 01:30:28 <KipIngram   > It's just taken for granted, as a cultural norm, that there "will always be bugs."
2024-04-09 01:30:46 <KipIngram   > And so we've institutionalized a whole infrastructure for tracking and processing them.
2024-04-09 01:31:01 <Al2O3       > I'm confident that today's programmers and designers when 'squishing a bug', create N* more.
2024-04-09 01:31:20 <Al2O3       > so its sadly a really ugly spiral into abyss
2024-04-09 01:31:21 <KipIngram   > Imagine if, say, the passenger plane industry had the quality record that the software industry has.
2024-04-09 01:31:45 <Al2O3       > its pretty much an old saying, automotive would be out of business all the same.
2024-04-09 01:31:54 <Al2O3       > yet, user error :)
2024-04-09 01:32:04 <Al2O3       > its amazing planes don't just fall out of the sky all the time.
2024-04-09 01:32:08 <Al2O3       > oh wait, they do now, kinda.
2024-04-09 01:32:10 <Al2O3       > Boeing!
2024-04-09 01:32:19 <KipIngram   > At least pieces of them do.
2024-04-09 01:32:27 <Al2O3       > yah, and people, and complete planes
2024-04-09 01:32:28 <thrig       > that's more due to MBA cost savings kicking the engineers and regulators out
2024-04-09 01:33:03 <KipIngram   > And you can almost count on the quality of a successful product going down over time, as those bean counters do that squeezing.
2024-04-09 01:33:17 <KipIngram   > Even when that quality was part of what made it successful to start with.
2024-04-09 01:33:18 <Al2O3       > https://news.ycombinator.com/item?id=25677848
2024-04-09 01:33:28 <Al2O3       > maybe broken code is thrig :)
2024-04-09 01:33:58 <Al2O3       > and then...  "Take a look at Apple’s functional organizational structure for an example of an engineering company done right. "
2024-04-09 01:34:01 <Al2O3       > now that is hillarious.
2024-04-09 01:34:17 <thrig       > naw, Apple wrote some SSL bug where they got the indentation wrong in C
2024-04-09 01:34:30 <thrig       > (where was the code review? analysis? auto-indent? etc)
2024-04-09 01:34:40 <Al2O3       > where is the ghost of steve?
2024-04-09 01:34:50 <Al2O3       > lurking around in the closet of Mr. Crook
2024-04-09 01:34:54 <Al2O3       > Jim Crook that is.
2024-04-09 01:35:04 <Al2O3       > agent double OO sleven for the chinese.
2024-04-09 01:35:28 <Al2O3       > but yes, on the topic of a complicated product company like boeing, it is lost now.
2024-04-09 01:35:47 <Al2O3       > a bus manufacture is something special, but gravity is not a big deal in making buses.
2024-04-09 01:35:57 <Al2O3       > neither is driving at 50-80 mph, vs 400+
2024-04-09 01:36:37 <Al2O3       > Friends, family, and others I know worked for Boeing, 'back in the day', its a shade of zero from what it was as a bright engineering company.
2024-04-09 04:05:26 <KipIngram   > ^ "Where was the ghost of Steve?"  Exactly.  Jobs sounded like a pretty big jerk in a lot of ways, but he did somehow have his finger on the customer pulse.
2024-04-09 04:05:51 <KipIngram   > Apple really did seem to have something special going on while he was at the helm.  Now it just seems like another big corporation.
2024-04-09 04:06:14 <thrig       > Woz was the hacker
2024-04-09 04:06:41 <KipIngram   > Yeah - I always figured Jobs was more the "marketer."
2024-04-09 04:12:11 <Al2O3       > jobs hacked, but not very well.
2024-04-09 04:12:19 <Al2O3       > woz was the engineer.
2024-04-09 04:12:31 <Al2O3       > both steves had a purpose, both did well, one more than the other.
2024-04-09 04:12:45 <Al2O3       > one is dead, leaving billions to be abused, and the other is quite joyous and happy.
2024-04-09 04:13:27 <Al2O3       > I now call the company I used to love, work for, and worship, Crapple.
2024-04-09 04:15:57 <Al2O3       > and the last OSX installation I performed was June 23, 2011, Snow Shitty, and as most appreciate might be the last post Crapsodomy release that mattered.  :)   It runs all kinds of forths, CLI mostly and does them well.
2024-04-09 04:17:02 <Al2O3       > may the forth be with ya
2024-04-09 04:18:57 <coyote      > i feel like the last macOS release I accepted (not liked, just begrudgingly accepted) was High Sierra
2024-04-09 04:19:57 <coyote      > as someone who deals with audio stuff a lot macOS was nice but since that point it just went downhill. it's no surprise that a lot of audio software still supports High Sierra because an incredible amount of the software out there that's still depended by professionals is 32-bit
2024-04-09 04:20:08 <coyote      > somehow Windows doesn't look that bad after that. :S
2024-04-09 04:20:48 <Al2O3       > I wish, upon a star, that something like QNX or BeOS would get traction.
2024-04-09 04:21:23 <Al2O3       > if it did, the underpinnings of great software and real time work would mature and emerge to show the past 30 years has literally be a race to the abyss.
2024-04-09 04:22:13 <Al2O3       > but, Gates, the SJB (steve jobs bukkake experience) have somehow pinned a divided culture of smart people against each other, and now we have a lowest common denominator and dropping.
2024-04-09 04:27:56 <coyote      > i just want more audio software to support linux ;-:. at least Renoise does, but it means I have to forget years of using another software to be able to switch to fully Linux
2024-04-09 04:31:24 <Al2O3       > it also means you have to pay, or suffer fun-conjuction-ality as well to get a paycheck or other tools so obscure and open sourced you would have to search and destroy (aka, do a job)
2024-04-09 04:32:04 <Al2O3       > fundamentally, most things have been written, sometimes better in the OS space, but folks simply don't believe they have time to do due diligence and know and own their domain as users.
2024-04-09 04:32:36 <Al2O3       > we are a society of being hand fed, search engines like wikipedia, like thesaurus like encyclopedias have made this all possible.
2024-04-09 04:32:51 <Al2O3       > and so the spiral continues :)
2024-04-09 05:02:06 <KipIngram   > Oh - Crapple.  That's good.
2024-04-09 05:03:01 <Al2O3       > remember, I coined it maybe 20 years ago, and I also came up with Steve Jobs Bukkake...  that which you get when you fall into love with a messiah.
2024-04-09 05:03:27 <KipIngram   > coyote: I want more anything to support Linux.
2024-04-09 05:04:17 <Al2O3       > I don't hate linux, or linus, or stallman, but they have single handed-ly done more to stall OS than help it.
2024-04-09 05:04:46 <Al2O3       > open source was great concept, from the start of software itself.  Then they branded it, and controlled it too much.
2024-04-09 05:04:49 <KipIngram   > I just think of it as the least bad option.  And one that I can, at least in theory, climb inside if I need to.
2024-04-09 05:05:06 <coyote      > 
ACTION nods

2024-04-09 05:08:11 <KipIngram   > So my DM42 started freezing up on me here and there a couple of days ago.  I updated the firware this afternoon, but that didn't really help.  Turned out it was just the battery getting low.  I somehow thought the thing used a rechargeable battery, and I'd had it plugged in to a USB port enough for that to be topped off.  It's a couple of years old, so I thought maybe that cell needed replacing.  When I got
2024-04-09 05:08:12 <KipIngram   > inside it it turns out it just runs on a CR2032 coin cell.  So yes, it did need replacing, but not in the way I thought.
2024-04-09 05:08:20 <KipIngram   > Popped a new one in and it's totally fine now.
2024-04-09 05:08:37 <coyote      > I have the same calculator :-)
2024-04-09 05:08:56 <coyote      > I had something similar happen to me, but it'd also just randomly shut down.
2024-04-09 05:09:04 <KipIngram   > I love it.  I used an HP-41CV in college, and this seems to be the best RPN option around.
2024-04-09 05:09:52 <KipIngram   > And it's got crazy precision.  More than I can really imagine anyone needing.
2024-04-09 05:10:02 <coyote      > I think it doesn't use the battery if it's plugged in to an USB port, or at least I've been led to believe that
2024-04-09 05:10:22 <coyote      > (since it also runs faster when plugged in)
2024-04-09 05:10:31 <KipIngram   > It at least doesn't need it - I plugged it in while I changed the battery and all the RAM stayed put.
2024-04-09 05:10:47 <coyote      > 
ACTION nods

2024-04-09 05:10:49 <KipIngram   > It's nice how easy it is to open up.
2024-04-09 05:11:00 <coyote      > I had to replace the battery like a year ago and I was delighted with how easy it was
2024-04-09 05:11:09 <KipIngram   > Yep.
2024-04-09 05:11:38 <KipIngram   > One of the reasons I thought it was rechargeable was because I've had it for years and it was still going strong.  Man, that was a long time for one coin cell.
2024-04-09 05:12:17 <coyote      > Mine ran out weirdly fast, but I think it was my fault while experimenting with writing my own firmware for it
2024-04-09 05:12:41 <KipIngram   > I want to try that.  It being an open platform encouraged me to buy it.
2024-04-09 05:12:48 <coyote      > weirdly last for the cell that came with it*
2024-04-09 05:13:03 <KipIngram   > This next Forth I want to write would work well for a platform like that.
2024-04-09 05:13:13 <coyote      > It's fun, the API can be a bit weird in some parts but you get used to it haha
2024-04-09 05:13:32 <KipIngram   > I'm expecting it to be very very compact, and that's nice for the calculator's somewhat limited memory.
2024-04-09 05:13:44 <coyote      > Like the fact that there's only one file descriptor for the entire system, so if you have something open and call some OS function that needs to open a file it'll clobber the file descriptor had open
2024-04-09 05:13:58 <KipIngram   > I also like how you can have several programs on it and choose which one you want to boot.
2024-04-09 05:14:07 <coyote      > I found out the hard way when I was taking screenshots of some test cases I was running and wondering why my script wouldn't continue running
2024-04-09 05:14:16 <KipIngram   > I haven't run anything yet other than the stock stuff, though.
2024-04-09 05:14:39 <coyote      > Right now I only run the stock stuff, I guess it's better to have a calculator that works than a toy :-)
2024-04-09 05:15:04 <KipIngram   > Yeah.  For a long time I hardly used a calculator, but I've been using it a bit more lately.
2024-04-09 05:15:20 <KipIngram   > Haven't really done much proramming yet, though.
2024-04-09 05:15:42 <KipIngram   > I did a LOT of programming on the CV.  It was actually the first programmable platform I ever had, so I kind of learned to program using it.
2024-04-09 05:15:46 <coyote      > I really want to sit and learn how to write programs for it at some point
2024-04-09 05:15:49 <KipIngram   > So it's no wonder I like Forth.
2024-04-09 05:16:23 <coyote      > My dad used to have an HP-48G which was the one that sparked my love for calculators
2024-04-09 05:16:30 <KipIngram   > It looks similar enough to the 41C famiy that I don't expect I'll have much trouble.  It's been a while, but that stuff is pretty drilled into me.
2024-04-09 05:17:16 <KipIngram   > That's my wife's calculator.  That HP-41C --> HP-41G is pretty close to our age difference, so it makes sense.
2024-04-09 05:17:31 <thrig       > I had a 48g back in college, used it for maff and geology stuff
2024-04-09 05:17:57 <KipIngram   > It can do a ton mine couldn't.
2024-04-09 05:18:27 <KipIngram   > I've actually never used a graphing calculator.
2024-04-09 05:19:28 <KipIngram   > Though I wrote a program for my 41-CV that "emulated" Smith chart calculations.  Couldn't see the graph - I had to imagine it.  But it still was a nice fit for problems that expected us to use the chart.
2024-04-09 05:20:20 <KipIngram   > My favorite program, though, was a setup that did Gaussian elimination on complex matrices.   The calculator didn't support complex numbers natiely - that was part of the program.
2024-04-09 05:20:31 <KipIngram   > That comes up in solving AC circuits.
2024-04-09 05:21:50 <KipIngram   > I could just look at a schematic of a circuit and calculate and enter the input on the fly - no scratch paper or anything - and run it and it whould chug for a while and then spit out all the steady state voltages and currents.
2024-04-09 05:24:21 <KipIngram   > coyote: You ever run across a book called "Algorithms for RPN Calculators," by a guy named Ball?
2024-04-09 05:33:32 <MrMobius    > Ya, DM-42 runs off USB power when you plug it in
2024-04-09 05:33:50 <MrMobius    > the amazing battery life comes from the screen which only needs power when it changes
2024-04-09 05:38:20 <KipIngram   > Yeah, something akin to eink.
2024-04-09 15:14:37 <KipIngram   > https://www.youtube.com/watch?v=6htbyY3rH1w
2024-04-09 15:30:07 <KipIngram   > This feels like black magic - very innovative.
2024-04-09 15:31:41 <KipIngram   > It looks like it's tantamount to "compressing" your input data with a slightly lossy compression method - you no longer get the exact answer, but you can control the inexactness - the more you will accept, the bigger the speed-up.
2024-04-09 15:32:08 <KipIngram   > So it's like a compression algorithm with the goal of reducing computational effort in the actual numerical processing.
2024-04-09 15:33:01 <KipIngram   > Since most machine learning data is noisy anyway, computing with exactness isn't REALLY buying you much anyway.
2024-04-09 16:33:52 <veltas      > Talking about quality software, I do somehow think Forth fits into that puzzle somewhere
2024-04-09 16:35:43 <user51      > How would you define quality?
2024-04-09 16:35:52 <veltas      > I had a nightmare that convinced me to take memory safe languages more seriously but to be fair, there's no reason you can't make a memory-safe layer in forth
2024-04-09 16:36:19 <veltas      > Sorry that wasn't directed at your question
2024-04-09 16:36:59 <user51      > I'm just taking a break, maybe half an hour.
2024-04-09 16:37:41 <veltas      > I mean quality is subjective but I'd say inexpensive to run and maintain, inexpensive to develop, not riddled with bugs
2024-04-09 16:38:21 <veltas      > And you can do that sometimes applying KISS, and taking advantage of good features of languages available to you
2024-04-09 16:38:33 <veltas      > Thinking about design a little, using iterative development
2024-04-09 16:38:58 <user51      > As far as quality software is concerned.. my first thought is that programmers might have a different metric than regular users.
2024-04-09 16:39:37 <veltas      > I think the usability by groups either is or isn't a requirement, so can be factored into my description
2024-04-09 16:40:23 <veltas      > I think software must achieve its requirements, but selection and scrutiny of requirements is important as well
2024-04-09 16:41:18 <veltas      > Iterative development helps refine requirements sometimes
2024-04-09 16:41:39 <user51      > That's for personal or commercial software?
2024-04-09 16:41:50 <veltas      > Either
2024-04-09 16:43:31 <user51      > Well, would you consider UNIX, with the shell and the standard utilities qualifying as quality software?
2024-04-09 16:43:45 <veltas      > Yes, especially the original
2024-04-09 16:43:59 <user51      > Geez, I was hoping for a no :P
2024-04-09 16:44:00 <veltas      > These days it's more archaic, we could probably do better but it's useful to keep the historical idea
2024-04-09 16:44:12 <veltas      > UNIX was very iterative in its development
2024-04-09 16:44:45 <user51      > Wait, the conversation is about development?  I was thinking about the end result.
2024-04-09 16:45:33 <veltas      > Well rather than just saying "software sucks" I'm trying to help describe how to achieve quality nonetheless
2024-04-09 16:45:43 <veltas      > And part of that is development methodology
2024-04-09 16:51:58 <user51      > veltas: I haven't read it but maybe you'll like it https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201
2024-04-09 16:54:10 <GeDaMo      > "The server chose violence" https://cliffle.com/blog/hubris-reply-fault/
2024-04-09 16:54:11 <GeDaMo      > "On Hubris, if you break a system call’s preconditions, your task is immediately destroyed with no opportunity to do anything else."
2024-04-09 16:59:47 <veltas      > Task destroyed, program and data purged, programmer fined
2024-04-09 17:01:24 <veltas      > GeDaMo: That really sounds like the wrong level to apply that logic
2024-04-09 17:03:02 <veltas      > The issue is that on a normal kernel it refuses to action malformed requests as well, but the exception is raised in software as an error code or interrupt or something.  Here it's reported to the parent task that the child was killed, so I need two tasks to handle errors in any robust software.  I'd rather have a language with features to help obey the rules, rather than a trigger happy OS or server
2024-04-09 17:04:16 <veltas      > Also they say there's no way to fix the task, but presuming you can debug and read a dump .... you *can* recover the task, automatically even, using a program additional to the base OS.
2024-04-09 17:04:22 <GeDaMo      > But now your tasks don't need as much error handling because they won't have to deal with errors
2024-04-09 17:04:42 <veltas      > Yes but now every program needs more than one task, with some IPC mechanism in charge of that work
2024-04-09 17:04:48 <GeDaMo      > It reminds me of https://en.wikipedia.org/wiki/Crash-only_software
2024-04-09 17:04:49 <veltas      > Every program that's robust, anyway
2024-04-09 17:07:48 <veltas      > This is a problem I do have with the UNIX philosophy today is that it's bloated
2024-04-09 17:09:40 <GeDaMo      > It feels like all software is bloated :/
2024-04-09 17:10:39 <veltas      > I compare with e.g. an embedded controller using something like coroutines and interrupts to handle I/O.  Performant, very low resources, one stack, one copy of .data in RAM, etc
2024-04-09 17:11:07 <veltas      > Is it that much harder than e.g. high-level pipes or sockets?  I would say no.
2024-04-09 17:11:18 <GeDaMo      > That Hubris system is for building embedded systems
2024-04-09 17:13:04 <veltas      > Yes but with e.g. preemptive multitasking, so it's bloated really
2024-04-09 17:15:53 <veltas      > Because then you've got multiple stacks, if you've got like 64K of RAM or less, typical for MCU's, then that's a huge hit on resources.  Or you have tiny stacks, well that isn't great for stability.
2024-04-09 17:16:06 <veltas      > I'm assuming their 'embedded' isn't the same kind I'm used to
2024-04-09 17:17:34 <veltas      > Operating systems are definitely bloat for MCU's, people put them on there and then think "oh we're out of memory, need a bigger chip".
2024-04-09 17:17:51 <veltas      > Meanwhile people who didn't use the OS have simpler software than runs better and doesn't need a more expensive chip
2024-04-09 17:17:57 <veltas      > that* runs
2024-04-09 17:21:12 <veltas      > I mean race conditions are much easier to avoid without preemptive multitasking right?
2024-04-09 17:24:43 <veltas      > I want to write a little on embedded design at some point because I don't want to just sound arrogant, I do think people who move to embedded OS's are missing a trick.
2024-04-09 17:32:28 <veltas      > I do think the basic layout of programs of e.g. a "main function", something that has a finite duration, is quite flawed
2024-04-09 17:34:04 <veltas      > win32 is closer to the right sort of model with the window procedure, the callback that gets called as each event occurs, this fits long-lived programs better IMO
2024-04-09 17:34:39 <GeDaMo      > A live system more like e.g. SmallTalk?
2024-04-09 17:34:39 <coyote      > KipIngram: I haven't come across that book
2024-04-09 17:35:20 <coyote      > I'll download it for later
2024-04-09 17:42:47 <KipIngram   > I've got a copy upstairs; bought it on eBay a couple of years ago, because I remembered enjoying it in college.
2024-04-09 17:43:07 <KipIngram   > It's nothing particularly profound - I got it mostly for sentimental reasons.  Has some neat astronomy algorithms in it.
2024-04-09 17:48:38 <veltas      > GeDaMo: I don't think that's what I mean.  I just mean that a long-lived program on a small system should have just an 'init' function and 'proc' function, and shouldn't have its own stack really
2024-04-09 17:49:02 <veltas      > Just call them from main thread when needed
2024-04-09 17:58:03 <veltas      > And then for KISS sake I wonder if we benefit from changing from this init/proc model at a larger scale
2024-04-09 17:58:15 <veltas      > I don't think so, I think we've just overcomplicated things
2024-04-09 18:51:19 <KipIngram   > The way I've thought about it, every thread will have a stack, but not necessarily the rigging necessary to do console I/O.  Also won't necessarily have the ability to compile new things to the dictionary.  All of those will be "tiers" of capability that build up.
2024-04-09 18:51:55 <KipIngram   > So the very simplest thread could have just a tiny stack and the necessary storage (there in the same RAM region as its stack) to store off its registers when it's not running.
2024-04-09 18:52:05 <KipIngram   > I.e., a "green thread" in the Erlang sense.
2024-04-09 18:52:10 <KipIngram   > As minimal as possible.
2024-04-09 18:52:44 <KipIngram   > It's hard for me to see how a Forth thread could not have stacks.
2024-04-09 18:53:11 <KipIngram   > I'm hoping that such threads could consume no more than a few hundred bytes of RAM.
2024-04-09 18:54:57 <KipIngram   > I'll probably want all threads, even the small ones, to have at least the ability to communicate messaes with other processes.
2024-04-09 18:55:39 <KipIngram   > I imagine the interactions among threads in the way Pike described his "communicating synchronous processes."
2024-04-09 19:06:00 <KipIngram   > I suppose you could imagine a Forth thread that was a single word of all primitives - that wouldn't need a return stack, in theory.
2024-04-09 19:06:13 <KipIngram   > But it's hard to see how to do without a data stack in any case at all.
2024-04-09 19:55:44 <koisoke     > if your dictionary is a list (with a(n optional) hash table for convenience) and your context has a pointer to the head of the dictionary, then each thread can just cons onto the dictionary invisibly to other threads
2024-04-09 19:56:18 <koisoke     > gets a big more complex if you want to merge those at some point ofc
2024-04-09 20:44:22 <veltas      > KipIngram: That model you're describing is similar to polyforth I think
2024-04-09 20:45:45 <veltas      > I'm trying to come up with a shared computational model that allows us to reduce or factor the memory requirements further,
2024-04-09 20:45:58 <veltas      > and I hope to understand whether it's realistic or practical to do this in more general computing
2024-04-09 21:59:51 <KipIngram   > It was mostly predicated by just "don't have unused space sitting around."
2024-04-09 22:01:09 <thrig       > it's Time Sharing, McCarthy, but not as we know it!