2024-09-04 00:09:26 dlowe: I'm not sure that's true specifically of Carmack, who is probably the single person most responsible for the industry's transition from games to game engines 2024-09-04 00:24:05 a lot of early game dev wasn't a case of writing neat code 2024-09-04 00:24:12 it was a case of getting the game to work at all 2024-09-04 00:24:55 lots of short definitions is great for a flexible codebase 2024-09-04 00:24:59 it's not good for performance 2024-09-04 00:58:10 in that page, Carmack is in the early 02000s talking about moving *away* from using lots of short definitions as performance became more critical, and said: 2024-09-04 00:58:41 > In no way, shape, or form am I making a case that avoiding function calls alone directly helps performance. 2024-09-04 00:59:20 specifically what he's talking about is the flexibility/bug-prone-ness tradeoff 2024-09-04 00:59:44 tbf stack machines are excellent at function calls 2024-09-04 01:00:51 he was using C on i386 tho 2024-09-04 01:01:04 well, C++ I think 2024-09-04 01:01:29 im fairly sure doom is c 2024-09-04 01:01:33 not sure about quake 2024-09-04 01:01:54 my point is that if you're on a stack machine, lots of small functions makes sense 2024-09-04 01:02:27 if you're on a register machine and you're doing full stack frames for every call, it doesn't (unless your compiler is good at inlining) 2024-09-04 01:06:39 or unless, as in this case, you have other considerations that are more important than that amount of performance 2024-09-04 01:45:11 https://en.wikipedia.org/wiki/Id_Tech_4 says, "id Tech 4 began as an enhancement to id Tech 3. During development, it was initially just a complete rewrite of the engine's renderer, while still retaining other subsystems, such as file access, and memory management. The decision to switch from C to the C++ programming language necessitated a restructuring and rewrite of the rest of the engine; today, while 2024-09-04 01:45:17 id Tech 4 contains code from id Tech 3, much of it has been rewritten." 2024-09-04 01:45:27 which is a little before the time frame of those emails 2024-09-04 04:19:46 How would switching from C to C++ **necessitate** a change in architecture? Isn't more or less all of C part of C++? 2024-09-04 04:21:11 Even if there were a few necessarty tweaks I wouldn't expect it to force an architectural redesign. My bet is that someone WANTED to redesign it and that was a warm and fuzzy thing to call up as a reason. 2024-09-04 04:22:31 I wouldn't even see a NEED to switch from C to C++ unless you were planning significant changes that required the C++ capabilities. 2024-09-04 05:10:03 KipIngram: yes, at most you might have to rename a few identifiers whose names are C reserved words, especially in 02007 2024-09-04 05:11:02 nowadays the languages have diverged a bit more, but I still can't think of any major architectural decision you could take in C that C++ would force you to undo 2024-09-04 05:11:17 maybe strongly suggest it, for example with const correctness 2024-09-04 12:56:50 the purpose of a for loop is incrementing i by +1 or by +step at each iteration, with +LOOP we break this solid construct, allowing incrementing i even with a negative number, causing an infinite loop, so, why +LOOP exists at all? 2024-09-04 12:56:55 is it really useful? 2024-09-04 14:11:49 rendar: If negative steps cause problems just don't use them. It's "Forthy" to forego explicitly checking for and preventing that sort of thing - such checks would carry overhead, and it's easy enough just to think of them as something for the programmer to avoid. I see it as the same sort of mistake as an overflow error on addition. Forth doesn't usually catch those either (Gforth doesn't - I 2024-09-04 14:11:52 just checked). 2024-09-04 14:12:36 A negative step is even easier to avoid than an overflow; an overflow might "sneak up on you" in an algorithm, but that step is an explicit number that you code in. 2024-09-04 14:13:43 So I put it in the "Don't do that" category. 2024-09-04 14:41:27 why would a negative step cause an infinite loop? 2024-09-04 14:42:55 are you telling me you've never written "for (i = n - 1; i >= 0; --i)" or similar in another language? 2024-09-04 14:54:49 KipIngram: In that case, it goes into my "must be done" category. :) 2024-09-04 15:08:53 zelgomer: I think they mean if it's going wrong direction, rather than 'negative' 2024-09-04 15:09:40 What's funny is on my 8-bit machine a misdirected step hangs a little, and then comes back 2024-09-04 15:09:43 On a 32-bit machine the same 2024-09-04 15:09:49 On 64-bit, don't hold your breath! 2024-09-04 15:10:32 Is there a point in this? Maybe 64-bit is too big? Who knows 2024-09-04 15:31:13 the question was wgy +loop exists at all. seems more general than just about loops going in the wrong direction. 2024-09-04 15:32:48 anyway, i don't like do/?do/loop/+loop so i guess my answer is none of them need to exist. they're too clunky imo. 2024-09-04 16:00:30 What do you think zelgomer, ought 32-bit to be enough for anyone? 2024-09-04 16:12:33 i don't know why they didn't just start at 128 bits 2024-09-04 16:13:17 why waste everyone's time with decades of insufficiently wide bus architectures?? 2024-09-04 16:18:38 well, during the 32-bit era, having 128-bit pointers would have been an incredible waste of ram 2024-09-04 16:19:20 not to mention having to align on 16-byte boundaries 2024-09-04 16:20:17 it's just money, essentially 2024-09-04 16:20:33 veltas: Yeah, that's what I'd expect. It'd still "work" - still do what you told it to do, and would eventually find its limit satisfied. 2024-09-04 16:25:37 128 bit pointers are still an incredible waste of ram 2024-09-04 16:25:44 arguably 64 bit pointers are too 2024-09-04 16:25:54 most things don't need more than 4G of ram 2024-09-04 16:26:16 which is why we have things like x32 2024-09-04 16:30:40 Don't need x32, lots of high-performance code uses 32-bit offsets for everything 2024-09-04 16:30:55 Which has minimal or no processing overhead depending on how this is done and makes performance gains by increased locality, less cache thrashing 2024-09-04 16:38:10 on a completely unrelated note i hate writing comparisons in asm 2024-09-04 16:40:24 I could see having 64-bit everyething except address space. 2024-09-04 16:40:39 "ought 32-bit to be enough for anyone?" - at least for me, I've only ever needed larger values a couple of times, and could have done those using double cell math instead of a native 64-bit type. 2024-09-04 16:41:29 it's nice being able to copy 64 or 128 bits at a time. 2024-09-04 16:41:48 work with 64 bit integers instead of 32 bit 2024-09-04 16:43:07 dlowe: that's basically what x32 is 2024-09-04 16:43:22 amd64 registers and instructions but with a 32 bit address space 2024-09-04 16:44:04 i do think it's important to separate data handling and memory addressing 2024-09-04 16:44:46 because while yes most machines in the 32 and 64 bit era use the same word size for both 2024-09-04 16:44:58 you don't necessarily have to 2024-09-04 16:45:50 guys where is the complexity of making a transpiler/compiler? 2024-09-04 16:46:44 I always seen it as an extremely complex task, but I got started with a simple lang design and I fail to see that complexity that scared me so much 2024-09-04 16:47:40 a simple language is gonna have a simple compiler 2024-09-04 16:47:54 it's when you start doing things like type systems and optimisations that it gets fnarly 2024-09-04 16:48:07 oh type inference might be 2024-09-04 16:48:28 type theory is an entire branch of maths in and of itself 2024-09-04 16:48:29 and optimization I suppose is the most complex part 2024-09-04 16:49:52 "The Programming Languages Zoo" https://plzoo.andrej.com/ 2024-09-04 16:50:21 ty amby, I wasn't able to see the complexity 2024-09-04 16:50:21 because I will avoid both things xd 2024-09-04 16:50:40 the only problem I have to solve now is to add semicolons properly 2024-09-04 16:50:40 "a simple language is gonna have a simple compiler" I don't agree, if you want an optimising compiler 2024-09-04 16:51:12 e.g. brainfuck is trivial to write a compiler for, but might as well be as complicated as LLVM if you add optimisations 2024-09-04 16:51:38 in my case I'm using lisp so the parser comes for free 2024-09-04 16:51:39 And there is a world of difference as you go for more and more sophisticated optimisations 2024-09-04 16:51:42 this is a test 2024-09-04 16:51:43 https://termbin.com/6thc 2024-09-04 16:51:59 and the code it generates 2024-09-04 16:52:00 https://termbin.com/r5ck 2024-09-04 16:52:26 no indentation and I explicitly add semicolons with the (pr ) operator 2024-09-04 16:52:50 I think I misunderstood what you meant by transpiler 2024-09-04 16:52:54 this is why the second function does not have semicolons, because I forgot to add that 2024-09-04 16:53:08 Or what you said rather, the fault is mine 2024-09-04 16:53:30 but the whole implementation is short 2024-09-04 16:53:31 https://termbin.com/sfny 2024-09-04 16:53:38 That would be simple yeah 2024-09-04 16:53:55 But you're basically taking a small language and converting to a language that can represent most of it nicely 2024-09-04 16:53:58 when i read transpiler, i think of a program that translates source code from one (usually high level) language to another 2024-09-04 16:54:04 veltas yeah I suppose is a "toy" transpiler xd 2024-09-04 16:54:25 and i reckon most of the difficulty there is in determining the semantic equivalence between some minimal unit of execution (ie. an instruction, a statement, a block) and variables in a source language and a target language 2024-09-04 16:54:48 oh if you're doing lisp->js that's not too bad 2024-09-04 16:54:58 but it seems to do the same as parenscript does, which is a transpiler of a subset of common lisp, yet this is like 10% of the code of parenscript or less 2024-09-04 16:56:06 idk I always was super scared of trying, thinking I would not be able to do such thing 2024-09-04 16:56:18 but at the end it does not seem as daunting as I thought 2024-09-04 16:56:57 one of these days i'll make a lisp 2024-09-04 16:57:02 that's why I was wondering if i 'm not realizing something 2024-09-04 16:57:47 watch out for unintended side effects 2024-09-04 16:57:48 I suppose the complexity is when you want to translate a specific language and have to adapt to that 2024-09-04 16:59:48 I suppose using lisp is cheating a lot 2024-09-04 16:59:55 :D 2024-09-04 17:00:38 I have a free parser and every statement is perfectly delimited 2024-09-04 17:01:26 I have (ab)used arrays in js to write lisp-ish code 2024-09-04 17:03:31 with a concat lang I found it very difficult to translate to a non rpn lang 2024-09-04 17:04:13 I had no way to know where a statement ends or is part of another expression, unless I add metadata to know the arity of every word 2024-09-04 17:04:17 lisp only saves you a lexing step 2024-09-04 17:04:37 parsing and code generation are pretty much unchanged 2024-09-04 17:05:20 though you have an extra macro-expansion step before parsing 2024-09-04 17:08:29 another aspect to this is: how accurately do you want to reproduce the behaviour (both obvious effects, and side effects (ie. flags set, implicit pointer arithmetic, printrooms set alight)) intended by the input source in your target environment? 2024-09-04 17:12:44 well in my case I'm just making some sort of dsl that resembles js with parentheses 2024-09-04 17:13:20 as long as you're happy with the results you're getting, fsck what anyone else thinks about it :) 2024-09-04 17:16:32 Writing a transpiler from a very simple lang to a high-level lang is easy 2024-09-04 17:16:41 I don't know who said otherwise 2024-09-04 17:18:51 Yet again we're talking about lisp in here ..... 2024-09-04 17:25:48 did somebody say the "lisp" word? 2024-09-04 17:31:48 hard to talk about languages without at least mentioning it 2024-09-04 17:34:10 Look there's two kinds of Forth programmers, Forth programmers and lisp tourists 2024-09-04 17:34:32 And at this point I want the tourists off of my lawn 2024-09-04 17:35:51 I go outside and there's tyre tracks everywhere, and someone banging on for the 100th time about how easy it is to parse lisp and generate an AST 2024-09-04 17:36:07 In ##forth, a channel about a language that is impossible to parse on its own and has no concept of tokens 2024-09-04 17:37:12 Which is not a weakness because obviously we're not trying to solve the same problems as lisp 2024-09-04 17:37:29 But then it just makes the conversation even less relevant to us 2024-09-04 17:38:18 I agree fwiw 2024-09-04 18:03:24 are the tyre tracks misplaced parentheses? 2024-09-04 18:04:04 forth is america, we spell it "tire" 2024-09-04 18:19:27 the next forth book should have a bald eagle delivering tires in an example somewhere 2024-09-04 18:20:00 a stack of tires 2024-09-04 18:25:12 sorry veltas 2024-09-04 18:25:41 I asked here because I know you guys know about language implementation 2024-09-04 18:26:39 let me write a forth hello world to compensate 2024-09-04 18:26:58 : oh ." Hello, world!" ; oh 2024-09-04 18:27:42 it's missing a cr :/ 2024-09-04 18:28:31 that said, I always envy forth in some way 2024-09-04 18:29:09 the fact you can create your data structures and an accessor can be as simple as memory_address offset + 2024-09-04 19:06:20 rendar: in gforth : neg -10 0 do i . -1 +loop ; neg prints out 0 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 and stops; what does it do for you? 2024-09-04 19:06:24 xentrac: Heh, guess I reached the age where I can tell what will be on a site just by the URL. That's about the Carmack link from yesterday. 2024-09-04 19:06:39 that's a loop with a negative step 2024-09-04 19:07:57 +loop is probably more often used for things like cell +loop to iterate over a range in steps other than one. this is less important on modern CPUs which have hardware multipliers 2024-09-04 19:10:21 vms14: some language constructs are harder to compile than others, and even just writing a parser for some languages can be a difficult problem 2024-09-04 19:11:09 there's nothing wrong with trying things you aren't able to do; if you never try anything you aren't able to do, the things you are trying are too easy 2024-09-04 19:11:36 ACTION gets out his camera 2024-09-04 19:12:18 user51_: heh 2024-09-04 19:36:12 zelgomer: Didn't even realise US spelt it different 2024-09-04 19:36:26 The second paragraph of 'Article on functional programming in C++ (2012-04-30)' seems very orthogonal to Spencer's email - if I understood it correctly it implied that the 'forward structure' of the program made it easy to reason about every possible state it was in. There's probably some relation to graphs here, maybe a DAG or something topological. Not sure as I only did one semester about them. 2024-09-04 19:37:34 Darn, that first sentence was too long :x computers shut down, humans shut up! 2024-09-04 19:38:38 Spencer's mail was mostly about how the Saab Gripen avionics firmware was loopless, subroutineless, and bug-free 2024-09-04 19:39:01 the second paragraph of that mail says 'A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in' 2024-09-04 19:40:18 these seem closely related to me: if your code is loopless and subroutineless, most of the state your code may execute in is encoded in a single program counter, though you may possibly care about which previous conditionals executed 2024-09-04 19:41:02 whereas code in a subroutine can be executed from anywhere, and code in a loop can be executed with various loop counter values and therefore varying numbers of preceding iterations (most problematically including 0) 2024-09-04 19:43:53 We could bring back GOTO. Add a PC word that pushes the current execution pointer and you're done. 2024-09-04 19:44:12 Would the type of subroutines matter? I was thinking of subroutines who are called exclusively by reference. 2024-09-04 19:45:40 Then a loop becomes PC 1 + DUP > 10 IF OVER GOTO THEN 2024-09-04 19:46:41 The main reason Forth doesn't have GOTO is because the to/from address goes on the stack, so structured programming works naturally, GOTO doesn't 2024-09-04 19:47:15 I guess you could have named labels/from's like local variables, maybe in a separate wordlist 2024-09-04 19:47:19 it works fine but I wasn't seriously suggesting it 2024-09-04 19:47:25 Not too hard 2024-09-04 19:47:33 could jump right into the middle of word definitions 2024-09-04 19:48:24 Manipulating top return stack item is a big theme in here 2024-09-04 19:48:35 It's how I implement a lot of my compiled/raw words 2024-09-04 19:53:39 dlowe: hahaha 2024-09-04 19:54:12 you can implement that in standard Forth 2024-09-04 19:58:05 ACTION has a `jump` word for GOTO-like purposes 2024-09-04 19:58:46 How do you handle the label? Jumps to start of a word? 2024-09-04 19:58:53 your loop isn't quite right though, dlowe 2024-09-04 19:59:46 well, there's a reason it was considered harmful 2024-09-04 20:00:07 though I was thinking PC would have to push the *next* address, not the current one 2024-09-04 20:00:20 dlowe: here's a working version: : pc r@ ; : goto rdrop >r ; : things 0 pc over . swap 1+ tuck 10 < if dup goto else drop then ; things 2024-09-04 20:00:33 yeah... simple... 2024-09-04 20:00:46 veltas: generally yes. It just takes an address and branches to it; most labels are just word names 2024-09-04 20:01:49 Rather than just accepting 'rules' for programming practices it's good to understand the rationale 2024-09-04 20:19:46 (verified in GForth and F83, where I had to define : rdrop r> r> drop >r ; ) 2024-09-04 20:21:01 given an assembly like http://forth.works/share/KEKRSMCOT1.txt I could use `&n:square jump` to jump to the code that follows the label. (`label:` adds the necessary code to branch around the header) 2024-09-04 20:26:03 veltas: Dijkstra's rationale for structured programming is very similar to Carmack's in the above note 2024-09-04 20:26:26 xentrac: That goto would break loops, no? 2024-09-04 20:27:09 user51_: do loops, yes, but not begin loops 2024-09-04 20:27:09 crc: Links empty for me 2024-09-04 20:27:23 I don't know why 2024-09-04 20:29:35 xentrac: You got me, I only checked do. 2024-09-04 20:31:21 veltas: should be fixed now 2024-09-04 20:31:34 Okay that works, thanks 2024-09-04 20:32:10 xentrac: I've seen first hand what people obsessed with structured programming do to code, they make it ten times harder to understand, less maintainable, introduce bugs 2024-09-04 20:32:31 veltas: Any examples? 2024-09-04 20:32:56 One of the things people do, which I'm not sure is a core tenet of it, but is related, is writing functions with only one return statement at the end 2024-09-04 20:33:17 This is especially painful with lots of error handling in e.g. C which is what I work with professionally 2024-09-04 20:34:44 early returns are great 2024-09-04 20:35:01 goto is great for cleanup code in C 2024-09-04 20:35:05 It's not a core tenet. Djikstra insisted on it, but the tide of opinion was not favorable generally. You still find some believers. 2024-09-04 20:35:06 veltas: I don't think it's really a core tenet,no 2024-09-04 20:35:29 Okay well my issue is with what Dikkstra described 2024-09-04 20:35:43 I am a fan of pragmatic structured programming, it's my favourite paradigm 2024-09-04 20:35:49 And data abstraction 2024-09-04 20:36:03 but there wasn't a good theory of multi-exit constructs 2024-09-04 20:36:06 But strict stuff like Dijkstra, OOP, etc, is all hot garbage in my humble opinion 2024-09-04 20:36:14 I mean, the alternative to structured programming is branch spaghetti and not many people want to go back to that. 2024-09-04 20:36:26 It has its place 2024-09-04 20:36:57 Every construct is multi-exit if it allows you to divide by zero 2024-09-04 20:37:01 haha 2024-09-04 20:37:10 At the top level of a program it's not really any worse, I would say. This is something hinted at in Moore's paper on programming problem oriented language 2024-09-04 20:37:31 Comparing routine with subroutine I think he called it(?) 2024-09-04 20:38:07 you jump to a routine, you call a subroutine 2024-09-04 20:42:08 Yeah that's how I seem to remember it 2024-09-04 21:18:39 crc: That's very nice 2024-09-04 21:19:13 so right after veltas's rant, this comes out https://github.com/gmpalter/cl-forth 2024-09-04 21:19:29 quite a coincidence :D 2024-09-04 21:20:33 ACTION puts his face through a glass table 2024-09-04 21:21:24 ALL-WORDS sounds incredibly useless 2024-09-04 21:21:37 WORDS is already one of the most useless words in Forth 2024-09-04 21:21:52 Because it's of no help in FORTH 2024-09-04 21:22:04 It's at least good for listing functionality of a vocab 2024-09-04 21:22:47 Ah they defined M/ , very good 2024-09-04 21:23:13 And have taken cues from SwiftForth, nice 2024-09-04 21:24:04 dlowe: Where did you find this? 2024-09-04 21:24:19 they literally just announced it on #commonlisp 2024-09-04 21:25:55 I didn't go looking for it 2024-09-04 21:26:21 Credit to someone who actually implemented a Forth in a lispy language that seems to be a full real implementation of Forth 2012 2024-09-04 21:26:30 I could actually talk to them about Forth, hypothetically 2024-09-04 21:33:37 Missing KEY and all the raw terminal stuff 2024-09-04 21:34:16 No blocks although that's not a huge omission, can implement it with files 2024-09-04 21:35:10 the first lisp tourist that pleases you 2024-09-04 21:35:13 dlowe: What's their nick? 2024-09-04 21:35:23 where do they live 2024-09-04 21:35:26 ^ 2024-09-04 21:39:04 veltas: palter 2024-09-04 21:39:09 zelgomer: West Roxbury, MA 2024-09-04 21:39:16 omw 2024-09-04 21:39:35 he's also the maintainer of the old lisp machine os 2024-09-04 21:42:34 Can you invite him to the channel 2024-09-04 21:50:53 palter: hi neighbor 2024-09-04 21:51:02 ACTION is a lisper/forther in waltham 2024-09-04 21:51:35 ACTION Ancient hacker in West Roxbury 2024-09-04 21:52:45 I work with some people in Wilmington 2024-09-04 21:53:00 I'm in the UK though 2024-09-04 21:53:53 palter: I asked if dlowe would invite you because we are interested in Forth 2024-09-04 21:54:01 What made you want to write a Forth 2012? 2024-09-04 21:54:25 i'm here because i'm interested in lisp 2024-09-04 21:55:28 ACTION looks with expectation 2024-09-04 21:57:02 I have a client with a set of large applications written in Common Lisp. For historical reasons, the applications communicate with a Forth process and use the Forth as a poor man's FFI. (The applications are over 30 years old.) 2024-09-04 21:57:58 Wow that's fascinating 2024-09-04 21:58:36 The Forth they're using is a 32-bit implementation written by a former employee. There's no one to maintain it, let alone recompile it for newer platforms. I had done some other consulting work for them, porting their applications to a different Lisp. They then asked if I could build them a new Forth. 2024-09-04 21:58:36 So what do you think of Forth itself? I'm assuming you like it because you've tried to modernise their Forth rather than outright replace it, if I guess right? 2024-09-04 21:59:23 I completely replaced their old Forth with a new one implemented in Common Lisp. (Their old one was written in C and assembler.) 2024-09-04 21:59:54 Did they want one written in CL specifically or was that an implementation choice? 2024-09-04 21:59:55 Before I did this, I hadn't touched Forth since the early '70s when I played with it at the Boston Museum of Science. 2024-09-04 22:00:37 That was an implementation choice but it has the benefit that they'll be able to embed the Forth in their applications. So, one less binary to ship. 2024-09-04 22:01:21 Do they have people there trained in Forth then? 2024-09-04 22:01:33 (The Forth will run as a Lisp process inside their application. The application will communicate with it over streams. Effectively, no source changes to their applications needed.) 2024-09-04 22:02:19 Not really. Their needs are very specific and most of the Forth they execute is generated on the fly by their apps. 2024-09-04 22:03:59 ACTION Having issues with my hands today. Typing is difficult right now. So, if I don't respond, it's not because I'm ignoring you. 2024-09-04 22:04:17 Understood 2024-09-04 22:04:28 Sorry to hear that 2024-09-04 22:05:32 I guess 30 years ago it would have been less strange to do all this 2024-09-04 22:05:59 You know palter we don't get a lot of people using Forth professionally in here, you're one of the few who has that badge 2024-09-04 22:21:40 xentrac, : miao 5 0 DO I . -1 +loop ; 2024-09-04 22:21:47 xentrac, what about that? it does into infinite loop. 2024-09-04 22:22:00 goes* 2024-09-04 22:22:48 Yes because you get 0 -1 -2 -3 -4 -5 -6 -7 -8 .... 2024-09-04 22:22:52 Not crossing 5 2024-09-04 22:23:01 yep, me too 2024-09-04 22:23:36 it doesn't. it just ends up iterating 2^cell - 5 times 2024-09-04 22:23:53 Do you want : miao 0 5 DO I . -1 +LOOP ; 2024-09-04 22:25:03 zelgomer: haha 2024-09-04 23:25:26 so multiline words: semicolon goes on the same line with the last word, or on its own line in the left most column? 2024-09-04 23:31:30 traditional screen-oriented Forth source heavily penalizes using extra lines 2024-09-04 23:31:59 semicolon goes on its own line 2024-09-04 23:32:47 good, we have two contenders. now arm wrestle for it! 2024-09-04 23:33:06 I'm inclined to use same line for screens, new line for files 2024-09-04 23:33:18 well, I think it's reasonable to do either one. I just think screen layout may be an influence on people commonly sticking semicolons onto the same line 2024-09-04 23:33:21 i just find it easier to distinguish where a word starts and ends if there's stuff on column zero 2024-09-04 23:33:45 Structure is indicated better with tabs + newlines, screens just aren't optimised for that 2024-09-04 23:33:52 But screens are cool and retro 2024-09-04 23:34:16 if i do ever end up writing a freestanding self hosted forth i'll put the work in to write a "proper" text editor tbh 2024-09-04 23:34:21 I think screens were probably always a bad tradeoff 2024-09-04 23:34:30 screens is a keep it simple thing 2024-09-04 23:34:44 is? are? whatever 2024-09-04 23:34:47 i don't have the guts yet to put my code in something that doesn't interact well with vim and git 2024-09-04 23:34:50 they do keep it simple, but at the time the efficiency cost was enormous 2024-09-04 23:35:11 it roughly doubles the size of Forth source code 2024-09-04 23:36:10 Whatever will I do without all these inodes 2024-09-04 23:36:24 swings and roundabouts 2024-09-04 23:36:29 heh 2024-09-04 23:37:01 nowadays using screens doesn't have a significant efficiency cost, but in the 01970s disks were commonly 90KiB 2024-09-04 23:37:51 well it has exactly the same efficiency cost 2024-09-04 23:37:54 it's just doesnt matter 2024-09-04 23:37:59 right 2024-09-04 23:38:01 nowadays instead we suffer from their inflexibility instead (which was always a problem) 2024-09-04 23:38:02 because double a small number is still a small number 2024-09-04 23:38:44 also possibly you're gzipping or zstding your Forth block files before copying them to stable storage 2024-09-04 23:38:59 which eliminates most of the inflation 2024-09-04 23:39:04 yeah 2024-09-04 23:39:15 Or replacing trailing spaces with newlines 2024-09-04 23:39:36 yeah, I think that's maybe the cure for zelgomer's problem 2024-09-04 23:39:41 And initial spaces etc with tabs 2024-09-04 23:40:06 tabs are better for indentation imo 2024-09-04 23:40:17 edit your code in vim, save it in Git, but do it by translating it bidirectionally with Unix text files 2024-09-04 23:40:18 cuz that way one tab corresponds to one level 2024-09-04 23:40:29 tabs are definitely better for indentation on an ASR-33 at 110 baud 2024-09-04 23:40:29 and then whoever's reading it can set one tab to whatever width they want 2024-09-04 23:40:41 doesn't matter that i'm apparently a freak for liking 8 space tabs 2024-09-04 23:40:44 because they only take 90 milliseconds instead of 450 milliseconds 2024-09-04 23:40:45 you don't gotta read it 2024-09-04 23:40:58 i like 8 col tabs 2024-09-04 23:41:09 I don't like them on my cellphone 2024-09-04 23:41:51 that's funny. i'm sure i've cursed my phone's screen being too small before, but it never occurred to me to make the tabs smaller. 2024-09-04 23:41:52 Just my point is that screens don't waste as much space as people think because they're ignoring the filesystem overhead 2024-09-04 23:41:59 Especially on really small disks 2024-09-04 23:42:27 a filesystem is useful though 2024-09-04 23:42:52 my linux machine can mount fat32 no problem but it wouldn't know where to start with a bunch of blocks of text 2024-09-04 23:43:25 That's what INDEX is for 2024-09-04 23:43:31 start at block 1, i guess 2024-09-04 23:44:22 i'd rather not write a kernel driver to pull my code up on my laptop, thanks 2024-09-04 23:44:34 (or fuse, but you get the idea) 2024-09-04 23:44:49 palter: what 32-bit platform were they running their Forth on? 2024-09-04 23:45:19 like when i do eventually get round to freestanding forth i'll probably just use grub or limine to boot it 2024-09-04 23:47:32 https://pastebin.com/raw/sRXX3qmN 2024-09-04 23:48:08 It just prints first line of each screen with its block number, skips if it's blank or contains a null 2024-09-04 23:50:02 e.g. https://pastebin.com/raw/68VeAQDc 2024-09-04 23:51:40 Should really skip a line if it contains anything under 32, that's a better test 2024-09-04 23:52:33 I've just not got around to changing it, I was in middle of adding block range moving/copying 2024-09-04 23:54:56 The government doesn't want you to know about this