2024-03-14 00:50:37 <veltas      > lf94: Re. OS, it's an interesting question.  An OS now is a kitchen sink of different features.  If I had to boil them down I wouldn't say it's a HAL.
2024-03-14 00:50:54 <veltas      > I'd say it is the software used to share resources
2024-03-14 00:51:14 <veltas      > Either between multiple users, or multiple threads of execution
2024-03-14 00:51:48 <lf94        > Why wouldn't you say HAL? Most programs use the OS as a HAL.
2024-03-14 00:52:09 <veltas      > I don't think a HAL is necessary for that, and OS's nowadays often provide extremely low level access to certain high-performance hardware, bypassing all abstraction
2024-03-14 00:54:54 <veltas      > Likewise security features, reliability features, a filesystem, all these are typical but I don't think they're the 'core identity' of an OS
2024-03-14 00:55:34 <veltas      > There's the 'OS' as it's typically presented in practice, and then there's the 'concept' of an OS, and I think my definition is the right one for that
2024-03-14 00:59:31 <veltas      > lf94: Re. local vars I think Chuck is a purist, he doesn't think locals are forthy.  Most of us agree, it's not forthy.
2024-03-14 00:59:50 <veltas      > But some people find it easier to write serious code with them, and easier to maintain said code
2024-03-14 01:00:18 <veltas      > To each their own, everyone has their own goal, I think it's clear Chuck's goal isn't necessarily to have a universal language
2024-03-14 01:01:00 <veltas      > This answers question about how to write good forth you need to be a good programmer
2024-03-14 01:01:45 <lf94        > I actually don't understand how you could not have local vars
2024-03-14 01:01:45 <veltas      > However I don't personally agree, I think that braindead naiive forth is often subtely good, and 'good programmers' probably write a lot of over-engineered forth. But I suppose it depends on definition of 'good'.
2024-03-14 01:01:56 <veltas      > He means named local variables
2024-03-14 01:02:13 <lf94        > Could you show me an example? My forth is next to nothing
2024-03-14 01:02:32 <veltas      > So not CREATE vars, or stack vars, but stuff like  : TEST {: x :} x x * ;
2024-03-14 01:02:41 <veltas      > As alternative to   : TEST DUP * ;
2024-03-14 01:02:55 <lf94        > Ah. To me, a "local stack var" is still a local var
2024-03-14 01:03:04 <lf94        > This makes way more sense now.
2024-03-14 01:03:26 <lf94        > That almost looks like a lambda
2024-03-14 01:03:42 <veltas      > 'lambdas' in forth are usually called quotations
2024-03-14 01:03:59 <lf94        > Do they add much more complexity to the interpreter?
2024-03-14 01:04:06 <lf94        > I'm avoiding lisp for the usual reasos
2024-03-14 01:04:08 <lf94        > reasons
2024-03-14 01:04:10 <veltas      > Locals or lambdas?
2024-03-14 01:04:14 <lf94        > lambdas
2024-03-14 01:04:28 <lf94        > "usual reasons" -> gc, slowness
2024-03-14 01:04:28 <veltas      > Not a huge amount of complexity no
2024-03-14 01:04:42 <veltas      > The main controversy with quotations is they aren't 'forthy'
2024-03-14 01:04:46 <veltas      > Which is highly subjective
2024-03-14 01:04:55 <lf94        > I read a ton of Forth related material today, like I do once every 5 or so years
2024-03-14 01:04:58 <veltas      > crc's retro heavily uses them, and feels very different as a result
2024-03-14 01:05:01 <lf94        > This time around I feel something different
2024-03-14 01:05:17 <veltas      > But retro is really cool, it is just very alternative
2024-03-14 01:05:25 <lf94        > retroforth I assume
2024-03-14 01:05:27 <veltas      > Yes
2024-03-14 01:05:41 <lf94        > I'm more interested in a forth that remains simple
2024-03-14 01:05:46 <veltas      > Retro is awesome, it's not a conventional forth
2024-03-14 01:05:55 <veltas      > Retro is simple actually
2024-03-14 01:05:56 <lf94        > colorForth really looks like a great idea
2024-03-14 01:06:07 <lf94        > Not with color but at least with alternative typesetting
2024-03-14 01:06:20 <lf94        > Is there a forth like this that's maintained?
2024-03-14 01:06:31 <lf94        > or takes its idea?
2024-03-14 01:06:36 <veltas      > Not that I know of but the idea's been discussed before
2024-03-14 01:06:52 <veltas      > It's easy to implement something like this in a normal forth for testing purposes
2024-03-14 01:07:43 <lf94        > I honestly still don't even know exactly what it does but my assumption is it helps with knowing stack sizes
2024-03-14 01:08:07 <lf94        > Like an alternative to parens from lisp
2024-03-14 01:08:20 <lf94        > you could probably do colorLisp and it'd help just the same
2024-03-14 01:09:20 <veltas      > KipIngram's designs have features that help keep track of stack sizes, I think
2024-03-14 01:10:25 <veltas      > I think something like [ n .... ] leaves the stack n smaller at ] or something like that, you'd have to wait for him to get on to explain
2024-03-14 01:10:57 <veltas      > But I think clearly there are a few variations possible that have different benefits/drawbacks
2024-03-14 01:11:24 <veltas      > lf94: I think retro's parsing mechanism is more pragmatic than colorforth's
2024-03-14 01:13:43 <veltas      > Well more pragmatic for use in a normal terminal setting, with plaintext files
2024-03-14 01:14:13 <veltas      > Personally I think classic forth parsing is plenty pragmatic, but Chuck doesn't agree.
2024-03-14 01:16:22 <veltas      > lf94: Re CAD software see https://www.youtube.com/watch?v=B_cf8n58Ews and https://www.youtube.com/watch?v=Dbd7Xu0ibJM
2024-03-14 01:17:43 <veltas      > If you want to work on this stuff then talk about it in here, lots of knowledge kicking around, and support available if you want to try and develop things yourself
2024-03-14 01:25:14 <lf94        > retro is sounding better and better. Yes, I'm open to anything that attempts to fix the "stack size" problem. And yes, I plan to at the very least use forth in the coming days :)
2024-03-14 01:27:57 <lf94        > Holy cow, OKAD looks crazy for the time.
2024-03-14 14:15:54 <veltas      > lf94: The primary method for solving the stack is to keep it simple
2024-03-14 14:16:03 <veltas      > My personal advice is to keep simple, and not be afraid of return stack
2024-03-14 14:22:15 <veltas      > Also don't be afraid of the data stack
2024-03-14 14:30:51 <zelgomer    > don't afraid of anything
2024-03-14 14:33:20 <user51      > I recommend using VARIABLE or VALUE liberally because it's better to get a program running ASAP.
2024-03-14 14:35:49 <user51      > But if someone insists on stack manipulation.. DUP, OVER, >R, R> and SWAP can get pretty far.
2024-03-14 14:49:22 <veltas      > They're not verboten
2024-03-14 15:08:29 <lf94        > What's the fastest Forth around?
2024-03-14 15:08:53 <lf94        > I saw a nice little benchmark involving Forth. A naive gforth implementation for counting words was about 4x slower than Python
2024-03-14 15:09:08 <lf94        > https://benhoyt.com/writings/count-words/
2024-03-14 15:09:10 <lf94        > Scroll to bottotm
2024-03-14 15:09:18 <lf94        > I feel like Forth should not be that slow.
2024-03-14 15:09:44 <lf94        > The optimized version is much better
2024-03-14 15:10:35 <lf94        > (Scroll to the very bottom to see the table of time)
2024-03-14 15:10:58 <lf94        > I misremembered, it's just 2x slower
2024-03-14 15:11:34 <lf94        > It'd be really nice to see it closer to 0.7 or 0.6s.
2024-03-14 15:15:40 <zelgomer    > lf94: gforth is an interpreter, it's not designed for speed.
2024-03-14 15:16:03 <veltas      > gforth compiles words with GCC though right?
2024-03-14 15:16:25 <zelgomer    > it does? i thought it was a live interpreter
2024-03-14 15:17:02 <zelgomer    > even if that's true, if it transpiles to c and compiles with gcc then that's also no wonder it's slow. i imagine it's very hard to implement a fast forth in c
2024-03-14 15:17:24 <zelgomer    > you're pretty much forced to emulate your stacks and use subroutine threading
2024-03-14 15:23:27 <zelgomer    > anyway, i have to admit i haven't done any benchmarking. lf94: my advice is don't get too wrapped up in performance metrics right now. there are a bajillion different implementations of forth, and if you really get into forth there's a good chance a few thousand of them will be your own implementations. for now, just learn the language and the philosophy of elegance and minimalism
2024-03-14 15:24:05 <zelgomer    > oops, i didn't finish that thought. there are a bajillion implementations and they all have different performances
2024-03-14 15:27:01 <veltas      > lf94: Their code looks slow, it's relying on word lookup which in Forth is designed to be simple, not fast
2024-03-14 15:27:14 <veltas      > As simplicity is prioritised over compiling performance
2024-03-14 15:27:39 <veltas      > Even though gforth has a hash table lookup, I don't know which version of gforth they used, and it still might not be a good hash
2024-03-14 15:27:46 <veltas      > good hash table*
2024-03-14 15:36:14 <crc         > "What's the fastest Forth around?" - definitely not mine :)
2024-03-14 15:46:00 <lf94        > Roger :)
2024-03-14 15:46:22 <lf94        > I just you know, avoid LISP  for the one of these reasons: slowness
2024-03-14 15:46:54 <lf94        > Forth being 2x slower than Python which is probably using an optimized C routine under the hood is probably pretty amazing.
2024-03-14 15:49:29 <crc         > I typically just drop to assembly if I need to make a part of my code faster
2024-03-14 15:58:18 <zelgomer    > lf94: again, i haven't benchmarked any of my implementations, but i suspect it'd not hard to be faster than python
2024-03-14 16:00:31 <zelgomer    > i'm pretty sure i remember brad rodriguez saying you can typically expect forth to carry a 2-3x overhead compared to native c, depending on the platform and threading model. i expect those fancy forths that compile to native instructions are faster, but i wouldn't have those metrics
2024-03-14 16:01:18 <lf94        > 2-3x overhead of c is very good
2024-03-14 16:01:29 <lf94        > (better if always 2x :p)
2024-03-14 16:01:40 <lf94        > if a C impl can be 0.2s, and a forth one is 0.4s, that's fantastic.
2024-03-14 16:02:12 <lf94        > How's Forth memory usage usually? I guess extremely good?
2024-03-14 16:04:53 <veltas      > Memory usage and performance can both be very decent, and as crc says it's usually easy to "drop into assembly" where necessary
2024-03-14 16:04:58 <veltas      > You've got a ton of control
2024-03-14 16:05:14 <veltas      > And there's cross-compiling forths where memory usage will be as good as anything else, if not better
2024-03-14 16:06:18 <veltas      > If a program has worse perf than python I'd be more interested in the program.  I would guess all Forth threading models are 'faster' than Python
2024-03-14 16:06:38 <veltas      > The Moving Forth articles are worth reading if you're interested in how it works under the hood
2024-03-14 16:06:48 <veltas      > And Starting Forth's later chapters
2024-03-14 16:06:55 <veltas      > for the classic model
2024-03-14 16:07:12 <veltas      > And should give you confidence that Forth is leaner than Python, at least
2024-03-14 16:08:22 <veltas      > An optimising STC forth example generating actual 'subroutines' with not-terrible code would be mecrisp
2024-03-14 16:08:46 <veltas      > swiftforth, gforth isn't bad either
2024-03-14 16:09:02 <veltas      > Just don't use a wordlist like a hash table
2024-03-14 16:09:15 <veltas      > It's a linked list on most forths!
2024-03-14 16:09:28 <veltas      > It's an optimised linked list on gforth
2024-03-14 16:11:40 <lf94        > Oof, ok
2024-03-14 16:13:32 <veltas      > It's a linked list because in the classic model you build it up as-you-go in the dictionary, and the lookup was done when you entered a line of text or LOAD'd a block.
2024-03-14 16:13:56 <veltas      > E.g. on my 3.5MHz ZX Spectrum that lookup seems "fast enough", the slower bit is actually reading numbers
2024-03-14 16:42:25 <lf94        > https://www.bradrodriguez.com/papers/tcjassem.txt what a great piece
2024-03-14 16:45:21 <lf94        > I feel between this, and a Forth i/o example, I'll be "up to speed" in no time
2024-03-14 16:46:00 <lf94        > I want to actually use Forth for some personal utilities. The two most useful being a subtitle printer and spaced repetition practice
2024-03-14 16:47:05 <lf94        > What's a recommended forth on Linux? Simply gforth?
2024-03-14 16:50:23 <veltas      > Might as well start with gforth if you want a standard forth
2024-03-14 16:50:53 <veltas      > Install 0.7.3 from your package manager and then build the snapshot if you want for newer features, needs old gforth installed to build
2024-03-14 16:51:06 <veltas      > Can also use swiftforth's demo, but it's x86-32 I think
2024-03-14 17:23:34 <lf94        > Cool cool :)
2024-03-14 18:38:20 <lf94        > What's an example of one of the nicest forth programs?
2024-03-14 18:38:26 <lf94        > In terms of being able to understand it
2024-03-14 19:06:26 <zelgomer    > lf94: in my opinion, the draw of forth is that it's easy to roll your own. in that case, performance and memory usage are entirely up to you. if you're looking for a language where you just download someone else's compiler and have libraries already available to you, you might as well use c. just my opinion, of course. forth, the language itself, just doesn't appeal to me enough to stand up to c if
2024-03-14 19:06:32 <zelgomer    > you're using third party compilers
2024-03-14 19:33:43 <KipIngram   > Totally agree - that is the Forth draw.  Python is possibly even more friendly than C in regard to just how easy it is to import and use packages for practically anything.  Or maybe I'm just more familiar with doing it - I'm sure there are tons of C libraries out there too.
2024-03-14 19:34:10 <KipIngram   > BTW, I was talking the other day about writing an Enigma emulator - I found an existing Python package for that too, that I can use to check my work.
2024-03-14 19:34:31 <KipIngram   > py-enigma
2024-03-14 19:34:51 <thrig       > it's an enigma anyone would write that
2024-03-14 19:34:58 <KipIngram   > Its documentation answers some subtle Enigma architecture questions too.
2024-03-14 19:35:03 <KipIngram   > :-)
2024-03-14 19:40:48 <KipIngram   > And you're kind of right - it's not of any real practical use these days.  Just historical interest.
2024-03-14 19:41:18 <lf94        > My draw to forth is you can get everything for very little.
2024-03-14 19:41:35 <KipIngram   > I saw a little project once where someone wrapped paper rings onto a Pringles can and made themselves a "manual" Enigma that way.  Just turn the rings the right way each time and follow the line from your input letter to your output letter.
2024-03-14 19:42:19 <KipIngram   > Yes - me too.  It's the only approach I know for writing a "total control" system for a computer from scratch, and yet have it be one you can extend indefinitely.
2024-03-14 19:42:52 <KipIngram   > If you've got a big team you can be a lot fancier, but Forth is good for "one man jobs."
2024-03-14 19:45:50 <zelgomer    > lf94: again, only speaking for myself and my experience. but "get everything for very little" can be misleading. don't discount the amount if time you'll spend waffling between a hundred possible choices. there is something to be said for established languages with clearly defined bounds
2024-03-14 19:46:48 <zelgomer    > this depends on your personality, of course. analysis paralysis is one of my greatest weaknesses, and forth is terrible for that
2024-03-14 20:00:00 <veltas      > Which is why early on I was happy to aim for the standard, and continued nearby the standard, even though I resent it entirely
2024-03-14 20:02:31 <veltas      > What I'll say about going with your own brand, go for it if you fancy, but if you spend any serious amount of time on the design then just stop.  There's no point sinking time into that *until* you really 'get' Forth
2024-03-14 20:04:15 <zelgomer    > yes, agree. i failed at that and wasted a lot of time fantasizing about making a dream forth that, even if i had followed through, would have missed the mark
2024-03-14 20:05:01 <zelgomer    > (not that i claim to be any authority on what "the mark" is, but i can say it's wildly different from what i'm pursuing now)
2024-03-14 20:05:35 <veltas      > It's honestly the hardest thing ever, working a design to a point where it's actually any good, weighing those tradeoffs, and accepting when you're at a dead end or failed start.
2024-03-14 20:05:36 <user51      > zelgomer: I'd like to hear what you were hoping for when you started, and how that ended up.
2024-03-14 20:07:33 <zelgomer    > user51: i have a lot of background in c, so i came into forth with that sort of thinking. i thought writing a self-hosting compiler was some kind of important milestone to achieve, and it really just isn't. i also wanted to write one unifying environment in which i would have package management and be able to load meta packages to retarget for any platform, and so on
2024-03-14 20:08:27 <zelgomer    > but if it were to be self-hosting, then it would also have to be something you could easily bootstrap from another language if you didn't already have a working binary
2024-03-14 20:09:44 <veltas      > I've spent much more time trying to rethink C, which I have orders more experience with, and even then that's full of dead ends and poor tradeoffs, for a design I can improve but never enough to convince anyone to switch to.
2024-03-14 20:09:53 <user51      > I definitely understand the appeal of a unifying environment but I'm not sure how great that would be in practice.
2024-03-14 20:11:04 <user51      > veltas: What do you mean by 'rethink'?
2024-03-14 20:11:16 <veltas      > redesign, come up with a better design
2024-03-14 20:13:23 <user51      > Well, how different would it be?  More specifically, does your redesign change things, remove things, add things?
2024-03-14 20:14:04 <zelgomer    > i have lots of things i'd like to add to or remove from c :)
2024-03-14 20:14:17 <zelgomer    > like a "recurse" keyword so that you can define recursive types
2024-03-14 20:15:18 <veltas      > What does that give you that arrays and pointers to same type don't give?
2024-03-14 20:16:08 <user51      > I'm certain I've said it before, but I really do like the RECURSE word.  I don't know any language which has something like it.
2024-03-14 20:16:51 <user51      > I know there's a forth that does it!
2024-03-14 20:19:30 <veltas      > My main conclusion playing with C is that it's actually quite good and it's great that such a language is used by so many.  Unfortunately I think that's a minority opinion!
2024-03-14 20:22:43 <user51      > I don't really have an opinion on languages anymore, do what's practical, bonus points if it's fun  :)
2024-03-14 20:25:31 <thrig       > C is a power tool without a lot of guards or orange warning bits
2024-03-14 20:44:56 <zelgomer    > veltas: the biggest one it gives you is the ability to define functions that return function pointers of the same type
2024-03-14 20:45:34 <zelgomer    > in c today, you can't write a function that returns itself without jumping through hoops
2024-03-14 20:45:57 <zelgomer    > why would i want this? because it's nice for writing a state machine
2024-03-14 20:50:33 <lf94        > C is hard to implement when you consider it as a whole and what it has to do
2024-03-14 20:50:43 <lf94        > vs something like Forth
2024-03-14 20:52:10 <GeDaMo      > "C in four functions" https://github.com/rswier/c4/blob/master/c4.c
2024-03-14 20:58:19 <GeDaMo      > "SectorC: A C Compiler in 512 bytes" https://xorvoid.com/sectorc.html
2024-03-14 20:58:22 <user51      > C4?  Someone set us up the bomb!
2024-03-14 21:11:08 <lf94        > GeDaMo: isn't that a really, really constrained C though?
2024-03-14 21:11:26 <lf94        > Like you can't really call it C. It's like C---- (Yes, 4 '-')
2024-03-14 21:12:03 <lf94        > Compare that to Forth, you can get _all of Forth_...
2024-03-14 21:12:14 <GeDaMo      > It's a subset of C, yes
2024-03-14 21:29:11 <lf94        > Why yes, this wheelbarrel is a vehicle.
2024-03-14 21:29:13 <lf94        > :p
2024-03-14 21:34:54 <thrig       > C---- would be G#
2024-03-14 22:02:51 <zelgomer    > my opinion is that they're all bad in their own special way
2024-03-14 22:03:21 <zelgomer    > oops, didn't realize my window was scrolled up. that was re: user51> I don't really have an opinion on languages anymore