2025-12-08 00:37:40 veltas, after decades of C, when I started Forth, thats exactly what I did, very long words, little or zero documentation 2025-12-08 00:38:55 veltas, it took me years to 'learn' that short words of a few lines were actually optimum for Forth 2025-12-08 01:54:23 It took me a long time too, but I went all the way to one line. 2025-12-08 01:54:48 However, I get a lot on the line - I work hard for names as short as possible and opt for symbols wherever humanly possible. 2025-12-08 01:55:02 It's one of the things that makes APL appeal to me so - those nice terse symbols. 2025-12-08 01:55:29 I've had acquaintances that hae expressed preference for the "APL like" languages that are more verbose, but to me that defeats the entire point. 2025-12-08 01:56:23 I've long been drawn to the idea that when a package of functionality occupies a small amount of space on the screen, especially if it's "aspect ratio" isn't too much different from 1.0, you can kind of take it in as a "shape." 2025-12-08 01:56:47 That's not quiet the right way to say it, but somehow I find it easier to consider my code's correctness when it fits into a nice little box on the screen. 2025-12-08 01:57:14 It's also why I don't comment as much as I should (or any, a lot of the time) - the comments just spread out the code and make it harder to "see." 2025-12-08 01:58:23 For a lot of little jobs I wind up with 8 to 10 definitions that are all no longer than 50 characters or so, and usually all of them but one are "helper" definitions that I prune out of the dictionary as soon as I've made that one definition I want to keep. 2025-12-08 01:58:51 Anyway, I agree with your point - it takes a long time to "catch on to it." 2025-12-08 01:59:27 And ever since I did, I cringe a little every time I see Forth code that's laid out on the page like a C function. 2025-12-08 02:01:49 I think replacing IF ... THEN and all other such structures with conditional returns was also a big part of what moved me in that direction. It forces you to factor. 2025-12-08 02:02:38 But I guess I had to already be approaching it in order for that replacement to seem workable at all. 2025-12-08 02:20:10 KipIngram, I think it takes a long time if coming from C, assembly users probably dont have that issue ? 2025-12-08 02:21:17 KipIngram, I think Forth itself engenders factorising, at least Im always driven to factorise as much as I can now 2025-12-08 02:30:14 <[[smlckz]] > Ah APL.. I want to learn it someday.. 2025-12-08 04:09:37 tpnix: I'd have to ponder that I think. You may be right. Nothing in assembly forces factoring the way my restriction to conditional returns does, though. I have a suspicion that most people only create subroutines based on re-use potential, and Forth factoring sort of asks you to go a lot further than that. 2025-12-08 04:11:26 I have this idea that definitions that involve just seven or eight words tops work well because you can hold that many things in your short term memory. But seven or eight assembly instructions rarely gets you very much, and each instruction is more complicated than a Forth word, because it can have any of many registers, any of several addressing modes, etc. - that is, an instruction counts as 2025-12-08 04:11:28 more than one item to hold in your memory. 2025-12-08 04:12:18 And certainly any body of code that does something substantial is going to stretch out over many many lines - no way to even see it all on the screen at once. 2025-12-08 04:12:31 KipIngram, I agree with you re subroutines, in my Forth code I never consider subroutine reuse at all, each Word is designed for it's use there and then only 2025-12-08 04:12:32 I think the way Forth uses both vertical and horizontal dimensions is an advantage too. 2025-12-08 04:13:03 Yeah, reusability is a wonderful bonus that you occasionally get. Not "typical." 2025-12-08 04:13:40 I never get it in embedded peripheral Words as everything is different 2025-12-08 04:14:16 Yes, "occasionally" may mean "very very occastionally." 2025-12-08 04:14:17 sure, there is a ton of reuse in the general Mecrisp-Stellaris Forth parts of the embedded program 2025-12-08 04:15:01 stuff like the Systick timer Words, clock driver words etc 2025-12-08 04:16:29 but then I only do STM32 projects, one or two models of Cortex-M mcu are my limit considering all the peripheral expertise needed, especially the timer/counters 2025-12-08 04:17:44 Ive spent the last 11 years mainly on the STM32F051 just to get a good working knowledge of all the peripherals 2025-12-08 04:19:17 Ive just started a new project that uses the STM32G030 which is the new 40nm node class and there is a lot of new stuff to learn, so there goes the next 5 years ... ;-) 2025-12-08 04:49:40 has anyone here done an array language embedded in forth that still "feels forthy"? 2025-12-08 04:57:43 got funny new matmul hardware and i'm not a fan of its (c++ and python -based) sdk so i'm strongly considering doing my own as a metacompiler in forth, but it'd be nice to have something high-level I could put on top of that for prototyping 2025-12-08 07:09:50 <[[smlckz]] > Not embedded in forth, but at least won't require unicode characters: https://codeberg.org/growler/k 2025-12-08 07:12:02 <[[smlckz]] > For me, even Chinese is easier to read than Unicode characters that are hard to properly discern 2025-12-08 07:16:17 smlckz, don't worry about embedded here, 99% of the traffic is not embedded,I'm one of the few that only does embedded Forth 2025-12-08 07:17:34 smlckz, the majority of nicks here are programmers who dont do electronics (I think) 2025-12-08 07:19:29 i think they (and i know i) meant a language embedded in another (ie, a DSL), not embedded systems 2025-12-08 12:36:16 tpnix: Most of my career was in embedded, and I'm also hardware by early education. 2025-12-08 15:33:18 <[[smlckz]] > remexre, yeah; like in forth how you can take over the parsing from the forth interpreter and implement some kind of macro assemblers 2025-12-08 16:38:12 <[[smlckz]] > veltas, I tried refactoring like you said, it now looks like this: http://0x0.st/KwlZ.fth 2025-12-08 16:51:34 Interesting 2025-12-08 16:51:55 And then do you think maybe some variables can be removed without confusion? 2025-12-08 16:52:15 Often after refactoring it's easy to remove certain vars, depends, not sure whether that applies here 2025-12-08 16:59:22 Looks readable to me anyway 2025-12-08 17:00:09 I think you'll find most Forth code is relatively readable because it's necessary for the author too, it quickly gets too hard for even the author to read if not! 2025-12-08 17:11:40 KipIngram, youre a rare breed then :) 2025-12-08 17:13:14 <[[smlckz]] > veltas, thanks for your feedback 2025-12-08 17:15:36 <[[smlckz]] > which variables do you think that can be removed? 2025-12-08 17:20:57 <[[smlckz]] > Considering where I took my inspiration from ( https://forth-standard.org/standard/core/PARSE-NAME ) for making this, maybe qsrc and qslen.. 2025-12-08 17:28:16 <[[smlckz]] > That begin .. while .. while .. repeat then made me wonder what's going on with it.. ''Extended control-flow patterns'' huh https://forth-standard.org/standard/rationale 2025-12-08 22:48:44 [[smlckz]]: Not sure I didn't really think but thought you might have insight 2025-12-08 22:49:02 But I just noticed a lot of vars and usually that's one of the things to try and get rid of with Forth refactors 2025-12-08 22:49:17 You simplify the words and sometimes it's clear where vars are a bit redundant 2025-12-08 22:49:33 But not always, vars are legit, up to you and depends on the code