4 ms·
I'm quite familiar with many Lisp dialects, including Emacs Lisp, Common Lisp, and Clojure, and I'm moderately familiar with Scheme too. I'm not a stranger to
by User23 5y ago
I'm quite familiar with many Lisp dialects, including Emacs Lisp, Common Lisp, and Clojure, and I'm moderately familiar with Scheme too.
I'm not a stranger to other outside the mainstream languages like OCaml and Haskell.
However, every time I've tried Forth I've bounced off it hard. Has anyone here had a similar experience and managed to overcome it? I really want to learn Forth because I believe learning new paradigms makes me a better programmer and it's also fun. So how can I make learning Forth fun?
And on a tangent, it's nice to see posts from the original Wiki. I spent a lot of time on that site a couple decades ago.
- eatonphil 5y agoIt's the most fun to me when I'm writing (or copying) programs in it for an implementation I wrote. So, write a forth implementation and add programs to benchmark or test it. You'll learn (parts of) it quickly!
- int_19h 5y agoI've found that the best way to truly grok Forth conceptually is to implement one yourself - and I don't mean a toy interpreter, but the real thing producing basic threaded code. Then you understand why it is the way it is, and what its strong sides are. Starting with a book that merely describes how to use it like any other PL just leads to questions like "why is this so weird?". Jones Forth is a common starting point - it has more comments than actual code, explaining the design in detail: https://github.com/nornagon/jonesforth/blob/master/jonesforth.S https://github.com/nornagon/jonesforth/blob/master/jonesfort...
- Karrot_Kream 5y agoThe reason I don't like building a Forth as an introduction to Forth is because it has you stop at the lowest level of abstraction a typical Forth program is written in. Forth is all about building layers of abstraction for yourself. If you're marching toward implementing a system with a set of words others have written about then you aren't really getting the practice in building your own abstractions that help writing Forth applications. It's why a lot of the Forth community laughs that most people come, write a Forth, then leave. A real Forth application can get quite high-level but it's up to you and your collaborators to design that tower of abstraction. I prefer a different approach myself. Start by writing small scripts, stuff that you've already written in other languages, in a full-featured Forth like Gforth. Once you feel comfortable doing that, start building small applications in Forth. Eventually, write bigger applications in Forth. Only shrink your base Forth vocabulary once you feel comfortable in a full-featured Forth like Gforth.
- int_19h 5y agoProblem is, there's not much point in writing high-level Forth - there are much better options out there for that.
- Karrot_Kream 5y agoIt depends on what you're looking for. If you think of Forth as just a macro-assembler that's easy to get started with, then you're going to just use Forth as a way to bring-up a system and leave. If you think of Forth as a way to build a custom DSL around essential complexity, then you'll be comfortable taking it as high as you'd like. I know most people, especially the types of folks who experiment with languages, view Forth as the former (especially since a lot of these folks are either interested in something high-level like Lisp or with more static assurance like an ML derivative), but if you want to actually see where Forth shines, then you need to actually write high level code in it.
- int_19h 5y agoBut, again, if you think Forth as a way to build a custom DSL, why wouldn't you use Lisp instead, which has a lot more to offer in that department to begin with? OTOH Forth as a universal macro assembler is essentially a unique niche where it not only fits surprisingly well, but it's also obvious as soon as you start using it in that capacity.