Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Forth Programming

call-with-current-continuation.org

Post reply on HN
Print view View original

81–90 of 97 posts

Re: Thoughts on Forth Programming

#81

Post by skybrian »

eckza wrote: post #79
skybrian wrote: post #75

The classic problem with inventing your own language is that now you can't understand anyone else. If we're going to have widespread communication then we need widely-understood languages and libraries. The goal should be to replicate understanding. We need to evolve a common vocabulary rather than ending up with nearly as many private dialects as programmers. Publishing libraries and gaining users for them should be…

> Forth is quite "invidualistic", tailored to single persons or small groups of programmers, mostly because it is natural and relatively straightforward to implement a Forth system yourself (and you should) and because the language is inherently malleable and adapts to your needs. Therefore what I write is just one way of seeing Forth, which is both a programming language and a engineering philosophy. Sometimes... yo…

As a specific example, I'm dabbling in embedded programming (like Arduino) and switched to Teensy for the audio library. I guess the Forth philosophy would be to figure out how to program real-time audio from the microprocessor's datasheet? I'm not really a fan of C++ but I knew better than to go that deep.

Arduino itself is a good example of how a decent, common abstraction can help users get started.

Re: Thoughts on Forth Programming

#82

Post by jes5199 »

skybrian wrote: post #81
eckza wrote: post #79

Earlier quoted context omitted.

> Forth is quite "invidualistic", tailored to single persons or small groups of programmers, mostly because it is natural and relatively straightforward to implement a Forth system yourself (and you should) and because the language is inherently malleable and adapts to your needs. Therefore what I write is just one way of seeing Forth, which is both a programming language and a engineering philosophy. Sometimes... yo…

As a specific example, I'm dabbling in embedded programming (like Arduino) and switched to Teensy for the audio library. I guess the Forth philosophy would be to figure out how to program real-time audio from the microprocessor's datasheet? I'm not really a fan of C++ but I knew better than to go that deep. Arduino itself is a good example of how a decent, common abstraction can help users get started.

you could probably get a lot more done on arduino by writing a tiny forth in arduino C and then writing your applications in _that_

Re: Thoughts on Forth Programming

#83

Post by JdeBP »

DonHopkins wrote: post #37
it wrote: 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?

FORTH has both an "inner interpreter" and an "outer interpreter" (aka the compiler, but that also works interactively like an interpreter). The inner interpreter is the thing that threads between words, and is typically an assembly function named "NEXT", which can be just a few instructions. Here is the FIG-FORTH 6502 implementation of "NEXT" (which is a bunch of instructions since the 6502 has 8 bit registers and si…

One can get a 6502 to do NEXT in a single instruction and have an IP register in hardware ... if one sticks a coprocessor onto it. Witness the KimKlone.

* http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_shor... (https://news.ycombinator.com/item?id=16564257)

Re: Thoughts on Forth Programming

#84

Post by eckza »

jes5199 wrote: post #82
skybrian wrote: post #81

Earlier quoted context omitted.

As a specific example, I'm dabbling in embedded programming (like Arduino) and switched to Teensy for the audio library. I guess the Forth philosophy would be to figure out how to program real-time audio from the microprocessor's datasheet? I'm not really a fan of C++ but I knew better than to go that deep. Arduino itself is a good example of how a decent, common abstraction can help users get started.

you could probably get a lot more done on arduino by writing a tiny forth in arduino C and then writing your applications in _that_

This seems to be the preferred methodology, actually. One of my close friends is an embedded systems developer and this is what he does.

One of the big advantages of Forth is that it's (apparently) pretty trivial to implement on your own, in whatever environment you choose.

Re: Thoughts on Forth Programming

#85

Post by eckza »

skybrian wrote: post #80
pavlov wrote: post #76

Earlier quoted context omitted.

The counterpoint is that every software project of reasonable complexity evolves its own language anyway. When that is layered on top of overly generic libraries/frameworks, you may end up using only parts of the underlying vocabulary. Now the project is stuck with two vocabularies. Learning the generic one doesn't get you far and may be actively misleading ("yeah, we never use features X and Y of the framework, inst…

Yes, that's a problem with code sharing gone wrong. Another problem is framework churn where popular libraries aren't stable. When good, stable libraries aren't available then it may be better to reimplement than to use a bad one. But these problems are, in their way, a sign of success at the package management level. If you don't have good package management then people probably aren't having much success at sharing…

> We should still aim for building and sharing stable, well-understood, high-quality code libraries.

And I agree with that 100% - but that isn't the solution to every single problem. That's all I'm saying.

Re: Thoughts on Forth Programming

#86

Post by roywiggins »

jacquesm wrote: post #44
kabdib wrote: post #29

Earlier quoted context omitted.

I've met a couple of really good FORTH programmers over the years. They were humble about it, were also happy to use other tools in their work, and they just happened to be working on projects that were really good fits for FORTH's strengths. I've met a lot more FORTH fanatics, people for whom FORTH was the answer no matter the problem; people who just would not shut up about how superior and fantastic it was, and ha…

> I've met a lot more FORTH fanatics, people for whom FORTH was the answer no matter the problem; people who just would not shut up about how superior and fantastic it was, and have you seen the light, brother? I've seen exactly one Forth programmer like that, they are simply too rare. But the stereotype language fanatic is easily recognized in other language eco-systems, Perl and Rust have a disproportionately high…

I think some of it may come from being forced to use X language, and then finding Y language, and realizing that it fits your mindset perfectly, and deciding that everyone using X must be idiots. Ie, these partisans were exposed to other languages, but never particularly liked them, until this new thing came along that seemed like a revelation. The zeal of a convert, sort of thing.

I haven't spent enough time with Forth or Rust to say, but I can see why both of them could seem like that to people. Forth, especially, has a sort of philosophical/hacker bent that is inherently appealing to a certain kind of person (including me!). Whereas I can't imagine Java ever winning someone over like that (though I'm sure it has).

Re: Thoughts on Forth Programming

#87

Post by vanderZwan »

upofadown wrote: post #71
arnautdaniel wrote: post #68

Anyone who wants to see a modern forth with elements of common lisp that is focused on application development should check out Factor. Concatenative languages are really fun to use once you get over the initial hump. https://github.com/factor/factor

Factor is a good example of what the writer of the linked article considers: >...what just ends up being some sort of Lisp with a funny notation.

Where do you think Kitten would end up?

http://kittenlang.org/

Re: Thoughts on Forth Programming

#88

Post by [deleted] »

skybrian wrote: post #75

The classic problem with inventing your own language is that now you can't understand anyone else. If we're going to have widespread communication then we need widely-understood languages and libraries. The goal should be to replicate understanding. We need to evolve a common vocabulary rather than ending up with nearly as many private dialects as programmers. Publishing libraries and gaining users for them should be…

[deleted]

Re: Thoughts on Forth Programming

#89

Post by steveeq1 »

skybrian wrote: post #75

The classic problem with inventing your own language is that now you can't understand anyone else. If we're going to have widespread communication then we need widely-understood languages and libraries. The goal should be to replicate understanding. We need to evolve a common vocabulary rather than ending up with nearly as many private dialects as programmers. Publishing libraries and gaining users for them should be…

Then how can paradigm shifts occur?

Re: Thoughts on Forth Programming

#90

Post by theamk »

kick wrote: post #10
LessDmesg wrote: post #9

Earlier quoted context omitted.

This can work, but it's incredibly tedious and not worth the trouble. Writing in Forth is like writing in pure CIL or JVM bytecode (they're both stack machines like Forth). Sure, you can do it, but if it was so rewarding, people wouldn't be using Java or C#.

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…

I don't think it is major corporate backing -- for example, neither Perl nor PHP had one, and they still are (and always were) vastly more popular than Forth.

It seems to me that Forth only works for certain people, and those people are quite rare. For the majority of programmers, almost every other language will make them much more productive.

Post reply on HN