Live data from Hacker News

Forth: The programming language that writes itself

ratfactor.com

61–70 of 174 posts

Re: Forth: The programming language that writes itself

#61
RPN interpreters require very little core memory. So they were popular with computers where core memory was under ten kilobytes.

But its horrible for software engineering with multiple programmers and large codebases. Lacks structures, interfaces, modules, data abstraction that you expect in a modern language. We called it the "Chinese food" of coding- ten minutes later you had nomidea what you just coded.

Re: Forth: The programming language that writes itself

#62
post #3

Why is it that languages like this don't scale? It's not the first time I see a powerful language that got forgotten. Other examples include SmallTalk and Common Lisp (tiny community). It is because some languages are "too powerful"? What does that say about our industry? That we're still not that advanced of a specie to be able to handle the full power of such languages? I say that because it seems languages that ar…

It's a different solution for a different time.

Forth was an excellent way to write a powerful and expressive programming language that could self-host with a bare minimum of assembly language "bare metal" programming.

The fridge-sized computer that Forth was originally developed on had double-digit kilobytes of memory (maybe 8192kwords, with 16-bit words) and clocked instructions through at a whopping 300kHz or so. The microcontroller that drives the Caps Lock LED on your keyboard is a hundred times faster with a hundred times the memory.

These days we do not need to squeeze editor, compiler, and target binary into such a tiny machine. If you're developing for a microcontroller you just use C on your "big" computer, which is unimaginably more powerful.

In the olden days of the 1990s I used a development system for embedded stuff that was written in and targetted Forth on a Z80 with a whopping 64kB of RAM and 5.25" floppies, but that was at least ten years old and five years out of date at the time.

You're probably reading my words on a slice of glass the size of half a sandwich that contains more computing power than existed in the whole world when Forth was first written.

It's a shame because writing something like Forth from the ground up (and I mean, assembly code to load the registers to start the ACIA to begin transmitting text to the terminal) perhaps in an emulated early 80s home computer is a great way to get a sense of what the chip behind it all is doing, and I feel that makes you a better programmer in "real" languages like Go or Python or C.

Re: Forth: The programming language that writes itself

#63
post #29
post #13

Earlier quoted context omitted.

I don't think "power" is really that helpful a metric in determining how useful a programming language is. If you think of programming from the standpoint of trying to specify the program you want out of all of the possibly programs you could write, one of the most helpful things a programming language can do is eliminate programs that you don't want by making them impossible to write. From that standpoint, constrain…

And at the extremes, too much power makes a tool less useful. I don’t drive an F1 car to work, I don’t plant tulips with an excavator, I don’t use a sledgehammer when hanging a picture. Those tools are all too powerful for the job.

planting flowers? trowel

planting foundations? excavator

once you specify "the job", the best tool is "the solution" to that job only. anything else is excess complexity

however if "the job" is unspecified, power is inverse to the length of "the solution"

so is constraint of power bad?

--

a fascinating question

just like music can be created by both additive and subtractive synthesis; every line of code creates both a feature and a constraint on the final program

in which case power can be thought of as the ability to constrain...

Re: Forth: The programming language that writes itself

#64
post #46

Earlier quoted context omitted.

One thing I note is that all of the languages you name are very far from the machine. Also Forth is not close to the modern machine. Note that it only has two integer types and the larger one can be aligned either way you make sure it is not.

> One thing I note is that all of the languages you name are very far from the machine Common lisp is one step away from assembly - you disassemble any function and it is, in fact, a valid strategy of one wants to check the compiler optimizations.

I googled a bit on how common lisp is compiled. Apparently it is possible to add some sort of type hints and ensure that parameters/variables have a certain type. If one uses that for most code, it would potentially be enough to qualify as being close to the machine.

Re: Forth: The programming language that writes itself

#65
post #40

Earlier quoted context omitted.

That argument implies that you would actually see these languages in communities with large SV style salaries which isn’t the case. It turns out that “brick layer” languages are also easier to understand not just for the next person taking over but yourself after a few months. That’s valuable even to yourself unless you value your time at 0.

Why? The less the VCs have to spend with employees the better. See the famous quote about Go's target audience, or 2000's Java being a blue colour job language. Not only do languages like Lisp, Forth, Smalltalk require a people to actually get them, a bit like the meme with burritos in Haskell, they suffered from bad decisions from companies pushing them. Lisp suffered with Xerox PARC, Symbolics and TI losing against…

psst blue "collar" :-)

Re: Forth: The programming language that writes itself

#66
post #36

I used to be a fan of these languages like Lisp and Forth and Joy (and Factor and Haskell), but then I found that what I a really long for is just (untyped) lambda calculus (as a universal language). (Combinatory logic is just a similar representation of lambda calculus, but the differences go away quickly once you start abstracting stuff.) I think expressing semantics of all (common) programming languages in lambda…

> And we should aim for that, the babel tower of languages doesn't really help anyone.

What exactly do you mean with this? That the amount of programming languages available isn't actually helpful, it's detrimental?

Re: Forth: The programming language that writes itself

#67
post #29

Earlier quoted context omitted.

And at the extremes, too much power makes a tool less useful. I don’t drive an F1 car to work, I don’t plant tulips with an excavator, I don’t use a sledgehammer when hanging a picture. Those tools are all too powerful for the job.

planting flowers? trowel planting foundations? excavator once you specify "the job", the best tool is "the solution" to that job only. anything else is excess complexity however if "the job" is unspecified, power is inverse to the length of "the solution" so is constraint of power bad? -- a fascinating question just like music can be created by both additive and subtractive synthesis; every line of code creates both…

that is quite wild...

it implies expressivity is the ability to constrain

it implies drawing on a page, or more broadly, every choice we make, is in equal parts a creative and destructive act

so maybe life, or human flourishing is choosing the restrictions that increase freedom of choice? it's so meta it's almost oxymoronic; concretely: we imprison people to maximize freedom; or, we punish children with the aim of setting them free from punishment

this is the same as the walk from law into grace found in Christian ethics

maybe the ultimate programming language then, provides the maximal step down that path, and this is also the most useful definition of "power"

i.e. place on people those restrictions that increase their ability to choose

Re: Forth: The programming language that writes itself

#68
post #64

Earlier quoted context omitted.

> One thing I note is that all of the languages you name are very far from the machine Common lisp is one step away from assembly - you disassemble any function and it is, in fact, a valid strategy of one wants to check the compiler optimizations.

I googled a bit on how common lisp is compiled. Apparently it is possible to add some sort of type hints and ensure that parameters/variables have a certain type. If one uses that for most code, it would potentially be enough to qualify as being close to the machine.

Yes, in a way common lisp code can be locally lowered to a well-typed language.

What people do is just write code they way they usually write dynamic lisp and then add types to functions where necessary for performance.

SBCL generates good assembly, btw.

Re: Forth: The programming language that writes itself

#69
"Working without names (also known as implicit or tacit or point-free programming) is sometimes a more natural and less irritating way to compute. Getting rid of names can also lead to much more concise code. And less code is good code."

Does Forth really reduce the burden of naming things? You don't name results but don't you have to pay for it with the burden of naming words? (My impression is that there's more words in a Forth program than functions in an equivalent program in a language that has named variables).

Re: Forth: The programming language that writes itself

#70
post #36

I used to be a fan of these languages like Lisp and Forth and Joy (and Factor and Haskell), but then I found that what I a really long for is just (untyped) lambda calculus (as a universal language). (Combinatory logic is just a similar representation of lambda calculus, but the differences go away quickly once you start abstracting stuff.) I think expressing semantics of all (common) programming languages in lambda…

> And we should aim for that, the babel tower of languages doesn't really help anyone. What exactly do you mean with this? That the amount of programming languages available isn't actually helpful, it's detrimental?

Everyone should be free to unite behind my choices. It's obviously what is best for everyone.
Post reply on HN