2022-07-10 11:43:32 <dzho        > KipIngram: wasn't sure what to think of that claim about proteins and functionality.
2022-07-10 11:43:51 <dzho        > log(20^150) is about 195 so ...
2022-07-10 11:44:09 <dzho        > I'm still not sure what to think of it, but at least I've got some sense as to how few that is amongst the possibilities.
2022-07-10 11:44:46 <dzho        > I haven't kept up with the field to know how far along they're getting with heuristics for the protein folding problem
2022-07-10 11:45:11 <dzho        > so I'm not even sure where that estimate (10^77) is coming from
2022-07-10 11:46:30 <KipIngram   > It's just a number I saw in something I read.  I can't comment on its integrity.
2022-07-10 11:46:57 <dzho        > yeah it's just interesting to think about this after not really thinking about it for a while
2022-07-10 11:47:24 <KipIngram   > Main thing I noted from it is that if that's so then they still have some things left to figure out about abiogenesis.
2022-07-10 11:47:33 <dzho        > oh my mercy yes
2022-07-10 11:47:55 <KipIngram   > Unless there's a multiverse - if you throw a factor of 10^500 or 10^1000 universes into the mix, then things that were otherwise improbable almost have to happen somewhere.
2022-07-10 11:48:16 <dzho        > one of the theories of abiogenesis is that the first things that looked like "life" were RNA
2022-07-10 11:48:49 <KipIngram   > I mean, the "random chemistry in a warm puddle over a long time" theory sounds nice, but when you start including numbers like 10^77 in the mix then the probabilities wind up really small.
2022-07-10 11:48:49 <dzho        > but that's a hard thing to work with in a lab because now there are so many enzymes all over the place that chew up RNA pretty thoroughly
2022-07-10 11:49:25 <KipIngram   > Yeah - there's a lot of "interference" floating around that didn't exist at that time.
2022-07-10 11:49:43 <KipIngram   > Hard for life to pop up when life is already around and is so good at eating things.
2022-07-10 11:50:02 <dzho        > yup
2022-07-10 11:50:06 <dzho        > they discovered in the '80s I think it was that RNA could perform catalytic aka enzymatic functions
2022-07-10 11:50:11 <KipIngram   > Yes.
2022-07-10 11:50:19 <KipIngram   > There've been nice bits of progress over the years.
2022-07-10 11:50:32 <KipIngram   > There's some interesting aspects of non-equilibrium thermodynamics too.
2022-07-10 11:50:50 <KipIngram   > That indicate complexity seems to emerge spontaneously in certain types of situations where there's a continuous energy flow.
2022-07-10 11:51:12 <KipIngram   > There seems to be a natural tendency for things to arrange themselves for maximum entropy production.
2022-07-10 11:51:33 <KipIngram   > And that's even before you have any self-replication and natural selection.
2022-07-10 11:54:11 <KipIngram   > I'm wondering currently if maybe that sort of thing will fill in some of the blanks in a final theory about all that stuff.
2022-07-10 11:54:52 <KipIngram   > Once you get life started, natural selection handily explains the rest.  It's just that initial kicking off that's massively unlikely.
2022-07-10 11:56:29 <KipIngram   > I find it kind of entertaining that guys like Richard Dawkins, who are not physicists, have jumped all over multiverse theory.  They don't really have the background to have a really strong scientific opinion about it, but it really *helps* them - it puts their own arguments on much more solid numerical ground.  So, they're fans.
2022-07-10 11:57:59 <KipIngram   > I think a really important thing will be whether or not we ever find any life of independent origin.   Right now we only know about ONE example of life having "initiated."  That means it's ok for it to be incredibly, incredibly low-probability.  No matter how low the probability was, it still could have happened once.
2022-07-10 11:58:16 <KipIngram   > But if we find another tree of life, then suddenly we need an explanation that provides a much higher probability.
2022-07-10 12:07:24 <KipIngram   > A few months ago there was a flap about spectral indicators of possible life in the upper atmosphere of Venus.  I heard about it fairly often for a few weeks, but it's been a while now; may have fizzled out.  At the time it seemed worth following up on to me, with a probe of some kind.  Even if it's there, though, it could turn out to be from the same tree - apparently during an earlier phase of the life of
2022-07-10 12:07:26 <KipIngram   > the solar system material moved around a good bit and they it it would have been possible for genetic material to be included in that.
2022-07-10 12:07:56 <KipIngram   > they "think"
2022-07-10 12:08:57 <thrig       > probes don't do too well on venus
2022-07-10 12:11:46 <KipIngram   > Yeah I know.  This one would just have to dip briefly into the very top of the atmosphere and then bail back out.
2022-07-10 12:11:58 <KipIngram   > It's not as bad up there (or there wouldn't be any chance of life).
2022-07-10 12:12:26 <KipIngram   > There are some non-organic chemical reactions that could have created what they think they saw, but they aren't considered likely under the conditions there.
2022-07-10 12:12:56 <KipIngram   > Anyway, it may be a dead issue now; I lost track of it after a while.
2022-07-10 12:14:40 <KipIngram   > And it would only be "hugely significant" if it turned out to be an independently originating life; if it's related to us it's "interesting" but much less important.
2022-07-10 12:14:44 <thrig       > someone would need to fund, plan, carry out a mission with suitable instrument. so, years
2022-07-10 12:14:52 <KipIngram   > Yes.
2022-07-10 12:15:18 <KipIngram   > I think there had already been some scuttle about a Venus mission anyway, so some of the preliminaries might have already been done.
2022-07-10 12:55:18 <dzho        > so, in addition to how hostile things are now for RNA I occasionally just sit in total wonder at the aerobe/anaerobe thing we've had going on since the oxygen catastrophe
2022-07-10 12:56:24 <dzho        > which is where my thoughts went pretty quickly seeing speculation above about Venus, or about a common initiating event for the solar system as a whole
2022-07-10 12:57:05 <dzho        > I'm more Team Gas Giant for a systemwide initiating event having survived somewhere
2022-07-10 12:58:50 <KipIngram   > dave0: Apparently nasm doesn't support direct assembly of i nstructions that use rip-relative addressing.
2022-07-10 12:59:09 <KipIngram   > But the instruction set does.  If I try to say 'lea rcx, [rip]', that throws an error.
2022-07-10 12:59:29 <KipIngram   > But you can assemble it here:
2022-07-10 12:59:31 <KipIngram   > https://defuse.ca/online-x86-assembler.htm
2022-07-10 12:59:48 <KipIngram   > and then insert the resulting bytes right into the instruction stream in nasm using db.
2022-07-10 12:59:55 <KipIngram   > And that appears to work just fine.
2022-07-10 13:00:04 <tabemann    > about multiverses, the thing is they solve the matter of why our universe seems so fine-tuned for senient life
2022-07-10 13:00:16 <KipIngram   > Yes, it does put that question very nicely to rest.
2022-07-10 13:00:26 <KipIngram   > Just slam dunks it.
2022-07-10 13:00:41 <KipIngram   > Which of course doesn't mean it's true.  But it may be.
2022-07-10 13:01:05 <tabemann    > because if there weren't multiverses, there would be a lot of questions that, well, imply a god
2022-07-10 13:01:10 <KipIngram   > If you *don't* assume it, though, then that fine tuning question becomes very onerous for everyone except the religious folk.
2022-07-10 13:01:22 <KipIngram   > ^ Exactly.
2022-07-10 13:01:58 <tabemann    > the thing is, will we ever know an answer to this?
2022-07-10 13:02:29 <KipIngram   > Yeah, we may not.
2022-07-10 13:02:40 <KipIngram   > No promises that we get to know everything for sure.
2022-07-10 13:03:14 <tabemann    > but yeah, I can see how people like Dawkins would really be attracted to multiverses
2022-07-10 13:04:21 <tabemann    > thing is, fine-tuning does not help most traditional religious people either, but rather deists
2022-07-10 13:04:37 <KipIngram   > Yeah, I agree.
2022-07-10 13:04:46 <KipIngram   > Doesn't help the  "literalists."
2022-07-10 13:06:20 <tabemann    > if they were to either prove or disprove multiverses, though, that would have major implications either way
2022-07-10 13:06:32 <KipIngram   > It really would.
2022-07-10 13:07:05 <KipIngram   > That would also necessitate a "higher probability" theory of abiogenesis.
2022-07-10 13:07:11 <eris[m]     > i dont think its exactly something that can be proven or disproven
2022-07-10 13:07:16 <KipIngram   > If that 10^77 number is right.
2022-07-10 13:07:17 <eris[m]     > it's a metaphysical not a physical question
2022-07-10 13:07:35 <KipIngram   > Yeah, I think it's beyond our ability to observe.
2022-07-10 13:07:40 <eris[m]     > assuming that there are 'realities' 'parallel' to our own, what makes them not simply part of our universe?
2022-07-10 13:08:05 <eris[m]     > there's nothing that makes 'the multiverse' not simply 'the universe'
2022-07-10 13:08:21 <KipIngram   > Well, one of the multiverse theories holds that our "universe" is a "bubble" in which cosmic inflation has stopped, while all around it inflation continues.
2022-07-10 13:08:26 <KipIngram   > And there would be other bubbles.
2022-07-10 13:08:33 <KipIngram   > Way beyond anything we could confirm.
2022-07-10 13:08:51 <tabemann    > the key thing is the fundamental constants of the universe could be different
2022-07-10 13:09:03 <KipIngram   > Right, for the fine tuning resolution.
2022-07-10 13:09:08 <eris[m]     > sure, but those could simply be properties of the universe
2022-07-10 13:09:21 <KipIngram   > And they throw out numbers for those "bubbles" of like 10^500.
2022-07-10 13:09:34 <eris[m]     > like, idk
2022-07-10 13:09:42 <KipIngram   > So with all of THAT out there, then suddenly 1 in 10^77, or even one in something much bigger, is no longer "rare."
2022-07-10 13:09:49 <KipIngram   > Well, no longer "unlikely."
2022-07-10 13:09:50 <eris[m]     > nothing prevents these 'bubbles' from simply being part of the universe
2022-07-10 13:09:52 <KipIngram   > Still rare I guess.
2022-07-10 13:10:00 <eris[m]     > maube the universe has different fundamental constants and laws based on location
2022-07-10 13:10:07 <KipIngram   > Yeah, it depends on what you want to call "the universe."
2022-07-10 13:10:12 <eris[m]     > the fundamental constants and laws are already subject to change
2022-07-10 13:10:14 <eris[m]     > exactly!
2022-07-10 13:10:26 <eris[m]     > it's a metaphysical question
2022-07-10 13:10:32 <eris[m]     > and metaphysics is bloody useless
2022-07-10 13:10:32 <KipIngram   > It is.
2022-07-10 13:10:44 <KipIngram   > Useless scientifically, yeah.
2022-07-10 13:10:49 <KipIngram   > It can be fun, though.
2022-07-10 13:10:55 <eris[m]     > that's fair!
2022-07-10 13:11:25 <tabemann    > the thing is that I don't think that things like whether there could be other universes is necessarily beyond proof or disproof
2022-07-10 13:11:26 <KipIngram   > If we can't measure it and confirm or reject it, it's not really science.
2022-07-10 13:11:54 <KipIngram   > I don't think they have to be - our bubble might interact with some other bubble.
2022-07-10 13:12:15 <KipIngram   > But I think it's pretty clear that "remote" bubbles would be beyond our ability to detect.
2022-07-10 13:12:22 <KipIngram   > Unless something new comes along.
2022-07-10 13:12:58 <eris[m]     > i dont think there's really any point in pursuing it :)
2022-07-10 13:13:15 <KipIngram   > As far as the fundamental constants go, our universe could be sitting at an equilibrium point in a big nonlinear parameter space, and "vibrating" around it.  If it somehow got knocked to a different equilibrium point, all those constants might change.
2022-07-10 13:13:15 <eris[m]     > i don't want to end up a rat biting into an electric cable, yknow?
2022-07-10 13:13:23 <KipIngram   > And we might go "poof."
2022-07-10 13:13:52 <KipIngram   > Very much like the response of an amplifier depending on the transistor's Q-point.
2022-07-10 13:14:55 <tabemann    > I'm not a physicist so I don't feel qualified to speak on these matters
2022-07-10 13:17:44 <KipIngram   > Oh god, I'm not either.  I read a lot about it, but I'm nowhere near expert.
2022-07-10 13:17:57 <KipIngram   > Maybe a little more than a lot of people, but still way down the curve.
2022-07-10 13:18:27 <KipIngram   > I loaded up on high math in graduate school because I knew I wanted to learn more over the years, but I still missed out on some of the important math.
2022-07-10 13:18:53 <KipIngram   > I'm pretty good with linear algebra and tensors, but I completely missed the group theory boat, and that turns out to be pretty important.
2022-07-10 13:18:58 <KipIngram   > Still trying to catch up there.
2022-07-10 13:22:21 <tabemann    > I always feel like a dumbass when it comes to math to tell the truth
2022-07-10 13:23:36 <tabemann    > probably because I never went to grad school
2022-07-10 13:29:34 <tabemann    > 
ACTION just went to the wiki, looked up "group theory", and came out wondering what the heck a group really is

2022-07-10 13:30:28 <imode       > it's an algebraic structure, which is a set of objects with some operations on it.
2022-07-10 13:30:56 <thrig       > the Abstractions of Zargel III are attacking!
2022-07-10 13:30:56 <imode       > those operations can follow some laws. associativity, etc.
2022-07-10 13:31:42 <tabemann    > imode: well I mean beyond that
2022-07-10 13:31:47 <imode       > that's it.
2022-07-10 13:31:53 <imode       > that is literally it.
2022-07-10 13:32:10 <imode       > the "universe" of algebraic structures is just that.
2022-07-10 13:32:47 <tabemann    > what is the relationship between group theory and category theory?
2022-07-10 13:33:37 <imode       > group theory is a single algebraic theory.
2022-07-10 13:34:12 <tabemann    > like I know what monads, functors, and monoids are
2022-07-10 13:34:45 <imode       > rings, groups, lattices, modules.
2022-07-10 13:35:03 <imode       > all different algebraic theories.
2022-07-10 13:35:32 <imode       > category theory is a bit more abstract, mainly because of all the mental wankery.
2022-07-10 13:36:02 <imode       > categories are "maps of the territory". they aren't the territory, but they're a map of the territory.
2022-07-10 13:36:13 <imode       > how you convert between different structures.
2022-07-10 13:36:39 <imode       > what operations are available and why.
2022-07-10 13:37:22 <tabemann    > of course, the reason why I'm familiar with the likes of monads, functors, and monoids is from my time working with haskell...
2022-07-10 13:37:59 <imode       > algebraic data types should've tipped you off, because the method for describing types forms an algebra.
2022-07-10 13:38:11 <thrig       > haskell, a system to annoy you with type errors
2022-07-10 13:38:19 <tabemann    > hee
2022-07-10 13:38:23 <tabemann    > *hee
2022-07-10 13:38:26 <tabemann    > *hehe
2022-07-10 13:39:11 <tabemann    > as they say, though, once haskell stops generating type errors your program is probably correct
2022-07-10 13:39:32 <tabemann    > whereas Forth, well, has no guardrails
2022-07-10 13:40:00 <imode       > stack/queue languages can have the same guarantees as haskell.
2022-07-10 13:40:24 <thrig       > types don't stop you from walking a list the wrong way
2022-07-10 13:40:26 <imode       > mainly because effects are a complete language to describe the types of functions.
2022-07-10 13:40:27 <tabemann    > imode: it's not the stack but rather the direct access to memory
2022-07-10 13:40:40 <imode       > that's.. not even close.
2022-07-10 13:40:59 <imode       > direct access to memory isn't something a type system or haskell prevents.
2022-07-10 13:41:14 <imode       > you can actually access memory in haskell.
2022-07-10 13:41:31 <tabemann    > imode: well, yes, in Haskell you can directly access memory... but you don't do so by mistake
2022-07-10 13:41:44 <imode       > I can't do that in Java either.
2022-07-10 13:42:27 <imode       > or Go.
2022-07-10 13:42:39 <tabemann    > of course the real issue in Haskell is space leaks
2022-07-10 13:43:00 <imode       > it's also founded on the wrong abstraction for building things.
2022-07-10 13:43:23 <imode       > erlang is better founded.
2022-07-10 13:45:56 <tabemann    > Haskell is better-suited to straight-line pure computation whereas Erlang is better-suited to large-scale concurrent applications
2022-07-10 13:46:12 <tabemann    > I wouldn't write a compiler in Erlang myself
2022-07-10 13:46:26 <tabemann    > whereas Haskell IMO is a great language to write a compiler in
2022-07-10 13:46:34 <imode       > I'm not sure why you wouldn't, but I'd also wanna know what the hell "straight-line pure computation" is.
2022-07-10 13:47:02 <imode       > other than some masturbatory ivory tower supremacy shit.
2022-07-10 13:47:32 <tabemann    > pure computation, taking data A and spitting out data B, without invoking concurrency or IO
2022-07-10 13:47:57 <imode       > great. and nearly every language on the planet is good at doing that, even erlang.
2022-07-10 13:48:09 <imode       > brainfuck or the SKI calculus is great at doing that.
2022-07-10 13:48:34 <imode       > it's literally the minimum requirement to be a programming language. sequential programming.
2022-07-10 13:48:36 <tabemann    > you're essentially saying that being Turing-complete is "great at doing that"
2022-07-10 13:48:39 <imode       > yes.
2022-07-10 13:48:47 <imode       > because that's literally the point of a turing machine.
2022-07-10 13:49:00 <imode       > take input tape, produce output tape.
2022-07-10 13:49:08 <imode       > take input lambda expression, reduce to output lambda expression.
2022-07-10 13:49:23 <tabemann    > the thing is that in Haskell the type system is your friend and is very well-suited for representing data
2022-07-10 13:49:32 <imode       > so is OCaml's.
2022-07-10 13:49:42 <imode       > and Rust's, to some extent.
2022-07-10 13:49:51 <thrig       > I uninstalled haskell instead of making friends with the type system
2022-07-10 13:50:09 <tabemann    > well, the basic type systems, before you invoke extensions, of Haskell and OCaml are very similar
2022-07-10 13:50:24 <imode       > because type theory isn't something Haskell-only.
2022-07-10 13:50:26 <tabemann    > 
ACTION used to program in OCaml before he switched to Haskell

2022-07-10 13:50:56 <tabemann    > but Haskell has nice things that OCaml doesn't have such as type classes
2022-07-10 13:51:08 <imode       > and the extensions aren't all that useful. if you really need dependent types, go with C++ templates or Agda. have fun risking that your type checker won't halt.
2022-07-10 13:51:37 <tabemann    > type classes are one of my favorite aspects of Haskell, and OCaml's eqtypes suck balls in comparison
2022-07-10 13:51:45 <KipIngram   > Holy cow - I walk away for a few minutes and miss a ton...
2022-07-10 13:51:47 <imode       > let me take you for a tour of "why you have been retreading the wrong road along with your colleagues for the past 60 years".
2022-07-10 13:52:07 <imode       > software formalists really did try to understand how to properly build software like civil engineers.
2022-07-10 13:52:12 <imode       > that was in the 50's and 60's.
2022-07-10 13:52:24 <imode       > they failed.
2022-07-10 13:53:03 <tabemann    > if I ever write a large application that I'm not doing so for my job on the PC again, sorry, but I'm doing it in Haskell
2022-07-10 13:53:18 <imode       > I'll be impressed if anything works after 3 months.
2022-07-10 13:53:42 <tabemann    > I work in Forth and assembly these days on my own, but that's because I target embedded systems now
2022-07-10 13:53:52 <imode       > evangelists of this paradigm of organization always hush up.
2022-07-10 13:54:01 <imode       > because they genuinely don't make anything that works.
2022-07-10 13:54:18 <imode       > the only thing sane that ever came out of haskell (and it was an accident) is pandoc. and I love the bloat that that thing has built up for it.
2022-07-10 13:54:23 <tabemann    > I've definitely written things that work in Haskell
2022-07-10 13:54:28 <imode       > oh yeah? show me.
2022-07-10 13:55:39 <tabemann    > https://github.com/tabemann/botwars < mind you, it's probably suffered from software rot, because I compiled it last several years ago, and GHC has moved on since then
2022-07-10 13:56:01 <tabemann    > something about you seems to evoke "Haskell hater" to me though
2022-07-10 13:56:03 <imode       > oh neat, a toy.
2022-07-10 13:56:20 <tabemann    > or this:
2022-07-10 13:56:21 <tabemann    > https://github.com/tabemann/amphibian
2022-07-10 13:56:24 <imode       > something about you seems to evoke "Haskell evangelist".
2022-07-10 13:56:40 <imode       > as in, you don't understand why you like something, and will espouse its virtues on command, as if puppeted.
2022-07-10 13:56:57 <tabemann    > I spend most of my time these days working in Forth and assembly, at home, and C++, at work
2022-07-10 13:57:11 <imode       > I manage digital accounting at Amazon.
2022-07-10 13:57:21 <tabemann    > so I'm a "Haskell evangelist" because I like Haskell and think it has its place
2022-07-10 13:57:36 <imode       > I think you haven't been exposed to the working environments that put models to the test.
2022-07-10 13:57:55 <tabemann    > imode: you obviously don't realize that I've run into things such as space leaks myself
2022-07-10 13:58:08 <imode       > everybody runs into them. it's on the wiki.
2022-07-10 13:58:18 <tabemann    > if I were to recreate Haskell from square one today I'd make it strict-evaluated
2022-07-10 13:58:18 <imode       > congratulations, you are average.
2022-07-10 13:58:19 <KipIngram   > I consider it slightly annoying that there are valid instructions that nasm won't directly assemble.
2022-07-10 13:58:48 <imode       > everybody has a favorite toy, everybody enjoys evangelizing their favorite toy.
2022-07-10 13:58:55 <imode       > thinking critically is difficult.
2022-07-10 13:59:09 <imode       > you have to do the latter when you're dealing with actual problems.
2022-07-10 13:59:09 <tabemann    > I plan on trying out Idris some day myself, but from reading about Agda wonder if I will ever wrap my brain around dependent types
2022-07-10 13:59:21 <KipIngram   > Yes - it is hard to think critically about something that you are either "very fond of" or "very non-fond" of.
2022-07-10 13:59:21 <imode       > dependent types are really simple.
2022-07-10 13:59:40 <imode       > it's just that the side-effect is that typechecking makes them undecidable.
2022-07-10 14:00:00 <imode       > because value types are things that are produced by potentially halting computations.
2022-07-10 14:00:29 <tabemann    > hence totality checkers and that nonsense (yes, you don't need to tell me about the halting problem, I know how totality checkers work)
2022-07-10 14:00:49 <imode       > which kind of defeats the point of formal proofs, eh?
2022-07-10 14:01:01 <imode       > the point was to use a weaker system to describe and constrain a stronger system.
2022-07-10 14:01:27 <imode       > this is the full fucking point of why church et. al. looked at bare LC and said "well shit we can't usefully describe anything because we can describe everything".
2022-07-10 14:02:16 <imode       > so you affix a limiter to it, and the thing becomes useful. to the extent that you can describe what you want within that new, limited system.
2022-07-10 14:02:28 <imode       > I've been working in functional programming for a long time.
2022-07-10 14:02:51 <imode       > hell I even implemented my own term rewriting language for a job, and then built a type theory on top of it.
2022-07-10 14:02:53 <KipIngram   > I am woefully ignorant of it.  Barely know what it "is."
2022-07-10 14:02:58 <KipIngram   > And may be wrong about that in some ways.
2022-07-10 14:03:15 <imode       > there isn't much meat that's useful, KipIngram.
2022-07-10 14:03:27 <tabemann    > KipIngram: functional programming is basically where your program, ideally, is a mathematical expression
2022-07-10 14:03:43 <KipIngram   > Yeah, that's basically how I think of it.
2022-07-10 14:03:52 <KipIngram   > "Turn it into math."
2022-07-10 14:04:01 <imode       > that's a lame explanation.
2022-07-10 14:04:09 <tabemann    > most functional programming languages get around the little problems of IO and concurrency by breaking from that model at some level, introducing monads, or introducing linear types
2022-07-10 14:04:57 <imode       > a more apt explanation would be there's no way to implicitly model state in the units of code that you write. every function (it's in the name) is actually a mathematical function: one input, one output, domain and range.
2022-07-10 14:05:14 <imode       > it can't change from under you, and your programs in the abstract form a dataflow graph.
2022-07-10 14:05:28 <imode       > which then gets reduced and compiled down to a target.
2022-07-10 14:05:34 <tabemann    > yeah
2022-07-10 14:05:38 <imode       > it's beneficial because you don't give a shit about the evaluation of that graph.
2022-07-10 14:05:41 <imode       > only that it evaluates.
2022-07-10 14:05:41 <KipIngram   > But then they talk about "side effects."
2022-07-10 14:05:50 <imode       > right. which, like with a dataflow graph, can be better isolated.
2022-07-10 14:05:55 <KipIngram   > And given the work I did it was those effects I was interested in.
2022-07-10 14:05:59 <imode       > you can understand and deal with the stateful parts or pass handles around.
2022-07-10 14:06:08 <KipIngram   > I wanted to DO SOMETHING to some actual piece of stuff.
2022-07-10 14:06:18 <imode       > you can. all functional programs are dataflow graphs.
2022-07-10 14:06:22 <imode       > and those need inputs and outputs.
2022-07-10 14:06:39 <tabemann    > side effects are implemented either by enforcing some order to evaluation, which allows you to put parts in that do IO or concurrency, or by introducing either monads or linear types
2022-07-10 14:06:49 <KipIngram   > But the other models of computation get at that more directly.
2022-07-10 14:06:58 <imode       > largely because they were built on a different paradigm.
2022-07-10 14:07:00 <tabemann    > a linear type btw consists of values that can only be acted upon once
2022-07-10 14:07:06 <KipIngram   > Yeah.
2022-07-10 14:07:14 <imode       > this is model dichotomy.
2022-07-10 14:07:17 <KipIngram   > Oh, thank you - I thought about asking, but then decided I'd try to look it up later.
2022-07-10 14:07:24 <imode       > turing/post's machines, and church's lambda expressions.
2022-07-10 14:07:34 <tabemann    > so each function can have an "inputIO" value and return an "outputIO" value, with linear types
2022-07-10 14:07:41 <imode       > church's input is "the expression". turing calls out inputs.
2022-07-10 14:08:13 <imode       > so in the process of reduction of that expression, in order to have any kind of I/O, you need something that gets "swapped out" for the value you're inputting on whatever I/O method you choose.
2022-07-10 14:08:39 <imode       > that's where linear types come in. you hand me an "I/O token", I swap it for the thing on the input bus.
2022-07-10 14:08:44 <imode       > but you can't use that again.
2022-07-10 14:09:09 <imode       > notice, though, how that's a very real analogy. people talking to people.
2022-07-10 14:10:19 <tabemann    > the difference between the use of an IO monad and an IO linear type, of course, is that the latter requires a lot of work to thread the IO linear type through your program
2022-07-10 14:10:19 <imode       > ivory tower mental masturbation hides the fact that functional programming's strength is that it's stitching together data flow modules, and each module has a "pinout" (phrased as a type signature) that it's expecting to get hooked up to, in and out.
2022-07-10 14:10:35 <imode       > it's why it makes a very good paradigm for HDLs.
2022-07-10 14:10:54 <imode       > and it's why chuck moore moved very fast when making his own EDA systems. because forth is functional to a large extent.
2022-07-10 14:11:16 <imode       > just with some additional shortcuts for I/O that you can eventually model into whatever flavor of I/O you want.
2022-07-10 14:12:51 <tabemann    > forth can be functional yes, even though forth the way I've used it is not because so much of what is going on is talking to hardware directly or, in the case of my Forth, invoking concurrency
2022-07-10 14:13:33 <imode       > the only difference between forth and haskell is the lack of enforced and well-typed stack effects, and the fact that the I/O isn't "hidden" from you. you can absolutely talk to the hardware in haskell.
2022-07-10 14:13:47 <imode       > most of haskell is written in haskell.
2022-07-10 14:13:51 <imode       > how else would it bootstrap.
2022-07-10 14:15:38 <tabemann    > most forths do not rely heavily on things like tail recursion, though, since most forths do not have real tail call "optimization", but rather use traditional imperative looops
2022-07-10 14:16:51 <imode       > most forths aren't interested in combining functional programming with their stuff.
2022-07-10 14:17:03 <imode       > you'd need to look at the general landscape of concatenative languages.
2022-07-10 14:17:09 <tabemann    > yes, like Factor
2022-07-10 14:17:17 <tabemann    > I've always meant to try it out, never have though
2022-07-10 14:17:21 <imode       > it's alright.
2022-07-10 14:17:50 <imode       > it's interesting in how far it's developed but it doesn't bring much new to the table.
2022-07-10 14:18:14 <tabemann    > considering that it was originally just a scripting language on top of Java
2022-07-10 14:18:36 <imode       > clojure is still that and powering a great deal of things.
2022-07-10 14:19:12 <tabemann    > I've looked at Clojure and have felt that it's impressive but is just too Java-influenced for my taste
2022-07-10 14:19:28 <tabemann    > 
ACTION used to program at Java at his previous job and isn't too fond of it

2022-07-10 14:19:39 <imode       > there's some good ideas there, hickey, for what he's worth, is in the right area but with the wrong scope.
2022-07-10 14:20:19 <tabemann    > personally I like GHC's implementation of STM better than Clojure's though
2022-07-10 14:20:32 <imode       > the fact that you need it means we're doing something wrong.
2022-07-10 14:21:39 <tabemann    > well, STM fits a traditional single-machine concurrency model well but does not extend to a multi-machine distributed concurrency model
2022-07-10 14:21:54 <imode       > message passing is better.
2022-07-10 14:22:08 <imode       > qualified isolation is better.
2022-07-10 14:22:44 <tabemann    > you can implement message passing on top of STM, btw
2022-07-10 14:22:54 <imode       > and you can implement STM on top of message passing.
2022-07-10 14:23:16 <imode       > funny how "things talking to eachother" is such a universal concept.
2022-07-10 14:23:34 <imode       > that's why erlang wins.
2022-07-10 14:23:38 <tabemann    > I imagine going the opposite way is much harder
2022-07-10 14:23:48 <imode       > trust me when I say it isn't.
2022-07-10 14:27:37 <tabemann    > of course in Forth I don't do any of this but rather do traditional imperative concurrency based on channels (whether queue or rendezvous), semaphores, locks (a specialized kind of semaphore of course), and like
2022-07-10 14:28:34 <imode       > rendevouz/blocking channels are a feature of biology.
2022-07-10 14:28:44 <imode       > they're robust for a reason.
2022-07-10 14:36:27 <tabemann    > I find in practice I can get better throughput in many cases with queue channels though
2022-07-10 14:37:38 <tabemann    > because one task can fill up the entire queue and then block once the queue is full, then the other task can receive from the entire queue and block once the queue is empty, back and forth
2022-07-10 14:38:11 <tabemann    > whereas a rendezvous channel is essentially a queue channel with a buffer of size 0
2022-07-10 14:38:23 <tabemann    > so it always blocks
2022-07-10 14:39:12 <imode       > yep. this is because you favor larger, long-running processes that target a single or few communication channels rather than phrasing your computation as the orchestration of tons of tiny processes that communicate locally over rendezvouz channels.
2022-07-10 14:39:24 <imode       > everybody does that and it's why erlang went with queues.
2022-07-10 14:42:26 <tabemann    > the reason I go with larger, longer-running processes is that stack space is expensive on embedded systems, so having large numbers of tasks gets expensive quickly
2022-07-10 14:42:28 <tabemann    > but
2022-07-10 14:42:53 <imode       > you need a smaller model of processes.
2022-07-10 14:42:55 <tabemann    > what I did do was implement something I called, for a lack of a better term, "actions", which are like processes minus stacks
2022-07-10 14:43:03 <imode       > ayyy.
2022-07-10 14:43:03 <KipIngram   > I also think it's just easier for a lot of us to think in terms of long-running processes.
2022-07-10 14:43:16 <KipIngram   > May just be habit, but it's a comfort zone.
2022-07-10 14:43:25 <imode       > KipIngram: long-running isn't bad. I guess the focal term is "larger".
2022-07-10 14:43:33 <KipIngram   > That's fair.
2022-07-10 14:43:40 <tabemann    > actions do purely blocking messaging with one another, and are very, very fast too
2022-07-10 14:43:49 <KipIngram   > It's another "dimension" of the same thing that makes GA144 programming really different.
2022-07-10 14:43:51 <imode       > monolithic. runs of sequential execution delimited by communication, rather than communication delimited by sequential execution.
2022-07-10 14:43:58 <KipIngram   > And you're right - those can be long running.
2022-07-10 14:44:07 <KipIngram   > They're just "small" compared to what many of us are used to.
2022-07-10 14:44:10 <imode       > the cells in your body are long running in their relative timespan.
2022-07-10 14:44:17 <KipIngram   > Yeah.
2022-07-10 14:45:20 <KipIngram   > I still think digital circuits have some analogies with this.
2022-07-10 14:45:31 <KipIngram   > Each "event" at a gate in a digital circuit is a very small thing.
2022-07-10 14:45:40 <imode       > there's a symmetry there.
2022-07-10 14:45:45 <tabemann    > the key thing with "actions", though, is code that uses them has to be structured in terms of individual words that get called, have complete control over the parent task while they run, and then give up control, without maintaining stack space in between
2022-07-10 14:45:46 <imode       > which is why Feather has a software and a hardware model.
2022-07-10 14:45:52 <KipIngram   > The gate does the same thing most of the time, but it does it over and over and those are independent events.
2022-07-10 14:46:26 <tabemann    > they're rather similar to how asynchronous computing is done in JavaScript actually
2022-07-10 14:46:36 <tabemann    > except JavaScript has closures
2022-07-10 14:46:40 <tabemann    > and Forth does not
2022-07-10 14:46:47 <imode       > unless you want it to.
2022-07-10 14:46:53 <KipIngram   > :-)
2022-07-10 14:47:28 <KipIngram   > I've always thought that digital logic, particularly asynchronous, is a good "training ground" for multi-thread programming.
2022-07-10 14:48:14 <tabemann    > I find digital logic (from what I did in it at school back when at least) is very different from multitasking, at least after having really implemented a multitasking system
2022-07-10 14:48:29 <imode       > there's no scheduler, that's for sure.
2022-07-10 14:48:48 <KipIngram   > Single-core/single-thread is kind of like a one-wire comm channel.  You send one bit, then you send the next, etc. etc.  Multi-core/multi-thread is  like a general circuit, with stuff happening all over the place with independent timing to a large extent.
2022-07-10 14:48:49 <imode       > components need to be self-timing, which means handshakes for literally every transaction along component boundaries.
2022-07-10 14:49:04 <tabemann    > in multitasking an individual task has undivided control over a core, interrupts aside, until it blocks or the scheduler decided that it's times-up and gives control to another task
2022-07-10 14:49:47 <tabemann    > the idea that every task is running at once is an illusion
2022-07-10 14:49:56 <KipIngram   > Well, I don't disagree.  I'm just talking about the timing / race condition issues that can arise *between threads*.  You can get that same kind of thing in general asynchronous circuits.
2022-07-10 14:50:03 <KipIngram   > Same type of "faults" can byte you.
2022-07-10 14:50:10 <imode       > heh, definitely.
2022-07-10 14:50:11 <KipIngram   > So I'm only trying to draw a fairly limited analogy.
2022-07-10 14:50:37 <KipIngram   > And when I say it's a good "training ground," I only mean for certain issues that arise in multi-thread programming, not the whole business.
2022-07-10 14:50:41 <tabemann    > yeah
2022-07-10 14:50:49 <thrig       > Dog bytes man, film at 11
2022-07-10 14:50:54 <tabemann    > race conditions are much more acute in digital logic
2022-07-10 14:51:04 <tabemann    > but that's almost a good thing
2022-07-10 14:51:06 <KipIngram   > The point being that single-thread programming doesn't really prepare you for those issues at all.
2022-07-10 14:51:10 <tabemann    > because they bite you much sooner
2022-07-10 14:51:13 <KipIngram   > It's very "neat and tidy" by comparison.
2022-07-10 14:51:23 <imode       > sequential execution, man.
2022-07-10 14:51:25 <tabemann    > whereas in multitasking you can go quite a while without your race condition biting you
2022-07-10 14:51:26 <imode       > it's a drug.
2022-07-10 14:51:43 <KipIngram   > Yes, that's a perfect description.
2022-07-10 14:52:12 <imode       > yeah, desync or race conditions can actually screw up far more than local effects in a multithreaded environment.
2022-07-10 14:52:17 <KipIngram   > Right - I don't necessarily claim the training works both ways.
2022-07-10 14:52:19 <imode       > it can cascade into.. everything.
2022-07-10 14:52:34 <imode       > the chip can burst into flames.
2022-07-10 14:52:42 <imode       > (not really but in a manner of speaking.)
2022-07-10 14:52:50 <KipIngram   > Well, in digital logic you have metastability.
2022-07-10 14:52:58 <KipIngram   > And that's just... a whole different ballgame.
2022-07-10 14:53:06 <tabemann    > I'd be impressed if I saw a chip deflagrate due to a race condition lol
2022-07-10 14:53:07 <KipIngram   > That can REALLY ruin your day.
2022-07-10 14:53:34 <KipIngram   > How long metastable conditions persist is a probability thing.
2022-07-10 14:53:34 <tabemann    > it can ruin your day, but problems that happen sooner are more reliably are better in the end
2022-07-10 14:53:41 <KipIngram   > Less probable for it to last longer.
2022-07-10 14:53:52 <KipIngram   > But it's *possible* for it to last any length of time you choose.
2022-07-10 14:53:55 <imode       > tabemann: halt and catch fire! ;)
2022-07-10 14:54:00 <KipIngram   > It's like balancing a ball on the tip of a pencil.
2022-07-10 14:54:17 <KipIngram   > In theory it might sit there forever, but we know it's not going to.
2022-07-10 14:54:18 <thrig       > easier if you stab the ball
2022-07-10 14:54:26 <KipIngram   > :-)
2022-07-10 14:54:57 <KipIngram   > Sooner or later noise will take care of it, and it will find its way back into some valid state
2022-07-10 14:55:07 <KipIngram   > But God knows what state that might be, across the whole circuit.
2022-07-10 14:55:08 <tabemann    > my most fun multitasking bugs are ones that take long periods of time to manifest
2022-07-10 14:55:42 <tabemann    > like bugs I could only make manifest if I ran my code overnight and while I worked and eventually came back to it to see that it had failed
2022-07-10 14:56:31 <KipIngram   > Just in case someone doesn't know - metastability happens when you clock a flip flop when its input isn't decisively "high" or "low" in keeping with the setup and hold times.  Flip flop doesn't know what to do with that input, and it can take an arbitrary length of time for it to make a choice.
2022-07-10 14:57:06 <KipIngram   > If it lasts long enough, it's output will then be out of valid range when the next clock comes, so metastability can be contagious.
2022-07-10 14:57:17 <tabemann    > yeah
2022-07-10 14:57:48 <imode       > at Amazon, my code handles traffic from all physical and digital ordering streams along with all of the metadata/"transaction tracking" services that multiply that traffic by 5. if we have a fault, it spreads to the point where a billion dollar bleed is a certainty and not a nightmare you get to wake up from.
2022-07-10 14:57:55 <tabemann    > what I'm talking about is race condition issues that take many hours to manifest themselves
2022-07-10 14:58:14 <imode       > cross-service race conditions and serving 800+ independent business teams is fun.
2022-07-10 14:58:28 <imode       > if one of them fucks up, your system needs to be responsive and resilient to it.
2022-07-10 14:58:29 <KipIngram   > Sounds like it could have some real nightmare aspects.
2022-07-10 14:58:41 <tabemann    > that makes me glad I now work on MRI machines
2022-07-10 14:58:42 <imode       > it's why I harp on resiliency. our systems self-heal.
2022-07-10 14:58:47 <thrig       > so much fun when the wheels of the payments wagon come off
2022-07-10 14:58:57 <imode       > thrig: it makes audits more exciting. ;)
2022-07-10 14:59:11 <thrig       > I worked in Amazon Payments for a while
2022-07-10 14:59:47 <imode       > oh fun. you work with Herd at all?
2022-07-10 15:00:16 <thrig       > this was a while ago, pre 2010
2022-07-10 15:00:34 <imode       > "things are different" is an understatement.
2022-07-10 15:00:35 <imode       > heh.
2022-07-10 15:01:03 <thrig       > 3000 line shell scripts to do payment batching, etc
2022-07-10 15:01:21 <tabemann    > the idea of doing payments with 3000 line shell scripts is scary
2022-07-10 15:01:24 <imode       > we still do that.. buuuut in groovy...
2022-07-10 15:01:33 <imode       > ....and ion...
2022-07-10 15:01:43 <tabemann    > the idea of doing anything mission-critical with large shell scripts is scary
2022-07-10 15:01:57 <tabemann    > 
ACTION is not a fan of shell as you can imagine

2022-07-10 15:02:27 <thrig       > it got replaced with some Java version that had an exact same business logic bug as the old code did
2022-07-10 15:02:28 <tabemann    > and groovy is like "let's program in Java... but without compile-time type-safety"
2022-07-10 15:03:10 <imode       > we're downstream from all the upstream so we get heaped on crap like nobody's business.
2022-07-10 15:03:40 <imode       > there's a multi-million dollar a day bleed because someone thought modeling the same events with a different name wouldn't result in some interesting... conflicts.. with line items.
2022-07-10 15:04:19 <tabemann    > I'll be back in a bit
2022-07-10 15:04:22 <imode       > o/
2022-07-10 15:04:38 <KipIngram   > It's worth noting that asynchronous systems have less trouble with metastability issues, because each part can wait as long as it needs to - if you design it to "do nothing" unless its input is *valid*, then things just slow down a little and then move on properly most of the time.
2022-07-10 15:05:38 <imode       > it's a beautiful concept. shamefully underutilized, though.
2022-07-10 15:06:50 <KipIngram   > Yeah.  Synchronous became a habit.
2022-07-10 15:07:06 <imode       > velocity keeps it up.
2022-07-10 15:07:17 <KipIngram   > And it's often more logic-efficient, since lots of elements of the circuit share their timing control.
2022-07-10 15:07:25 <KipIngram   > Early on efficiency was important.
2022-07-10 15:07:38 <KipIngram   > Well, still is, I guess.
2022-07-10 15:07:40 <imode       > hard to get a clock signal from point A to point B if dist(A, B) is large enough, though.
2022-07-10 15:07:59 <KipIngram   > Yes, that's true, but dist(A,B) just kept getting smaller and smaller over the years.
2022-07-10 15:08:07 <thrig       > that's why you strap an atomic clock to your wrist, and then
2022-07-10 15:08:23 <imode       > it's more like it flatlined.
2022-07-10 15:08:37 <KipIngram   > That was an interesting bit of that Belt machine we talked about a couple months ago.  I'd never given thought to there being a down side of a larger cache.
2022-07-10 15:08:39 <imode       > you have more circuitry but it's more dense, the electrical paths' distances are growing.
2022-07-10 15:08:48 <KipIngram   > But if the cache is larger, parts of it are further away, and that can slow things down.
2022-07-10 15:08:52 <KipIngram   > So there's a sweet spot.
2022-07-10 15:08:57 <imode       > yeah. compute wants to be next to data.
2022-07-10 15:09:00 <imode       > like, really close to it.
2022-07-10 15:09:08 <imode       > it's why trillion-core chips are the future.
2022-07-10 15:09:14 <KipIngram   > Makes total sense.
2022-07-10 15:09:44 <imode       > we just don't know how the fuck to program them yet.
2022-07-10 15:12:42 <imode       > because we're still thinking in terms of large tasks. I don't even think our minds work on that level, it's why we need task boards and decomposition.
2022-07-10 15:12:43 <KipIngram   > Similar with quantum computers.  We have a few algorithms, but I don't think we *really* understand the lay of that land yet.
2022-07-10 15:13:01 <KipIngram   > As in, we don't have a general theory of what we can do with them and what we can't, like we do with classical computers.
2022-07-10 15:13:42 <KipIngram   > Some encryption schemes we know are quantum vulnerable, but others we "think" are not.  But we're not sure.
2022-07-10 15:13:56 <imode       > it's unexplored. it's the edge.
2022-07-10 15:14:01 <KipIngram   > Yeah.
2022-07-10 15:14:05 <imode       > we're still working on the mainland.
2022-07-10 15:14:17 <KipIngram   > And damn hard to build, too, from an engineering perspective.
2022-07-10 15:14:37 <KipIngram   > Quantum things don't generally like to stay to themselves; they like to interact with everything around them.
2022-07-10 15:16:33 <imode       > QDCA is an interesting contender for logic.
2022-07-10 15:16:48 <imode       > https://en.wikipedia.org/wiki/Quantum_dot_cellular_automaton
2022-07-10 15:17:20 <KipIngram   > Yeah, and there are some interesting ideas based on knot theory too, that seem to be a bit more resistant to decoherence.
2022-07-10 15:17:32 <KipIngram   > But no "practical successes" yet.
2022-07-10 15:17:57 <KipIngram   > I figure when quantum computers come they may come suddenly; someone "finds a new way" that just... works.
2022-07-10 15:18:19 <KipIngram   > Particularly if they're ever going to be cheap and small.
2022-07-10 15:18:43 <KipIngram   > But I just don't know to what extent all of us "need" quantum computing.
2022-07-10 15:18:48 <imode       > we don't.
2022-07-10 15:18:54 <KipIngram   > Won't really help us check our email and update our Facebook, etc.
2022-07-10 15:19:02 <imode       > it won't even help us build or compute in new ways.
2022-07-10 15:19:11 <KipIngram   > I think the chemical and pharma industries will be the biggest beneficiaries.
2022-07-10 15:19:17 <imode       > yeah, always domain specific.
2022-07-10 15:19:42 <KipIngram   > Maybe some logistics type operations.
2022-07-10 15:20:25 <imode       > my design partner is heavily interested in QC circuits.
2022-07-10 15:20:28 <KipIngram   > There's some famous quote where the CEO of IBM once estimated the world demand for computers at about five.
2022-07-10 15:20:44 <KipIngram   > In one of the biggest errors in history.  :-)
2022-07-10 15:20:53 <KipIngram   > But it may come closer to being true for quantum computers.
2022-07-10 15:20:55 <KipIngram   > It won't be five.
2022-07-10 15:21:05 <KipIngram   > But I doubt there will be one in everyone's pocket, too.
2022-07-10 15:21:30 <imode       > once popsci gets over it, it'll be better.
2022-07-10 15:21:54 <KipIngram   > I think a lot of folks don't understand that, though - they see the word "quantum" and mentally replace it with "magic" and just assume it's "more and better in every way" and will *displace* conventional computing.
2022-07-10 15:22:45 <KipIngram   > Yeah, popsci loves "quantum."  And they hype the "mysticism" of it more or less to death.
2022-07-10 15:22:54 <KipIngram   > Makes their articles more sensational.
2022-07-10 15:23:05 <imode       > look for the financial incentive and that's where you'll find innovation.
2022-07-10 15:23:19 <KipIngram   > Follow the money.
2022-07-10 15:24:24 <KipIngram   > That's exactly why I think chemical and pharma will be the big adopters.  There a whole lot of potential payoff there for them, in having access to cheaper, more correct models of chemical processes.
2022-07-10 15:25:01 <KipIngram   > And it really might usher in a golden age in those industries.  We might wind up with drugs and stuff that seem like magic compared to what we have now.
2022-07-10 15:25:23 <KipIngram   > Super materials, etc.
2022-07-10 15:26:03 <imode       > I'll be glad to see it. but there's incentives that lie beyond miracles.
2022-07-10 15:26:26 <imode       > if anything, it'll be the deprivation/gradual rollout of those miracles.
2022-07-10 15:29:38 <KipIngram   > I may be over-expecting.  I read The Expanse a few months ago; it's hard not to think "protomolecule" here.
2022-07-10 15:29:53 <KipIngram   > Though obviously that was literary hyperbole.
2022-07-10 15:30:07 <KipIngram   > That thing more or less was "magic."
2022-07-10 15:30:27 <imode       > magical mcguffin is a common trope, heh.
2022-07-10 15:30:47 <KipIngram   > Yeah.  It's a pretty good story, in spite of how heavily they leaned on it.
2022-07-10 15:31:43 <KipIngram   > And they did a great job with the first couple of TV seasons too - one of the best book->TV "conversion" I've ever seen.
2022-07-10 15:32:14 <KipIngram   > The show diverged some in season 3, unfortunately.
2022-07-10 15:32:45 <imode       > I've been looking for some series to watch while I do work, is it worth a watch?
2022-07-10 15:32:53 <imode       > is the acting non-shit.
2022-07-10 15:33:02 <KipIngram   > Yes it is.
2022-07-10 15:33:10 <KipIngram   > Well, I thought the acting was completely competent.
2022-07-10 15:33:37 <KipIngram   > I've only watched the first three seasons, but 1 and 2 were some of the best TV I've seen in a long long time.
2022-07-10 15:33:54 <KipIngram   > Definitely recommend at least trying it out.
2022-07-10 15:34:03 <imode       > I'll put it on my list!
2022-07-10 15:34:13 <KipIngram   > Cool; let us know!
2022-07-10 15:34:31 <imode       > sci-fi is rarely done well IMO.
2022-07-10 15:34:44 <imode       > I'm not a purist but acting and suspension of disbelief.
2022-07-10 15:35:10 <KipIngram   > I agree.
2022-07-10 15:36:07 <KipIngram   > McGuffin aside, I was pretty impressed with the "hard scifi" aspect of it.  No mystical tech that is just beyond belief.
2022-07-10 15:36:28 <KipIngram   > The science is advanced but believable.
2022-07-10 15:36:42 <KipIngram   > The tech, rather.
2022-07-10 15:37:01 <thrig       > the ships do somehow move at the speed of plot
2022-07-10 15:37:51 <KipIngram   > Yes, they don't share the dwell of cross-solar system travel.  In the books it's more clear that the appropriate length of time has elapsed, though.
2022-07-10 15:39:29 <imode       > it'd be interesting to see the details of that travel.
2022-07-10 15:40:10 <KipIngram   > They do have a "space drive" tech that makes the whole "mastery of the solar system" thing possible - the "Epstein drive."  But I actually have a theory about how that could work that is in tune with the laws of physics.
2022-07-10 15:40:45 <KipIngram   > It doesn't let them go at super speed - it mostly just lets them dodge the usual burden of having to carry a ridiculous amount of rocket fuel around with them.
2022-07-10 15:41:26 <KipIngram   > My theory is that it would work by somehow ejecting the propellant at near the speed of light, so you'd get the benefit of that exhaust becoming much more massive because of going so fast.
2022-07-10 15:41:50 <KipIngram   > Propellant would give you a lot more bang for the buck than it does in real rockets.
2022-07-10 15:42:01 <KipIngram   > So you wouldn't need as much for long missions.
2022-07-10 15:43:13 <KipIngram   > Anyway, I don't think anything I've said is a spoiler, but I'll shut up about it now.  I predict you'll enjoy it at least some.
2022-07-10 15:43:28 <KipIngram   > I'm not terribly easy to impress, with TV or with books.
2022-07-10 15:43:36 <KipIngram   > And that one sucked me in pretty good.
2022-07-10 15:43:48 <imode       > some massive accelerator on par with the LHC with some energy improvements would actually be feasible.
2022-07-10 15:43:57 <imode       > just with much larger or more consistent mass streams.
2022-07-10 15:44:07 <KipIngram   > The main problem with books these days is that I've now read that urban fantasy series The Dresden Files, and now nothing else really compares for me.
2022-07-10 15:44:18 <imode       > oh?
2022-07-10 15:44:28 <KipIngram   > Oh yeah - it's almost "too good."
2022-07-10 15:44:51 <KipIngram   > There was one season of a TV show for it back around 2005 or so, but it doesn't adhere to the books much at all; it was "ok," but the books are OUTSTANDING.
2022-07-10 15:45:16 <KipIngram   > Author is Jim Butcher - first novel is Storm Front.
2022-07-10 15:45:19 <imode       > huh, my wife's really into urban fantasy.. maybe I'll grab a copy for her.
2022-07-10 15:45:25 <KipIngram   > There are 17 novels and two short story anthologies so far.
2022-07-10 15:45:42 <KipIngram   > We're expecting about 25 novels total, with the last three being a "big apocalyptic trilogy."
2022-07-10 15:45:48 <imode       > damn.
2022-07-10 15:46:20 <KipIngram   > Yeah - he cranked out the first 15 novels in about 15 years, and then there was a big dwell, and he's taken to alternating between Dresden and another series.  I think it's not as fun for him as it used to be.
2022-07-10 15:46:27 <KipIngram   > But officially at least he's "hanging in there."
2022-07-10 15:46:43 <imode       > that always hurts. :\
2022-07-10 15:46:44 <KipIngram   > I sure hope he makes it to the end - I really want to finish this one.
2022-07-10 15:47:00 <KipIngram   > Oh yeah - the fans were climbing the walls during that long wait.
2022-07-10 15:47:09 <KipIngram   > I imagine his publisher wasn't awfully happy either.
2022-07-10 15:47:32 <KipIngram   > Surely they had financial forecasts based around that "one a year" pace he'd set for 15 years.  And then... nothing.  And more nothing.
2022-07-10 15:47:40 <KipIngram   > Then in 2020 two new ones came out.
2022-07-10 15:47:47 <KipIngram   > Those are the last two currently.
2022-07-10 15:47:58 <imode       > at least he continued. 2020 was a shakeup year for old stuff.
2022-07-10 15:48:04 <imode       > NiN did a thing.
2022-07-10 15:48:04 <KipIngram   > It was originally intended to be one, but it came in too big and the publisher had him split it.
2022-07-10 15:48:11 <KipIngram   > They're really one story.
2022-07-10 15:48:49 <KipIngram   > The series he's alternating with is called Cinder Spires; there's one book out so far called The Aeronaut's Windlass.  It's outstanding too.
2022-07-10 15:48:57 <KipIngram   > So I really look forward to seeing where that one goes.
2022-07-10 15:49:04 <KipIngram   > He's currently working on Cinder Spires #2.
2022-07-10 15:49:04 <imode       > I need to read more..
2022-07-10 15:49:25 <KipIngram   > Cinder Spires is a steampunk genre thing.
2022-07-10 15:49:37 <imode       > aha I'm into that.
2022-07-10 15:49:59 <KipIngram   > Well, try that one out too; I was really impressed with Windlass as a "first installment."
2022-07-10 15:50:27 <KipIngram   > With Dresden it took him several books to really get the "world" rolling, but I think the Spires 'verse is already "in flight."
2022-07-10 15:50:43 <KipIngram   > Of course when he wrote those first Dresden books he was young and inexperienced.
2022-07-10 15:50:52 <imode       > it's difficult to bootstrap world.
2022-07-10 15:50:53 <KipIngram   > He's matured a lot now; it's over twenty years later.
2022-07-10 15:54:41 <tabemann    > back
2022-07-10 15:58:01 <imode       > web.
2022-07-10 21:13:07 <KipIngram   > Hey, do typical direct threraded Forths have the entire code handler for definitions, variables, and so on just before the parameter field?  Or is it typically a "snip" to secure the PFA and a jump to the routine proper?
2022-07-10 21:14:06 <KipIngram   > I would argue that if it's the latter then that largely defeats any speed advantage direct threading might have - you've wound up doing two direct jumps vs. one indirect jump.
2022-07-10 21:16:00 <KipIngram   > Those routines aren't very big - I could see someone just putting a copy down in every place.
2022-07-10 21:23:26 <tabemann    > I think the whole point of direct threading is that all such stuff is copied before each definition
2022-07-10 21:23:39 <tabemann    > which is what gives its performance boost over indirect threading
2022-07-10 21:31:13 <KipIngram   > I think that would be the only way to get that boost, so I figure you're right.
2022-07-10 21:31:50 <KipIngram   > And that boost is the only reason I know to prefer direct threading, so if you gave that up you might as well have done indirect.
2022-07-10 21:32:35 <KipIngram   > I'm fairly convinced that at the very least create/does> is easier to implement if you're indirect.
2022-07-10 21:32:56 <KipIngram   > I guess may I just did it in a dumb way when I did a direct threaded version of it.
2022-07-10 21:33:06 <KipIngram   > But it sure went better the next time, when I did indirect.
2022-07-10 21:33:16 <KipIngram   > s/may/maybe/
2022-07-10 21:35:27 <KipIngram   > I've never done a code threaded system.
2022-07-10 21:41:43 <KipIngram   > I can't remember what processor it was, but a long time ago I ran into one case where direct threading was faster than code threading.  Speaking only of the threading - the subroutine call on that processor was slow for some reason.
2022-07-10 21:42:08 <KipIngram   > I know code threading offers opportunity to inline as well; that probably would have tipped things in favor of code threading overall.
2022-07-10 21:45:18 <KipIngram   > One thing to keep in mind is that when you're doing non-inlined primitives in code threading you have to call the primitive and return from it; with direct and indirect threading you just go directly from primitive A to primitive B.
2022-07-10 21:47:12 <KipIngram   > No return stack activity.
2022-07-10 21:52:43 <KipIngram   > I think if I were starting over I'd consider having a CFA/PFA table at the low address end of my body region.  Instead of storing them right by hte names in the header region.  The way I've done it this time, the definitions cells point to the CFA field IN THE HEADER.  So I can't do without the header region.  Can't have a headerless target.  The new way I'm thinking of would require an extra pointer; the two
2022-07-10 21:52:45 <KipIngram   > pointers that are in the header now would move down into the runtime region, and then I'd still have to have a pointer in the header to those.  But what it would gain me would be that everything needed to run compiled code would be in the one region, and that would be the region that would be copied to a headerless target.
2022-07-10 21:53:24 <KipIngram   > Those CFA/PFA pointers would never move, but I could move the definitions that follow them up if I needed more room.
2022-07-10 21:53:51 <KipIngram   > The definitions themselves would be completely relocatable.
2022-07-10 21:54:17 <KipIngram   > Since they would refer to one another through that CFA/PFA table.
2022-07-10 21:56:10 <KipIngram   > If I moved the definitions up N bytes to make room for more CFA/PFA pairs, I'd just adjust all the CFA's and PFA's by N.