.. but .. something can be conceptually/theoretically very simple yet pointlessly hard to use in practice - e.g. Forth, S+K combinators, FP needing Monads to be useful, thus losing simplicity, etc.

I'd suggest that Forth is small, rather than "simple" in the way Hickey defines the term. (I recently wrote a Forth system for fun on an old 16-bit 286 PC, so I have a lot of thoughts about Forth's relationship with simplicity in particular, which I will try not to burden anyone with unless they really want to hear them.)

Wow .. 😄 but its programming model is simple - conceptually just stack operations - no?

I’d love to hear more, @Jeremy Penner. A side thread like this shouldn’t raise objections.

I mean, when you talk about Forth, you're typically thinking of the stack, but to me Forth is interesting because it is an extremely tiny VM and extensible single-pass compiler framework

one line? paste it here!

sorry, my brain's exploded

Don’t listen to @Duncan Cragg, you have others in the audience here. Keep going 😄

I guess my point is, any language where you can redefine

3

to mean

launch the missiles

is not "simple" even though it is a perfectly logical outcome of how the interpreter & dictionary is implemented

well simplicity often correlates to power

and I haven't gotten much further than that 🙂

sounds .. simple 😄

I built a Forth basically so I could have green threads

crikey. you're hard core 😄

It wasn't that much work! Forths are fun to build and easy to change as you get a better understanding of them 🙂

right... nice. 🙂

There’s also a TON of great examples to learn from and documents from people explaining different strategies

I feel the trouble with Forth's stack is that you're linearizing things that are intrinsically a bit treeish.

Someone once said that "software should be as simple as possible -- but no simpler". I think that means there's a threshold where something can be simpler in a technical or literal sense, but at the cost of staying away from what's simplest on terms of the human mental model or manageability -- which is where I think Forth lives.

Why is forth's stack bad but lisp's stack good? I get that lisp is stacks of lists and I get that lisp is arguably higher level than forth. More I mean the perception that forth = bad/hard and lisp = good By the way, many of Sid Meier's 8bit games were written partly in a language called Sidtran which was similar to forth.

Basically, there is a pretty low complexity ceiling beyond which manipulating the stack to access the values that you need becomes really difficult vs. just naming the values and letting the compiler sort out where on the stack / register / memory those values live. https://yosefk.com/blog/my-history-with-forth-stack-machines.html is a long read but has a pretty good description about how Forth was simply the wrong tool to solve his class of problem. I'm fond of recounting how Chuck Moore has said that local variables as a language feature are "not only useless, but harmful", and my understanding is that this is because Chuck sees the inability to cope with complexity as a beneficial force, which prevents you from introducing it into your system. Instead he believes you should find a way to change the problem to a simpler one. It definitely has been true, in my experience, that writing complected code that braids together a bunch of things is so difficult to do in Forth that it's not worth attempting in the first place; whereas in C complexity may be much more straightforward to express without realizing it.

I love Forth. Yes it has issues, but everybody in this forum in particular should gain some experience with it, maybe try implementing a Forth interpreter. It would make all your future ideas so much more interesting if you can explain precisely why a Forth interpreter can be so tiny. Here’s my critique of Forth: https://plforums.org/practice/minimal-features-required-for-an-extensible-language#post_65 Here’s my ongoing attempt at filling and building on Forth’s niche: https://github.com/akkartik/mu/blob/master/subx/Readme.md I think an unsafe language that occupies C’s niche in a stack shouldn’t have a complex compiler. Type checking and memory safety are the problems at this level, and if you can’t help me with them what am I paying you hundreds of thousands of LoC for, anyway? What are your overheads? () Go safe or go transparent.

@Kartik Agaram Can you point me to a quick way of learning Forth?

Hmm, I immersed myself in the SVFig mailing list for a year, and read many books, so my memory isn’t very helpful right now. The only memorable experience was this screencast by Sam Falvo which gave a very visceral sense of what it’s like to program well in Forth: Other than that, here’s a couple of tutorials that seem decent: • https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Tutorial.html#Tutorial • https://skilldrick.github.io/easyforth

Thanks... hrm, I see the names aren't so great...

if

should be called

then

and

then

should be called

endif

But then some operations read forwards and some back. Better to get used to everything being backwards.

I'll add that get excited by the concatenative model every now and then. I like how pretty much any sequence of words can be factored out as a new definition.

Forth is highly factored code. I don’t know anything else to say except that Forth is definitions. If you have a lot of small definitions you are writing Forth. In order to write a lot of small definitions you have to have a stack.

— Chuck Moore () Heh, https://yosefk.com/blog/my-history-with-forth-stack-machines.html also has this quote. Agreed with @Jeremy Penner that it’s the best critique of Forth ever.

big forth/concatenative langs fan logging on—I think it's underestimated on a few levels: 1. amenability to visual programming (random example) 2. extensibility: factor was a programming language and environment built mostly by one person in a relatively short amount of time that managed to incorporate a CLOS-style object system, novel compilation, a graphical interface and smalltalk-esque code browser 3. begins with data: if you imagine an alternative visualization of stacks, you shove example data onto a kind of workbench and then do a bunch of transformations to it. this is analogous to example based programming if you squint 4. incremental interpretation/composition—since every use of a forth "word" is point-free and describes a transformation from one stack to another, the difference between a space (function composition in forth IIRC) and a line break is basically zero, so your programs end up very modular and tracking reflective program information like what actions have been done on the data is decomplected by default 5. an alternative to the lambda calculus: sorry if this is a bit of a dump I'm on mobile and organization is hard

All great for techies, but I was commenting from the perspective of non-techs, who always need to see their data and the transformations they are undergoing