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

Easy Forth (2015)

skilldrick.github.io

Post reply on HN
Print view View original

121–128 of 128 posts

Re: Easy Forth (2015)

#121

Post by kabdib »

bxparks wrote: post #105
kabdib wrote: post #82

Earlier quoted context omitted.

> My problem is that I cannot see how control flow works in Forth, e.g. a simple if-then-else. figuring this out for my own FORTH interpreter was a moment i still remember, nearly 50 years later. quite a revelation

In my opinion, a language that requires a programmer to have a "revelation" to understand basic control flow is not a language that is useful or practical for solving real world problems. I would prefer to write in assembly language than write in Forth. Which is what I have done with one of my current projects. With assembly language, there is a good chance that a random person with some minimal programming skills wo…

i understood how to use IF/ELSE/THEN in FORTH. my "revelation" was figuring out how to do the code generation for it. i was in high school :-)

i definitely prefer assembly to FORTH. i have direct and rather terrible experience with this after watching a few people try to ship a cartridge video game in FORTH

Re: Easy Forth (2015)

#122

Post by eschneider »

kragen wrote: post #112
eschneider wrote: post #111

Earlier quoted context omitted.

Very much this. Even when programming for constrained environments, it's almost never necessary to self-host anymore. It's easy to use host-side tools to crunch code down to something that'll work on whatever the target is. From a practical standpoint, one of the few modern uses where FORTH shines is as a REPL for new chips/SOCs so you can play around with the hardware and see how things actually work/debug the datab…

Have you been using it for that? Which Forths and which chips have you been using?

Yeah, I've been doing that a bit, mostly with STM32G474 (arm core) chips and my own Forth system. I'm not using it for production code, but I definitely use it for prototyping/experimenting with the SOC to see how the system actually behaves.

A simple Forth REPL gives a nicer environment for poking at the low level hardware than going back and forth with C/C++.

I could easily do production code this way, but TBH, I work with other people and have to share code, so C++ is generally the way to go there. :)

Re: Easy Forth (2015)

#123

Post by mpweiher »

kragen wrote: post #119
mpweiher wrote: post #116

Earlier quoted context omitted.

Forth has always intrigued me as one of those languages (APL and Mumps also come to mind) that appears to have a superpower, for example expressing somewhat complex systems compactly, while at the same time also being flawed enough so that this superpower only appears to be applicable to a small niche. Given the somewhat sorry state of (lack of) expressiveness and accompanying bloat in programming in general, it woul…

I agree about Forth being a fatally flawed language with superpowers, although I think we could easily have ended up in a world where Forth played the role of C, which has its own fatal flaws. Yes, compile-time metaprogramming is very much "how things are done". This is simplified by not having syntax, but I don't think they're inseparable; you could imagine building up a compiler in the same way from an almost-as-mi…

Thanks a lot for that very comprehensive and insightful answer! Still digesting it... :-)

I did quite a bit of work in Postscript, it's a fun and interesting language.

A guess:

1. compile-time metaprogramming is where the magic is. That is the superpower.

2. as you mentioned, compile-time metaprogramming is quite a bit easier when you have a language with little to no syntax. Hence Lisp and Forth.

3. Not having syntax, or maybe more precisely: having a programming model that does not require syntax, is the fatal flaw.

4. Where we are today, the two actually are coupled. And this leads to the common schisms: one side sees the fatal flaw, the other side the superpower.

5. There is both a causal relationship between the superpower and the fatal flaw and a historical relationship (that's where it was easy, so that's where it was done first)

6. However, the coupling may not actually be a necessary one.

Which paper?

Re: Easy Forth (2015)

#124

Post by kragen »

eschneider wrote: post #122
kragen wrote: post #112

Earlier quoted context omitted.

Have you been using it for that? Which Forths and which chips have you been using?

Yeah, I've been doing that a bit, mostly with STM32G474 (arm core) chips and my own Forth system. I'm not using it for production code, but I definitely use it for prototyping/experimenting with the SOC to see how the system actually behaves. A simple Forth REPL gives a nicer environment for poking at the low level hardware than going back and forth with C/C++. I could easily do production code this way, but TBH, I w…

That makes a lot of sense. Have you found a lot of unreported datasheet errata, or is it more a matter of things where the datasheet/user manual just doesn't specify how things work? What's your turnaround time for loading a new C++ firmware image on the thing?

Re: Easy Forth (2015)

#125

Post by kragen »

mpweiher wrote: post #123
kragen wrote: post #119

Earlier quoted context omitted.

I agree about Forth being a fatally flawed language with superpowers, although I think we could easily have ended up in a world where Forth played the role of C, which has its own fatal flaws. Yes, compile-time metaprogramming is very much "how things are done". This is simplified by not having syntax, but I don't think they're inseparable; you could imagine building up a compiler in the same way from an almost-as-mi…

Thanks a lot for that very comprehensive and insightful answer! Still digesting it... :-) I did quite a bit of work in Postscript, it's a fun and interesting language. A guess: 1. compile-time metaprogramming is where the magic is. That is the superpower. 2. as you mentioned, compile-time metaprogramming is quite a bit easier when you have a language with little to no syntax. Hence Lisp and Forth. 3. Not having synta…

Specifically https://www.hpi.uni-potsdam.de/hirschfeld/publications/media.... I read through it once when you mentioned it here a few months ago, but I think it merits a deeper reading, which I haven't finished doing yet.

I think more than necessity, requirements, and fatality we have more of a gradient thing. It isn't necessary to have no syntax to do compile-time metaprogramming, but the effort gradient sort of pushes you in that direction. It isn't impossible to write a web browser in Forth either, just hard.

Re: Easy Forth (2015)

#126

Post by eschneider »

kragen wrote: post #124
eschneider wrote: post #122

Earlier quoted context omitted.

Yeah, I've been doing that a bit, mostly with STM32G474 (arm core) chips and my own Forth system. I'm not using it for production code, but I definitely use it for prototyping/experimenting with the SOC to see how the system actually behaves. A simple Forth REPL gives a nicer environment for poking at the low level hardware than going back and forth with C/C++. I could easily do production code this way, but TBH, I w…

That makes a lot of sense. Have you found a lot of unreported datasheet errata, or is it more a matter of things where the datasheet/user manual just doesn't specify how things work? What's your turnaround time for loading a new C++ firmware image on the thing?

Data sheets are usually 'accurate' as far as they go. I'm often working with pre-production samples so not everything _quite_ works and sometimes it's just handy to experiment and see for yourself what happens. As for getting a new C++ image on new hardware, usually it's just a few days for something basic.

Re: Easy Forth (2015)

#127

Post by kragen »

eschneider wrote: post #126
kragen wrote: post #124

Earlier quoted context omitted.

That makes a lot of sense. Have you found a lot of unreported datasheet errata, or is it more a matter of things where the datasheet/user manual just doesn't specify how things work? What's your turnaround time for loading a new C++ firmware image on the thing?

Data sheets are usually 'accurate' as far as they go. I'm often working with pre-production samples so not everything _quite_ works and sometimes it's just handy to experiment and see for yourself what happens. As for getting a new C++ image on new hardware, usually it's just a few days for something basic.

I see! I meant on existing hardware, as an alternative to typing a command in a REPL. I was thinking that recompiling and reflashing might be somewhere between 100 milliseconds and a minute.
Post reply on HN