I mean fair enough but a lot of Forth fans try and sell it as a general purpose programming language and even compare it to things like LISP, but it's obviously really not, it's very domain specific.
FORTH isn't necessarily domain specific when you start a project, but it always is by the time you finish.
In that sense it is actually much more like LISP than most other languages, it is scaffolding that allows you to build a DSL (in FORTH probably in the most literal sense of the word(s)).
I've never used any other language that has this property, and I've used C, C++, C#, Haskell, Java, Javascript, Rust, Python, Mathematica. All of them have easy to use dynamically sized arrays
C arrays are syntax sugar over pointer arithmetic and defining up a handful of FORTH words to do the same thing (plus a bump allocator) is sufficiently trivial that putting it in core would be weird, because -in general- FORTH programs are low level enough you wouldn't have -many- dynamic arrays so having separate words for each one often makes a lot of sense.
This isn't to say that FORTH is going to be particularly -suited- to writing something like a todo app, and I'm having the sort of day where I can see the rough shape of the required code in my head just fine but cannot for the life of me convince my fingers to produce you a useful example, but it's very much doable.
Well then it's weird that no Forth programmer I've asked can produce such an example when I ask them, and instead tell me to use another programming language
They probably tell you to use another programming language because if that's the kind of questions you are asking for your todo list application using another programming language is likely going to work better for you. It's a bit like asking to provide the schematics for a particular type of wrench when your job is to put a nail in the wall.
For instance, in computer science "literal constant" has a very specific meaning.
Python calls things "literals" that are obviously not literals; for instance [1, 2, 3] is actually a constructor which allocates a new li^H^Harray each time it is evaluated.
A true literal does no such thing; its syntax retrieves an object which has been placed into the program image; it typically exists before the program even starts.
Programs depend on the semantics of [1, 2, 3] making a new object each time; a Python compiler cannot just deduce that because all arguments are constants, it can be turned into a literal.
You don't want to learn computer science terminology (or computer science at all) from Python.
In general, in a discussion about or adjacent to programming language design, people will tend to expect 'list' to be used to mean a data structure that behaves like a singly linked list ala lisp's cons cell based list data structures.
The programming styles list-first and array-first languages encourage are sufficiently completely different that using them interchangeably tends to be a really bad idea, and honestly python's arrays being named that way irritates me even if I don't consider 'this irritates me' to be a criticism per se.
