[HN Gopher] Forth: The programming language that writes itself
___________________________________________________________________
Forth: The programming language that writes itself
Author : ingve
Score : 144 points
Date : 2023-02-25 14:03 UTC (8 hours ago)
(HTM) web link (ratfactor.com)
(TXT) w3m dump (ratfactor.com)
| NikkiA wrote:
| My biggest problem with forth has always been the curmudgeonly-
| ness of the community, it's like they feel compelled to do things
| at exactly 1800 to how the rest of the computer industry works,
| even this webpage throws out every norm about how web pages must
| be navigated, and feels like something from the 1970s while still
| looking modern.
|
| I love the language, at least part of it, but the community and
| that 1800 shift always feels like any attempt to utilise forth is
| swimming upstream in monsoon season.
| zozbot234 wrote:
| It's important to realize _why_ the computer industry works a
| certain way and how that compares to different approaches. For
| instance, there 's very real issues with stack machines when
| you try to generalize them to parallel programs - including
| extracting fine-grained parallelism from sequential code. The
| most elegant approach is probably dataflow, but that's still a
| far cry from the simplicity of the FORTH-inspired,
| concatenative approach. The register-based CPU's we use are a
| pragmatic, middle-of-the-road approach.
| jvanderbot wrote:
| This appears very insightful, but I can't grok the
| differences. Got an explainer handy that I and others might
| start with?
| shaunxcode wrote:
| I personally really enjoyed the site layout choices. I viewed
| it on a phone and it was like you are given a little chunk of
| info to think about as you scroll to the next.
| armitron wrote:
| This is one of its greatest strengths. The Forth community,
| large parts of which treat Forth as a secret weapon of sorts,
| has no particular reason to make concessions on the altar of
| popularity. This attitude helps to attract out-the-box thinkers
| and people with a tendency to go against established norms.
|
| The SVFIG meetings have been traditionally excellent in
| showcasing these somewhat unique in today's mainstream
| programming culture strengths.
| uonpopular_th wrote:
| Working as intended.
|
| WON'T FIX.
| omeysalvi wrote:
| Learning languages like these feels like the premise of
| Arrival(2016) where learning a new language expands the way you
| think about and solve problems. I'm trilingual like most Indian
| people but I suspect learning languages like Japanese or Mandarin
| which use a different, pictorial way of representing words would
| be a similar way to improve cognition.
| jallmann wrote:
| Try one of the sign languages. Not sure where you are located,
| but many countries have their own, including India.
| haolez wrote:
| I've had an unexpected epiphany when I dug deeply into
| Makefiles. For some reason, its spreadsheet-like logic clicked
| with me an influenced my programs elsewhere.
| Pompidou wrote:
| What about hungarian language? It's like if it was created by
| some programmer or mathematician.
| omeysalvi wrote:
| I've heard about how difficult Hungarian grammar is. The
| closest analog I can think of is Sanskrit which we had to
| study for a few years in school. They're still discovering
| more things about the language that were lost for thousands
| of years: https://www.popsci.com/science/sanskrit-
| puzzle-2500-years-ol...
| Pompidou wrote:
| I remember also when I was studying philosophy. The amount
| of non consensual traduction and interpretation from
| ancient greek is amazing. Ans what about the Epiousion
| case.
|
| I agree with you : hungarian is maybe some contemporary
| equivalent of the great language from the past such as
| latin, greek or sanskrit, in regard of scientific thinking.
| Nevertheless, its a agglutinative language, and the logic
| behind is different.
| PaulHoule wrote:
| I've had people that they like the ontological orientation of
| Mandarin, not so much the fact that the "words" are pictoral
| but the way they are combined systematically.
| Pompidou wrote:
| It raises the question of the (eventual) link between the
| grammar of 'spoken' language and our habilty to think the
| world. I personnaly think almost every human natural
| languages have the power to express almost everything with
| the help of circumlocution.
| teddyh wrote:
| _LISP is worth learning for a different reason - the profound
| enlightenment experience you will have when you finally get it.
| That experience will make you a better programmer for the rest
| of your days, even if you never actually use LISP itself a lot.
| (You can get some beginning experience with LISP fairly easily
| by writing and modifying editing modes for the Emacs text
| editor, or Script-Fu plugins for the GIMP.)_
|
| _It's best, actually, to learn all five of Python, C /C++,
| Perl, and LISP. Besides being the most important hacking
| languages, they represent very different approaches to
| programming, and each will educate you in valuable ways._
|
| http://www.catb.org/~esr/faqs/hacker-howto.html#skills1
| jvanderbot wrote:
| Though I'm not a Rust fanatic, I will say that spending time
| programming in Rust has made me a better C++ programmer.
| proper_elb wrote:
| This would be my 2023 list: Python, C, LISP, Fortran,
| Haskell, Prolog, SmallTalk. Also likely Rust, it might
| replace C in my list and is quite similar to Haskell in some
| ways, particularly when it comes to turning runtime errors to
| compile time error.
| bmitc wrote:
| > LISP is worth learning for a different reason - the
| profound enlightenment experience you will have when you
| finally get it.
|
| I like Lisp (or rather Scheme and Racket), but I have never
| understood this perspective. The only thing I can think of
| that Common Lisp does truly uniquely is its condition system.
| I feel like something like Prolog is much more profound in
| the way that it reshapes how to think about programming.
| teddyh wrote:
| What LISP has, uniquely, is its macro system which, unlike
| text-based macro system like C, operate on the abstract
| syntax tree level.
| agumonkey wrote:
| prolog is another step that's for sure but lisp is the
| gateway drug
|
| the emphasis on thin syntax, homoiconicity is really no
| joke to me. I'm finishing queinnec's l.i.s.p but writing
| some of it in python and using OO requires so many layers
| and layers to reacreate what is mostly various sexp trees
|
| it puts away a lot of sequential imperative, replaced by
| functional/function oriented, it may look trivial today but
| it's been like this since the 70s
|
| and about CL/CLOS, one could mention the MOP, the
| multimethod+combinations too
| jacquesm wrote:
| May I suggest adding PROLOG to that list? Or Erlang, for yet
| another different take on programming.
| crabbone wrote:
| My biggest problem with Forth is that you simply cannot start
| reading a program at an arbitrary point because you only have few
| valid entry points where you know that the stack is empty.
| Otherwise you just have no idea what's going on.
|
| This is where it differs from languages which try to guard the
| scope, but is, in a way similar to the problems created by
| violating the locality of the problem by using global variables.
|
| I feel like Forth might have evolved to mitigate this problem (as
| well as many similar ones, like not needing to specify the number
| or names of arguments to the subroutines, or not really having
| much structure to the routines that can be expressed through
| something like paired delimiters or indentation...) but,
| unfortunately, it didn't. Or, maybe I never found any descendants
| that would take the language further towards implementing some of
| the more modern ideas about how to structure large programs.
| l_theanine wrote:
| This is reaching new heights of annoying ux. Flicks itself all
| over the place. Edge on iOS.
| optimalsolver wrote:
| A great introduction is the book Starting Forth [0].
|
| It has the most charming illustrations I've ever seen in a text
| book.
|
| [0] https://www.forth.com/starting-forth/
| ofalkaed wrote:
| I love forth and stack based languages in general, writing a
| forth implementation has become my standard way to learn
| languages. Lately I have been playing with MinForth[0], it
| transpiles to C so you can effortless mix C in with the forth and
| get easy access to C libraries, good fun.
|
| 0: https://minforth.sourceforge.io
| mrtomorrow wrote:
| "When I was a wee programmer, I would sit around the virtual
| Usenet campfires listening to the tall tales and legends of the
| elders."
|
| When I was a wee programmer, we'd sit around reddit and talk
| about no wipe poos.
| submeta wrote:
| I learned about stack based programming when I bought a HP28s
| calculator in 1988. It could be programmed in its Forth like
| language, had data structures like lists, arrays, matrices, and
| symbols. It was also my intro to Scheme. It was like revelation.
| When everyone else around me was learning C or Pascal, where
| arrays had fixed lengths, I had seen the future with dynamic data
| structures. I could implement and test ideas that would take me
| ten or a hundred times more LOC.
|
| Now over 30 years later I still use a stack to implement tree
| traversal instead of using recursion.
| zozbot234 wrote:
| > Now over 30 years later I still use a stack to implement tree
| traversal instead of using recursion.
|
| Recursion is the same as "using a stack". It's just using the
| system stack generally, which might not be what you want.
| submeta wrote:
| But it is possible to get a stack overflow error when using
| recursion to implement tree traversal if the depth of the
| tree is too large or if the recursion is not properly
| managed.
|
| Implementing tree traversal iteratively can help avoid that
| because it does not rely on recursive function calls that can
| build up on the call stack. Instead, an iterative approach
| uses an explicit data structure (such as a stack or queue).
| skybrian wrote:
| Well, you could run out of memory implementing a stack as
| an array too. It all depends on what the limits are.
| gareth5851 wrote:
| loved this
| Kapura wrote:
| Is there a version of this website that works better for non-
| mobile browsers?
| PaulHoule wrote:
| I'd say it works about the same on desktop and mobile. You
| might prefer something that isn't so wasteful of whitespace and
| doesn't make you scroll but that could be accomplished in a way
| that works the same on desktop and mobile.
| foresto wrote:
| Have you tried Firefox's reader view? I find it very helpful
| for annoying site designs, especially after adjusting its style
| settings.
| mikewarot wrote:
| Stoical is an older forth with an interesting twist. 'string is a
| quoted string that is terminated by a space. Colon takes a string
| parameter, to avoid a lot of "compile mode" nonsense.
|
| To define the cube function 'cube : dup dup * * ;
| teddyh wrote:
| > _' string is a quoted string that is terminated by a space._
|
| Sounds like LISP symbols, which have the same syntax, are also
| essentially strings, and are also used to refer to names of
| function and variables.
| version_five wrote:
| In case it's new to anyone, I recommend going through the jones
| forth "literate program" - even if you don't understand assembly.
| You can try porting it to a language you know, it gives a good
| understanding of how forth works
|
| https://github.com/nornagon/jonesforth/blob/master/jonesfort...
| bitexploder wrote:
| Also just learn assembly. The basics take a half hour to grasp
| if you have any exposure to programming :)
| Nadya wrote:
| And make it a fun ASM. Like 6502 [0].
|
| [0] https://skilldrick.github.io/easy6502/
| bitexploder wrote:
| My favorite learning assembly. It all mostly applies to
| every other Von Neumann machine too.
| messe wrote:
| Oh, nice, Jones forth! I second the recommendation to read
| through it. I ported this to ARM assembly years ago, and it was
| a lot of fun. No idea where that program is now, unfortunately.
|
| Now that I'm using Apple Silicon day to day, maybe it's time I
| try rewriting it for ARM64.
___________________________________________________________________
(page generated 2023-02-25 23:00 UTC)