2025-12-15 01:27:32 <vms14       > i keep wondering how do you guys manage to write large codebases or complex software with forth
2025-12-15 01:27:55 <vms14       > i understand factor and simplify, but still
2025-12-15 01:29:20 <vms14       > i have my own rpn lang and it's a write only language, even the most simple program looks quite weird
2025-12-15 01:29:25 <vms14       > https://termbin.com/bcd2
2025-12-15 01:29:36 <vms14       > for example that code just shows a random verse
2025-12-15 01:29:56 <vms14       > http://wewill.getenjoyment.net/oh.html
2025-12-15 01:30:29 <vms14       > that's the code running in the browser
2025-12-15 01:33:51 <vms14       > i always ask myself why people can use forth for complex stuff and my language chokes with the most simple thing
2025-12-15 01:34:47 <vms14       > i understand that they are completely different things, and always wondered if the simplicity of forth is what allows it to work, but i wonder if it's more about the programmer getting discipline
2025-12-15 01:51:12 <tpbsd       > vms14, I'm additcted to Forth since 2014 but I only use it with dedicated self contained microprocessors, I havent used Forth on the PC to write applications and would probably use Scheme for that
2025-12-15 01:52:09 <tpbsd       > vms14, but for making devices as above, Forth is unbeatable because of it's REPL that gives me real time control of microprocessor devices
2025-12-15 01:53:59 <tpbsd       > sure you can also do that with python, elisp etc, but they require many more memory resources than forth, which in the case of Mecrisp-Stellaris fits in 20KB of flash and 1.5kb ram on STM32 mcu's
2025-12-15 01:54:48 <tpbsd       > all the non Forth programs that will run on those devices with a REPL need at least 150kb of flash and tons of ram
2025-12-15 01:55:14 <tpbsd       > so the choice is very clear, in this domain, there is only Forth
2025-12-15 01:58:46 <tpbsd       > vms14, tho if I dont use Scheme or Racket on the PC, I much use crc's 'Retro' as that looks awesome, and he uses it the way I used to use shell
2025-12-15 02:12:05 <vms14       > yeah but i know some people has created complex software and applications with it
2025-12-15 02:12:35 <vms14       > still it might be true that it's not the best language for that and that it will fight you a lot
2025-12-15 02:13:44 <vms14       > my language is entirely different though, and always wondered why my lang is useless for more than a hello world and forth isn't
2025-12-15 02:17:10 <tpbsd       > vms14, I have a theory, but as I'm not a real programmer but a retired rlrctronics guy I could be wrong; I think that forth is mainly useful for 'lone wolfs' and not for the kinds of large groups that make complex software, where langs like C rule
2025-12-15 02:18:06 <vms14       > yeah but still i wonder how they actually achieve to create something more than a hello world application with forth
2025-12-15 02:18:29 <vms14       > i understand the rules of factoring and simplifying, but still, isn't it a pain anyways?
2025-12-15 02:18:51 <vms14       > the main reason you factor and simplify is because everything is painful enough so you better not add more complexity
2025-12-15 02:19:15 <vms14       > and it forces you to avoid complexity as much as possible
2025-12-15 02:19:56 <vms14       > you strip everything and get to the minimal requirements that are really true, i think that's the philosophy at the end
2025-12-15 02:20:33 <vms14       > then you create tiny words extending the language to create a vocabulary until the program can be expressed in that new language
2025-12-15 02:24:40 <tpbsd       > vms14, all accurate, but some vital points are missing imho
2025-12-15 02:25:44 <tpbsd       > vms14, for instance I used C and assembly for 15 years before I learned forth, and before Forth I never *wanted* to factor and simplify
2025-12-15 02:26:54 <tpbsd       > vms14, in fact for a decade after I learnt Forth I didnt want to factor or simplify and I didnt relly know how
2025-12-15 02:28:03 <tpbsd       > but slowly I developed a *desire* to simplify and factor, it just grew within me, it had a life of it's own. It was fun, not work
2025-12-15 02:29:02 <tpbsd       > I could spend a week factoring a complex Word and if I succeeded, I was filled with joy, my endorphins would have a party
2025-12-15 02:29:32 <nmz-        > that's because C based languages penalize factoring
2025-12-15 02:29:34 <tpbsd       > and so Forth passed from 'work' into 'the way' for me
2025-12-15 02:31:15 <tpbsd       > vms14, I'm no expert, but I do know that the Forth 'aha moment' can take time, it took a decade for me, maybe you just need more time, and to use proper forths so the penny will drop ?
2025-12-15 02:32:07 <tpbsd       > nmz-, you must be right, while C was easy, I felt no joy after building projects with it. It was more like laying bricks for me
2025-12-15 02:32:25 <nmz-        > especially because of ()
2025-12-15 02:32:42 <vms14       > yeah we were told that function calls were expensive so we would never think about abusing them
2025-12-15 02:33:12 <vms14       > in forth they tell you not only that they are cheap, but that it's the only way
2025-12-15 02:33:18 <tpbsd       > nmz-, yeah, I love the Forth DSL syntax, it's 100% problem solving language for me
2025-12-15 02:33:28 <nmz-        > apparently c compilers can inline, so you can factor
2025-12-15 02:33:37 <nmz-        > but any other interpreted language does not
2025-12-15 02:33:50 <nmz-        > if it cannot inline, you should not factor
2025-12-15 02:33:57 <tpbsd       > vms14, yes, I have found that to be true, along with very short Words
2025-12-15 02:34:02 <nmz-        > reminds me of that meme with the 10k line function
2025-12-15 02:34:46 <nmz-        > it also copies parameters even when it shouldn't
2025-12-15 02:34:56 <tpbsd       > I use Mecrisp-Stellaris which has automatic inlining
2025-12-15 02:35:21 <nmz-        > if you are not modifying a parameter, why do C languages copy them?
2025-12-15 02:35:29 <tpbsd       > Im a Forth user, being a hardware guy, Im not a real programmer
2025-12-15 02:36:04 <tpbsd       > and Im definitely not a Forth implementer
2025-12-15 02:37:06 <nmz-        > That's what I've noticed, forth folks are usually hardware people
2025-12-15 02:41:36 <tpbsd       > nmz-, my experience has been that theyre mostly software, tho a lot thik they have hardware skills. just ask them to describe their soldering skill to check
2025-12-15 02:42:27 <tpbsd       > nmz-, tho I must admit, nicks like KipIngram and veltas are definitely hardware experts
2025-12-15 02:43:12 <tpbsd       > but theyre rare I find, perhaps times are a changing ?
2025-12-15 02:44:25 <tpbsd       > nmz-, Forth people *should* be hardware guys, after all Forth was invented to control telscopes, a very hardware oriented use
2025-12-15 02:45:32 <tpbsd       > but for me sadly, Forth seems to attract all the software people who are making their own language for the first time, and Forth is chosen as it's the easiest of all
2025-12-15 02:46:27 <tpbsd       > nmz-, look at github ? hundreds of forths and about 4 actually work, the rest are unfinished or plain stupid
2025-12-15 02:49:39 <vms14       > yeah i'm one of the guys who came to forth because it shown me how what a concat lang is and how i could manage to create one myself
2025-12-15 02:50:21 <vms14       > which has nothing to do with forth though, but i stole some concepts like the stack, rpn and immediate words although they are quite different
2025-12-15 02:50:58 <tpbsd       > vms14, and it's perfectly understandable, who wouldnt choose the easiest language to make their first one ?
2025-12-15 02:51:17 <vms14       > i think a concat lang is the best introduction to making interpreters
2025-12-15 02:51:37 <tpbsd       > vms14, but Forth tho easy to learn is very hard to master, it takes a long time
2025-12-15 02:51:41 <vms14       > but i cry a lot because my lang is quite useless and incredibly hard to do anything with it
2025-12-15 02:52:18 <tpbsd       > vms14, just keep learning and revising until you get there ?
2025-12-15 02:52:45 <vms14       > xd i wonder, i see how it has been evolving and becoming slightly more useful but meh
2025-12-15 02:53:13 <vms14       > that's my current implementation in js btw
2025-12-15 02:53:16 <vms14       > https://termbin.com/wy38
2025-12-15 02:53:26 <tpbsd       > vms14, in fact default Forth is useless for todays embedded devices, utterly useless
2025-12-15 02:53:31 <vms14       > but it's very different from forth
2025-12-15 02:54:03 <tpbsd       > Ive had to make a post-processor to make forth as easy to use as C in embedded
2025-12-15 02:54:55 <tpbsd       > electronics technology has moved on, and programmers arent aware of that
2025-12-15 02:54:55 <vms14       > yeah i keep asking myself, is my language useless because of rpn or because it does not have a proper design
2025-12-15 02:55:26 <vms14       > and always keep answering "well, forth can be used for serious stuff, your shitty interpreter can't, so might not be just rpn"
2025-12-15 02:55:40 <tpbsd       > vms14, I cant answer that, you'd need an experienced  'forth implementer' to do that
2025-12-15 02:56:23 <tpbsd       > vms14, your question is way out of my sphere of exprience and expertise
2025-12-15 02:57:49 <tpbsd       > frustration does drive one to achieve more tho ?
2025-12-15 02:59:17 <vms14       > it pushes me to make a lisp interpreter, then i cry because it's slow and i do not have the skill to optimize it, then i come back to the rpn lang again to repeat the cycle
2025-12-15 02:59:55 <tpbsd       > have you read https://www.bradrodriguez.com/papers/ ? you may find his expertise helpful
2025-12-15 03:00:04 <vms14       > i guess i did
2025-12-15 03:00:07 <vms14       > let me chek
2025-12-15 03:00:09 <vms14       > check*
2025-12-15 03:01:10 <vms14       > i guess i read that long time ago, but using a high level language to implement forth is not a good idea
2025-12-15 03:01:42 <vms14       > it can be done, but you are going to pretend memory is an array and so on, downgrading the language to meet forth expectations of being written in assembly
2025-12-15 03:01:56 <tpbsd       > vms14, the Forth I use is 100% written in cortex-m assembly language, by the author who thinks in assembly and heavily optimised, so it's as fast as can be expected I think
2025-12-15 03:02:29 <tpbsd       > yeah, all the slow forths I've seen were written in some hll
2025-12-15 09:11:27 <KipIngram   > vms14: The biggest limitation of an hll Forth is that you can't really use the processor registers properly.  Things that  you'd normally keep in registers are in variables instead, unless the compiler happens to put some of them in registers.  You can circumvent the "RAM is an array" problem using gcc, but you can only ask it politely to make variables be saved in registers - it won't necessarily
2025-12-15 09:11:29 <KipIngram   > comply.
2025-12-15 09:12:10 <KipIngram   > I'm unaware of any other hll that will let you dodge the RAM = array issue.
2025-12-15 09:14:36 <KipIngram   > I should clarify - your RAM actually is still allocated via an array, but you don't have to access it by indexing that array.  You can arrange for it to be accessed in a proper native way.  And the advantage gcc gives you vs. other C compilers is that you can arrange for the inner interpreter to work in the correct way, using gcc's "pointer to labels" extension.
2025-12-15 09:15:10 <KipIngram   > I've actually built one of these and made it work.
2025-12-15 09:16:03 <KipIngram   > It was horribly ugly code to read, though.  I tried to be clever and use C macros, and at first that worked pretty cleanly.  But by the time I was done implemented CREATE/DOES> and so on it was hideous.
2025-12-15 09:16:34 <KipIngram   > I shared the source with a couple of acquaintances in another channel at one point and they ridiculed me for weeks.
2025-12-15 09:17:03 <KipIngram   > Not over how it worked, but rather over how the C source looked.
2025-12-15 09:17:47 <KipIngram   > I scrapped it because it got to hard to work on.  Did the next one in nasm.
2025-12-15 09:18:11 <KipIngram   > And once you've done that there's really no going back.
2025-12-15 09:19:12 <KipIngram   > You solve all the technical limitations, but you also can suddenly have beautiful source layout.
2025-12-15 09:20:12 <KipIngram   > You can harness nasm's macros to do basically all of the dictionary construction, and you can use sections to organize the source super nicely.
2025-12-15 09:25:38 <tpbsd       > KipIngram, Mecrisp-Stellaris (written in assembly) makes extensive use of macros also, the source is neat and tidy, well commented and easy to read
2025-12-15 10:11:00 <KipIngram   > I haven't seen it, but it's not surprising.  Honestly I was amazed at how nice I was eventually able to set it all up.  Even though my headers and bodies are in separate RAM regions, I'm still able to put all of the code for each word in one tidy little place, and it "almost" reads like Forth definitions themselves.  I usually write the Forth for a word as a comment, and then put the macro calls
2025-12-15 10:11:02 <KipIngram   > relatd to that word right underneath.  Nasm's ability to have macros that take any number of parameters helps quite a lot.
2025-12-15 10:12:02 <KipIngram   > All of the section juggling to make that work is in the macro definitions, so once they're written it all just takes care of itself.
2025-12-15 10:13:44 <KipIngram   > I've not used any of the Mecrisp stuff, but everything I've learned about it is really impressive.  Looks like a really excellent tool set.
2025-12-15 10:34:41 <tpbsd       > Mecrisp-Stellaris is a work of assembly art, tho 'mecrisp' is the origonal and for the MSP430, while Mecrisp-Stellaris is a port to the cortex-m
2025-12-15 10:35:03 <tpbsd       > the author loves MSP430, doesnt like Cortex-M
2025-12-15 10:35:47 <tpbsd       > I've always loved assembly and I think when done properly, it's beautiful, as good as any code Ive seen
2025-12-15 10:36:56 <tpbsd       > I started in embedded in 1975 writing machine code and didnt get an assembler until 1984, and I thought i'd gone to heaven as assembly was so easy and has all the aids a programmer needs
2025-12-15 10:38:00 <tpbsd       > machine code by hand on a hex keypad and 7 seg display really sucks, I made a zillion errors I had to fix for the one commercial job I did with it
2025-12-15 10:38:50 <tpbsd       > then the next commercial job was with the 6800 assembler and it was smooth as silk, everything worked, even guestimations were in the balparks
2025-12-15 10:39:06 <tpbsd       > I loved doing it
2025-12-15 10:39:53 <tpbsd       > then I got into C and that was ok, but Forth caused me to really love the code again, as I did with assembler
2025-12-15 10:40:39 <tpbsd       > mainly as Im always dissasembling my Forth code to make sure it meets my standards
2025-12-15 10:40:56 <tpbsd       > so Im always neck deep in assembly anyway
2025-12-15 11:09:04 <KipIngram   > Yes - I first got exposed to assembly in a college course that used the 6809 (great little chip), and it always just felt totally natural to me.
2025-12-15 11:10:30 <KipIngram   > If I had to work directly with machine code I could, but I've never had to do that in any sort of "volume" way.
2025-12-15 11:11:37 <KipIngram   > As far as the actual binary you create goes, machine code and assembly are the same thing.  The assembler just saves you an awful lot of tedious work.
2025-12-15 11:13:01 <KipIngram   > And Forth is just much closer to that than other hll's are - it's usually very clear exactly what you're laying out in RAM when you write Forth.
2025-12-15 11:13:17 <KipIngram   > You feel "in contact" with the actual image in a way you don't with, say, C.
2025-12-15 11:15:05 <KipIngram   > I had an acquaintance at one time who insisted on referring to Forth as a "glorified macro assembler."  I disagree with that for a variety of reasons, but I do at least see what he was trying to get at.
2025-12-15 11:15:33 <tpbsd       > he was wrong imho, Forth is in no way like he claimed
2025-12-15 11:15:49 <KipIngram   > I imagine that's exactly why a lot of people don't like it - it doesn't feel "rarified" enough to suit them.
2025-12-15 11:16:02 <KipIngram   > Well, I agree with you - I think Forth is much more than that.
2025-12-15 11:16:43 <KipIngram   > But I do think it has the same sort of "right up against the hardware" feel.
2025-12-15 11:17:00 <tpbsd       > my problem with machine code was always having to enter the same hex codes, no shortcuts and because jump offset varied depending on up or down, I was always making stupid errors
2025-12-15 11:17:21 <KipIngram   > At least it does for me - when I write Forth I'm always very conscious of precisely what I'm doing to the RAM image, the other hardware, etc.
2025-12-15 11:17:44 <tpbsd       > oh yeah, Forth is almost assembly, and Im constantly checking the assembly of Words I build anyway
2025-12-15 11:18:39 <tpbsd       > but I guess the one constant is that Forth is different for everyone, and varies with every DSL
2025-12-15 11:19:23 <tpbsd       > the fast that Forth varies so much is perhaps why it suits lone wolf coders, we make it into exactly what we want
2025-12-15 11:19:31 <KipIngram   > Yes - that's what makes it "more."  It can just be extended far, far further than you could get with an assembler.  Not so much in "what you can do" - you can do anything in assembler - but in terms of how it feels to use it after you've built it.
2025-12-15 11:19:46 <KipIngram   > And of course it's interactive.
2025-12-15 11:20:17 <KipIngram   > You don't just "code in Forth" - you WORK in Forth too.
2025-12-15 11:20:35 <tpbsd       > in my case I use the post-processor I designed so that I can refer to registers and bitfields using the CMSIS-SVD syntax, Ive made Forth into what I need
2025-12-15 11:21:12 <tpbsd       > yeah, it's said that 'no one codes in Forth' rather people make their own DSL out of Forth
2025-12-15 11:21:44 <veltas      > Local vars are totally legit in Forth code, but rarely necessary.  A good Forth env allows you to add locals or whatever half-way thing is necessary for the task
2025-12-15 11:21:58 <veltas      > But you may need to do some of the legwork
2025-12-15 11:22:20 <tpbsd       > I started developing an adversion to vars after a couple of years, hard to explain
2025-12-15 11:22:56 <veltas      > When code is purpose built and factored it shouldn't have lots of locals
2025-12-15 11:23:10 <veltas      > Is my attempt to explain
2025-12-15 11:23:25 <tpbsd       > and I've develped a love for what people describe as 'stack gymnastics' but I dont call it that any more than id call a chess game 'chess gymnastics'
2025-12-15 11:23:51 <veltas      > If you use locals a lot then you may be using an unnecessary feature and writing more code than necessary
2025-12-15 11:24:05 <veltas      > But if you want that comfort then go for it
2025-12-15 11:24:07 <KipIngram   > I enjoy it when a clever path is evident, but it definitely can feel like a jam-up at times.
2025-12-15 11:24:29 <tpbsd       > I've come to the conclusion that in Forth the secret is the stack, that a love of the stack is what makes a Forth addict
2025-12-15 11:24:43 <KipIngram   > I can't disagree with that.
2025-12-15 11:24:47 <veltas      > I'd rather people used locals than not use Forth at all
2025-12-15 11:24:50 <veltas      > Agreed
2025-12-15 11:25:25 <KipIngram   > My very first programming experience was with an HP-41CV calculator.  So I baked "stack thinking" into my head before I ever got corrupted by anything else.
2025-12-15 11:25:47 <KipIngram   > So it feels totally natural to me to think that way.
2025-12-15 11:26:00 <tpbsd       > I love challenges and mysteries and refining the stack ops as much as possible is great fun for me
2025-12-15 11:26:34 <veltas      > The stack is point-free and good at factoring code
2025-12-15 11:26:56 <KipIngram   > And that calculator just had a four-element stack, so it was a pretty snug environment to have to live in.  And I hated - HATED - to get forced to use a "register" (calculator equivalent of a variable) to make something work.
2025-12-15 11:27:22 <tpbsd       > as a tech, I love fixing electronic faults, repairing gear, it's like a good mystery book and finding the murderer by using the clues, designing the Forth stack is like that for me also
2025-12-15 11:27:26 <KipIngram   > Unless I was putting something in it that actually needed to hang around for a while.
2025-12-15 11:27:45 <veltas      > I actually wrote a Forth initially after realising what I was trying to do in 8-bit asm was essentially a two stack model
2025-12-15 11:28:04 <veltas      > And I was using 2 stacks to save code space
2025-12-15 11:28:05 <KipIngram   > Yes, debugging a faulty circuit, when you understand the circuit well, is a particular kind of fun.  It IS like detective work.
2025-12-15 11:28:27 <KipIngram   > On the other hand, debugging someone else's work that you're not familiar with is a pain in the rear.
2025-12-15 11:28:43 <KipIngram   > Debugging - wrong word.  Fixing a defect.
2025-12-15 11:29:08 <KipIngram   > I far, far prefer to do that kind of work on my own designs rather than some unfamiliar thing.
2025-12-15 11:29:33 <tpbsd       > actually once I learned to deconstruct the stack piece by piece and analyse it, I started understanding the forth code of other people
2025-12-15 11:29:38 <KipIngram   > And it's the same for me with software.  If I wrote it, I know exactly what's supposed to be happening and I can REASON about it.
2025-12-15 11:29:53 <KipIngram   > If someone else wrote it, then who knows what they had in mind.
2025-12-15 11:30:01 <KipIngram   > Usually something different from what I would have done.
2025-12-15 11:30:23 <veltas      > tpbsd: Yeah, if you want to collab or read Forth you must be used to writing with the stack
2025-12-15 11:30:29 <tpbsd       > if one deconstructs the stack, then one knows what they wanted, for me it's been a real eye opener
2025-12-15 11:31:13 <veltas      > Also there are lots of equivalent ways to shuffle stack, but some are neater than others
2025-12-15 11:31:21 <tpbsd       > until I started doing that I couldnt understand any complex Forth code, it was all a mystery
2025-12-15 11:31:29 <KipIngram   > See, this is where the fact that I'm not actually a programmer by training comes in.  I've never worked in a collaborative software environment.  I've really only ever worked with my own code for the most part.  Very limited exceptions.
2025-12-15 11:31:50 <KipIngram   > And 95% of the code I've written in my life never got looked at by anyone other than me.
2025-12-15 11:32:10 <KipIngram   > It would usually be a tool for getting my own work done.
2025-12-15 11:32:11 <tpbsd       > yes, thats the one thing I love and I find when the stack 'looks right' the code is optimum
2025-12-15 11:32:22 <tpbsd       > KipIngram, Im the same
2025-12-15 11:32:32 <KipIngram   > Oh yes - you can just "feel it" when you've landed on the "right approach."
2025-12-15 11:32:40 <tpbsd       > no one sees my code, theyre not interested, only Im interested
2025-12-15 11:32:45 <KipIngram   > It has a "grace" that's just missing otherwise.
2025-12-15 11:33:27 <tpbsd       > yeah, writing good stack ops is like designing a aircraft, as they say 'when the aircraft looks beautiful, it will fly'
2025-12-15 11:33:43 <KipIngram   > Doubly linked lists in Forth felt that way to me.  I fuddled around with it for quite a while, getting ugly solution after ugly solution, until finally it just kind of fell into place, and I was like "Ah, THAT'S it."
2025-12-15 11:33:45 <tpbsd       > exactly! great choice of word
2025-12-15 11:34:48 <tpbsd       > when you see the smooth symetry and the balance, you just feel the correctness
2025-12-15 11:35:16 <tpbsd       > it jumps out at me and yells 'im right, I'm perfect'
2025-12-15 11:35:51 <tpbsd       > as opposed to being plain ugly and horrible
2025-12-15 11:37:15 <tpbsd       > so when some Forth user tells me they hate 'stack gymnastics' and always use vars, I know they just dont 'get' Forth yet, for them the 'penny hasnt dropped' yet
2025-12-15 11:38:21 <KipIngram   > One thing I think some people, coming to Forth from other languages, miss is that it's really not true that definitions are "isolated" from oen another.  In a case where someone has one of those ugly words, they're apt to think "I'll just re-write that later."  But there's more to it than that.  Things like the order you arrange your arguments on the stack, way up at the top level, ripple all up
2025-12-15 11:38:23 <KipIngram   > and down through your call stack.  There is a  "global" element to the design, and that needs to be right too to get that happy solution.
2025-12-15 11:38:43 <KipIngram   > In C the order of arguments in a function don't really matter.  But in Forth argument order matters a LOT.
2025-12-15 11:38:57 <KipIngram   > s/don't/doesn't/
2025-12-15 11:39:25 <tpbsd       > absolutely !
2025-12-15 11:39:36 <KipIngram   > So Forth code is more "vertially integrated" than you find in other languages.
2025-12-15 11:39:43 <KipIngram   > vertically
2025-12-15 11:40:22 <tpbsd       > Ive had to alter the sequence of my parameters many times to get the optimal word and simplest stack ops, thats the kind of factoring I do all the time
2025-12-15 11:40:24 <KipIngram   > I tend to think of "small groups of words" as my basic "unit" of programming.
2025-12-15 11:40:43 <tpbsd       > same here
2025-12-15 11:41:40 <KipIngram   > And I like short definitions, so I try to make those groups form little rectangles on the screen, with a nice aspect ratio, so that my eye can take in the whole group AS a unit.
2025-12-15 11:41:58 <tpbsd       > I now write lots of small words compared to when I started and I like anyone coming from a decade of embedded C to forth, was writing very long Words
2025-12-15 11:41:58 <KipIngram   > A bad consequence of that is that I don't comment enough, because that "spreads the code apart."
2025-12-15 11:42:33 <KipIngram   > Me too.  It took a while to take hold, but it eventually did.
2025-12-15 11:42:42 <tpbsd       > KipIngram, I have a solution at last for that (in my case)
2025-12-15 11:42:54 <KipIngram   > I've got an idea for a solution.
2025-12-15 11:42:58 <KipIngram   > Haven't implemented it yet.
2025-12-15 11:43:24 <KipIngram   > I just want to have a way of separating the comments from the code, and also I want an editor that will let me toggle inline comments on and off.
2025-12-15 11:43:39 <tpbsd       > because I use Fossil as my SCM, and Fossil has built in Wiki and flowcharting (pichr) I do all my doc in the wikis
2025-12-15 11:44:12 <KipIngram   > I imagine an environment with that inline visibility toggling and also a "hyperlink" style structure that will let me set up levels of documentation in a wiki like way.  Linked to right from the source.
2025-12-15 11:44:17 <tpbsd       > and the docs refer to the code, rather than being embedded in it
2025-12-15 11:44:53 <tpbsd       > exactly! the Fossil wiki hyperlinks allow all kinds of doc use
2025-12-15 11:45:17 <KipIngram   > So, simplest comments inline with visibility toggling, slightly more verbose comments at the first wiki level, and further wiki levels evolving toward full "tech ref" status.
2025-12-15 11:45:50 <tpbsd       > Ive always like flowcharts, and 'Pichr' is easy to use and it also embeds with hyperkinks etc
2025-12-15 11:45:57 <KipIngram   > I LIKE writing descriptions of how things work.  I just hate uglying up  my source.
2025-12-15 11:46:06 <tpbsd       > yeah, same
2025-12-15 11:46:17 <tpbsd       > I love good doc
2025-12-15 11:46:57 <tpbsd       > and also hate messing up the source, but with Fossil I dont need to
2025-12-15 11:47:44 <tpbsd       > the only downside is Im used to VIM style editing and the Fossil wiki editor is quite plain and RSI inducing
2025-12-15 11:48:41 <tpbsd       > I wish that the old free online Fossil server ws still up so I could link some url's to show you what I mean
2025-12-15 11:49:57 <tpbsd       > the fact that Fossil has a built in web server means that all the doc, flowcharts and pics can be viewed in a browser, nothing special needed
2025-12-15 13:20:45 <KipIngram   > Right - when I get around to writing mine I will definitely use vim-ish key bindings in my editor.
2025-12-15 13:22:02 <KipIngram   > Though my most in-depth plans involve using a keyboard manager based on key press/release events, and I want to do some things with that you can't do with character-based key handling.  Things like double taps of the shift/control keys, etc.
2025-12-15 13:22:21 <KipIngram   > For things that you might typically do with mouse clicks.
2025-12-15 13:22:40 <KipIngram   > I've looked at how Acme works, and kind of think about a "keyboard oriented" version of that.
2025-12-15 13:23:03 <KipIngram   > I'm a huge fan of never (or almost never) having to move my hands away from home typing position.
2025-12-15 15:17:16 <veltas      > crc: I have been thinking (i.e. not actually doing) about making a virtual mainframe or minicomputer experience and I thought it would be fun to make up a computer with e.g. konilo as the arch
2025-12-15 15:18:57 <veltas      > What do you think would suit konilo, a minicomputer size like early PDP 11-20 or bigger e.g. IBM 360?
2025-12-15 15:20:30 <veltas      > Just having fun thinking about it
2025-12-15 15:26:37 <veltas      > It's not very 'realistic' but I have some artistic licence I think
2025-12-15 15:30:12 <KipIngram   > I'm only vaguely familiar and it's been decade since I really looked, but I want to say the PDP-11 had a lot more streamlined instruction set than the IBM 360.
2025-12-15 15:30:30 <KipIngram   > Someone here in the channel - one of the long time guys - is familiar with the 360, I want to say.
2025-12-15 15:41:08 <veltas      > KA11 was very simple, flexible, took up 2 slots in PDP 11-20
2025-12-15 15:42:05 <veltas      > Not really 'RISC', allowed stuff like mem to mem moves I think
2025-12-15 15:42:27 <veltas      > Not that you said that
2025-12-15 15:43:58 <veltas      > UNIBUS backplane
2025-12-15 15:51:51 <veltas      > What's great is we can go look at the manuals for all of these old computers, especially the successful ones
2025-12-15 15:51:58 <veltas      > So many archives
2025-12-15 16:16:53 <crc         > veltas: apart from word size and ram, the PDP-11/20 is probably a close conceptual match than the 360.