Live data from Hacker News

Thoughts on Forth Programming

call-with-current-continuation.org

91–97 of 97 posts

Re: Thoughts on Forth Programming

#91
post #4

This quote stood out as sounding quite far-fetched: "on many CPUs the interpreter consists of two or three machine instructions". Can someone point to an example?

The book “Threaded interpretive languages” by R. G. Loeliger has details on how Forth & Forth like languages are built re: core interpreter & threading of words.

That is the best book anyone has ever loaned me and some day I plan on returning it.

Re: Thoughts on Forth Programming

#92

> One such property is the use of reverse polish notation and the lack or eschewal of local variables. What do you gain by eschewing local variables in favor of reverse polish notation that throws values onto a stack?

As someone else mentioned you get many natural factorization points because often you can just copy a portion of code verbatim into a new word.

Of course, you can implement named parameters and local variables in Forth. There is even a standard for locals in ANS Forth.

Re: Thoughts on Forth Programming

#93

Earlier quoted context omitted.

On a new OS, forth often has a "first mover" advantage. E.g. some of the first apps for MacOS were developed in forth. It's also useful when limited resources are available. OO forth is quite pleasant to work in, if you really want to. That said, I wish somebody would have created a statically typed forth.

http://kittenlang.org/

I wish ... would have ... 20 years ago.

Re: Thoughts on Forth Programming

#94
post #10

Earlier quoted context omitted.

That's not true at all. I know multiple people who are incredibly productive in Forth environments, though I don't use it myself. Pretending that it's like writing in JVM bytecode (despite some overlap between the two) is completely unfounded. Your claim that C# and Java won based on merits is similarly unfounded: they won because they have major corporate backing. There are countless languages before and after that…

C# and Java won over CIL and bytecode because of corporate backing? You're ridiculous and can't even read. I didn't compare Java to Forth, I compared Java to pure JVM bytecode, both of which are backed by the same corporations. As to people being productive in Forth, that's singular cases and/or fairytales. Let's see some real, large, valuable software written in Forth. Browsers, web frameworks, GUI frameworks, text…

You can't attack another user like that on HN, no matter how strongly you feel or disagree. Please make your substantive points thoughtfully in the future.

https://news.ycombinator.com/newsguidelines.html

Re: Thoughts on Forth Programming

#95

Can you please give some examples on those who are extremely productive using FORTH? I'm intrigued. I think FORTH could be very useful to someone who prefers to work alone or in small group, but I'm not sure how do they use it in daily life.

This subthread was originally in reply to https://news.ycombinator.com/item?id=21821841, but we detached it because it is full of information and can stand on its own.

Re: Thoughts on Forth Programming

#96
post #73
post #52

Forth style is great for writing but very hard for reading. I'm playing around with the idea that you use a Forth-like language to interactively develop code. The steps you perform become AST nodes. Then when you want to read it, it comes out in another form. This is more ideal because it is more interactive and you can see the immediate result every step of the way. This is different than writing traditional code be…

What I would like to have (and looks quite similar to what you are describing) is some APL interpreter (or J or K...) with an RPN input method. The idea comes from HP calculators, where you use RPN to "build" algebraic expressions. I have many ideas for such a system, but it will require much experimentation to get it right and, at this moment, is just vaporware.

Have you seen Lang5? It's a stack-based array language.

http://lang5.sourceforge.net/tiki-index.php

Re: Thoughts on Forth Programming

#97
post #48

The main problem with such a stack based language for 'serious' programming would, I think, be the lack of dynamic allocations. The stack is all nice and fine if pieces of memory only need to be preserved inside functions and their children but if memory is to be allocated for an amount of time that is determined at run time there basically does not seem to be anything to do that. Any kind of solution to this would p…

This can be trivially achieved by moving the dictionary pointer and reserving some space on the heap.
Post reply on HN