[HN Gopher] Forth vs Lisp
___________________________________________________________________
Forth vs Lisp
Author : monological
Score : 49 points
Date : 2021-11-16 17:31 UTC (1 days ago)
(HTM) web link (wiki.c2.com)
(TXT) w3m dump (wiki.c2.com)
| eatonphil wrote:
| It's about as fun and easy to implement a simple thing that looks
| like a forth as it is to implement a simple thing that looks like
| a lisp. But that's where the ease of forth ends for me.
|
| I find forth basically impossible to read even when, at best,
| authors leave a comment on basically every 1-2 words. Writing it
| is pretty hard too.
|
| In contrast it's about as easy to be productive in a lisp (CL or
| Scheme) as it is in Python or JavaScript (give or take useful 3rd
| party libraries).
|
| Even if they're from the same time period and are interesting for
| being not very Algol-like, I don't think it makes a lot of sense
| to discuss Forth and Lisp in the same conversation. They were
| both improvements on very different things.
| coliveira wrote:
| If you read "Thinking in Forth" you'll discover that Forth can
| be more readable than other languages, if you write in the
| style that is supported by the language. Of course, if your
| goal is to use the same algorithm as in, for example, Java,
| your code will look terrible.
| eatonphil wrote:
| Thanks! I have read that book.
| agumonkey wrote:
| How do you feel about haskell point-free or function
| oriented programming ? Some times it feels a bit like forth
| (lots of tiny combinator that can feel obscure).
|
| Just asking, I'm no expert neither in Forth nor Haskell..
| just curious about your opinion
| voxl wrote:
| This is just personal preference. I find lisp impenetrable and
| parenthetical soup. But I can read pipelined function calls (in
| e.g. OCaml or Haskell) easily.
| jedimastert wrote:
| > I find lisp impenetrable and parenthetical soup
|
| I think part of this is the somewhat idiosyncratic indenting
| style, where closing parens are gathered together instead of
| their own line like curly brackets in C-style syntax. It ends
| up being somewhat similar to python, in that if a lisp
| program is indented "properly" you should be able to ignore
| the pileup of closing parens that tend to happen at the end
| of a long expression, and even the open parens, and see the
| structure for what it is.
|
| I found that Parinfer's introduction helped me a ton in this
| regard <https://shaunlebron.github.io/parinfer/>
| kazinator wrote:
| Even if so, a compiler can read your Lisp code and find
| errors that are run-time problems in Forth. $
| cat errors.tl (defun bad () (length (cons 3)
| x)) $ txr -e '(compile-file "errors")'
| errors.tl:2: warning: length: too many arguments: max 1,
| given 2 errors.tl:2: warning: cons: too few arguments:
| needs 2, given 1 errors.tl:2: warning: cons: constant
| expression (cons 3) throws errors.tl:2: warning: cons:
| constant expression (cons 3) throws errors.tl:2:
| warning: unbound variable x
|
| All that matters in readability is is how easily you can spot
| the error in bad code, and convince yourself that good code
| is good, taking into account and advantage all the available
| tooling.
|
| Forth is implementable in a tiny amount of space, and can
| produce fast executions. It can be fast when interpreted, and
| supports a straightforward compilation model. These are
| worthwhile qualities. Every computer scientist should know
| about Forth.
| eatonphil wrote:
| My point is that Forth's general goal is to be a higher-level
| assembly language for embedded systems.
|
| Common Lisp and Scheme's general goal is to be a high-level
| programming language for application development (also PL
| research in Scheme's case).
|
| By general goal I mean what you could ultimately guess the
| focus is based on the implementation decisions and how the
| community uses the implementations.
|
| They both do a good job but in very different situations.
| K0balt wrote:
| I would beg to differ that that is the "goal" of forth, but
| I do think that there is truth to the statement in terms of
| niches best served when used by most programmers.
|
| Writing in forth is a process of creating a domain specific
| language to solve the problem at hand, so it tends to get
| quite claustrophobic as you close in on the goal.
| eatonphil wrote:
| Yeah I tried to clarify. I am not an authority on their
| literal goal. I was trying to describe the result when
| you look at the systems overall in terms of
| implementation and use; what they make easy.
| Karrot_Kream wrote:
| At high levels (meaning you've built up some nice Forth
| words), I disagree. The main difference is that most Lisps
| and Schemes have a GC, so you're not in charge of
| allocating/freeing memory like you would in Forth. That
| doesn't stop Forth words from implicitly referring to a
| variable that actually contains memory allocation addresses
| and hiding the actual underlying details of the allocation.
|
| I think Forth certainly starts you out at a level of
| abstraction only somewhat more rich than an assembler while
| a Lisp runtime certainly abstracts more away from you, but
| once a Forth has been built-up, they become similar. Gforth
| gets a lot of flack in the Forth community for not being
| minimal, but it's a good example of a feature-rich Forth
| with support for things like exceptions, filesystems,
| sockets, and more. The Forth community itself is split into
| broadly two camps. The minimalist camp, (where Chuck Moore
| likes to live) which believes in bringing up custom Forths
| for custom platforms, creates small Forths that try to
| limit abstraction. The more featureful ANS Forth community
| tries to focus on a more batteries-included experience and
| these have more in common with most Common Lisp and Scheme
| runtimes.
| eatonphil wrote:
| Yeah I can see that but, to make a comparison, just
| because you can build up high level functions in assembly
| doesn't make it a comparable language to
| Python/JavaScript.
| Karrot_Kream wrote:
| I think Forth is unique in that you actually can be both
| high-level and low-level productive in a single "system",
| but I can also see the perspective that high-level Forth
| is more of just a concatenative language than a high
| level Forth as such. Regardless I think Forth's power is
| that it can be both a very low level language or a high
| level runtime.
| kazinator wrote:
| Also, when we talk about reading code, the reading that matter
| is this:
|
| - how easily can you read incorrect code and find the problem.
|
| - how easily can you convince yourself that correct code is
| correct.
|
| x86 assembly language is highly readable: e.g. it's completely
| unambiguous that "xor eax, eax" clears the eax register,
| independently of the previous or following line of code.
|
| An x86 assembler can tell you that "xor eax" is missing an
| operand.
|
| In Forth, a word can receive insufficient arguments due to
| something distant in the program, not related to that word.
|
| For instance, suppose we push 200 operands onto the stack (o1
| o2 o3, ...), followed by words which are supposed to decimate
| those operands down to one value. Then suppose we remove some
| operand in the middle, like o17. There will necessarily be a
| stack underflow. But that underflow will not necessarily happen
| inside that word which operates on o17. That word will
| cheerfully use o18 as its argument, thinking that it's o17. It
| is the word which operates on o1 that will bomb; at that spot
| in the execution when the correct code would pull o1 from the
| stack, the stack will be empty.
|
| That's a pretty stupid thing to to do yourself for the sake of
| being able to implement a language in one weekend.
| joe_the_user wrote:
| The upshot of the discussion seems to be that the definitions of
| a Lisp and a Forth are so orthogonal that one person correctly
| say "most lisps have no relations to forth and vice versa" and
| another can correctly say "look, a lisp that's also a forth".
|
| How conceptual orthogonality works.
| lizknope wrote:
| I remember using some Sun workstations in the 1990's. They Open
| Firmware boot system used Forth. It was also used for PowerPC
| Macs but I never had any of those.
|
| https://en.wikipedia.org/wiki/Open_Firmware
| agumonkey wrote:
| open firmware was still default in mac up until ~2008 (I bought
| a mac mini to play). I'm not sure it's still there though.
| eatonphil wrote:
| The FreeBSD bootloader was written in Forth for a while. It
| looks like they may have transitioned off it to Lua by now.
|
| https://marc.info/?l=freebsd-current&m=153469833911665&w=2
| spijdar wrote:
| Open Firmware is still used by IBM Power servers, although not
| as the "actual" bare metal firmware[1]. It's instead the
| default firmware interface for the standardized "VM", PAPR. A
| cut-down variant called SLOF is shipped with QEMU for this
| purpose, either for full emulation, or combined with KVM on
| Power hardware for accelerated virtualization.
|
| [1] Technically there's nothing preventing bare metal hardware
| from implementing PAPR, but to my knowledge, no currently
| produced hardware does. Same direction that Sun went with their
| servers late into the game, not long before their acquisition;
| sun4v ran everything inside LDOMs, with the default
| configuration giving all resources to a single LDOM, IIRC.
| macintux wrote:
| As someone who has only _barely_ dabbled in either, they feel
| very similar in philosophy, but I understand that 's superficial
| to some degree.
|
| I have a particular soft spot for Forth in part because W.
| Richard Stevens (RIP) wrote a primer for Kitt Peak National
| Observatory:
|
| http://www.forth.org/KittPeakForthPrimer.pdf (PDF)
| mananaysiempre wrote:
| Very similar philosophies re building up abstractions, DSLs and
| DSL-enabling syntax (half of _Thinking Forth_ is essentially
| proselyzing DSLs), very different philosophies re lowest level
| of abstraction accessible in the language and compound
| datatypes. I'd say that neither of those are superficial.
| zerr wrote:
| Any reasons to code in Forth these days, besides intellectual
| exercise?
| qsort wrote:
| It's very easy to bootstrap and can be made Turing-incomplete
| if needed. Bitcoin script is a Forth IIRC.
| whartung wrote:
| Speaking of this, I've always loved this paper [1] about
| Forth. And it's a real eye opener. It's a real eye opener
| when you understand that primitives such as assignment and
| variable references are, indeed, in Forth, actual primitives.
| Primitives that can be readily changed.
|
| Combine this with a venerable Forth (cross)assembler and it's
| pretty powerful for all of its simplicity. This is
| bootstrapping without even a boot, just need a sniglet.
|
| [1] https://pygmy.utoh.org/3ins4th.html
| dang wrote:
| One old thread:
|
| _Forth vs Lisp_ - https://news.ycombinator.com/item?id=2243877 -
| Feb 2011 (15 comments)
| mikewarot wrote:
| As someone who has written a forth, and knows a tiny sliver of
| what lisp can do, the huge difference is that Forth can't deal
| with arbitrary data structures in anything close to the ease of
| Lisp. If you want to ingest a chunk of source code, tokenize,
| parse and put it all in an abstract syntax tree, you're far
| better off doing it in lisp.
|
| Forth doesn't really do data structures. Stoical is a forth
| variant that did, but it died out.
| 7thaccount wrote:
| There are a lot of Lisps out there, but even more Forths (like
| the one you've written), although people like to argue what it
| means to be a Forth.
|
| One desktop/server Forth that I have enjoyed is 8th and it is a
| Forth in the since that it is a concatenative language using
| words and a stack, but it also is like GForth in that it comes
| with garbage collection, while it also has support for various
| data structures like arrays/maps/JSON/matrix, file IO, GUI,
| database, cross compilation...etc. It still takes my brain
| awhile to use, but my workflow is pretty similar to the one I
| use with Python.
___________________________________________________________________
(page generated 2021-11-17 23:00 UTC)