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

Levels of code in Forth programming (2002)

ultratechnology.com

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Levels of code in Forth programming (2002)

#11

Post by lidHanteyk »

theamk wrote: post #8

> Portability is not possible. Real applications are closely coupled to hardware. Change the platform and all the code changes Some lessons simply did not age well.... Even in world of today's microcontrollers, which often have kilobytes of RAM and very different CPU styles, people still write mostly hardware abstracted code.

Most code should be abstract, because the things that are specified are abstract. Some code needs to be closely coupled to hardware, but most code should only need to be closely coupled with other code.

Re: Levels of code in Forth programming (2002)

#12

Post by nine_k »

To sum up Chuck Moore's quotations: you write code that takes all of the machine, and you got to write all of the code. If you have this, you can squash out all abstraction and build the ideal solution directly.

This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head.

This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews.

This means that you have trouble sharing code with yourself in your next project.

You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine.

I personally think that deep optimization is something that the machine should do, they are better than humans at this most of the time. And humans should do want machines currently can't.

Re: Levels of code in Forth programming (2002)

#13

Post by madhadron »

bcherny wrote: post #10

This is a really interesting read, and as someone who’s almost exclusively programmed in high level languages, this approach seems alien to me. A couple of questions: 1. Is it possible to write complex, modern applications (things like browsers, photo editors, etc. — things that would take millions of lines of Java or JS) using this style of programming? 2. What is “sourceless programming”? Where is a good place to l…

1. "This style" is kind of hard to pin down. If you mean Chuck Moore's dramatic minimalism, then, yes, but it won't resemble what most people in computing expect from a browser or photo editor. If you mean expressing the abstractions you want directly in the primitives you have without bothering about layers or even accepting the idea of higher vs lower levels, then, yes, certainly. It requires a lot of unlearning, though.

2. Sourceless programming was something Chuck Moore tried for a while where he designed a machine that was the virtual machine he wanted to program, implemented it in hardware, and then edited byte code directly for it. Later he stepped back and went to colorForth, which has the source/binary separation we are all accustomed to.

Re: Levels of code in Forth programming (2002)

#14

Post by Twisol »

nine_k wrote: post #12

To sum up Chuck Moore's quotations: you write code that takes all of the machine, and you got to write all of the code. If you have this, you can squash out all abstraction and build the ideal solution directly. This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head. This means that you have a certain trouble sharing the code with your col…

My takeaway was that you're always writing against a machine. The difference is whether you're writing against a physical hardware machine or an abstract virtual machine. OSes and VMs abstract over existing machines and present a virtual interface for the sake of portability, but they're still themselves machines.

You're still coding against a machine, and you still have to spend time learning the vicissitudes of that machine. But you also have the impedance mismatch between the virtual machine you're developing against and the physical machines you intend the software to run on. All software abstractions are, to some extent, leaky.

Re: Levels of code in Forth programming (2002)

#15

Post by bcherny »

madhadron wrote: post #13
bcherny wrote: post #10

This is a really interesting read, and as someone who’s almost exclusively programmed in high level languages, this approach seems alien to me. A couple of questions: 1. Is it possible to write complex, modern applications (things like browsers, photo editors, etc. — things that would take millions of lines of Java or JS) using this style of programming? 2. What is “sourceless programming”? Where is a good place to l…

1. "This style" is kind of hard to pin down. If you mean Chuck Moore's dramatic minimalism, then, yes, but it won't resemble what most people in computing expect from a browser or photo editor. If you mean expressing the abstractions you want directly in the primitives you have without bothering about layers or even accepting the idea of higher vs lower levels, then, yes, certainly. It requires a lot of unlearning, t…

Thanks for the reply!

> but it won't resemble what most people in computing expect from a browser or photo editor.

In the sense that an end user would interact with some low level API primitives, rather than a full GUI? I’d love more examples or metaphors, or maybe a link where I could learn more.

Re: Levels of code in Forth programming (2002)

#16

Post by petjuh »

haolez wrote: post #4

Forth is pretty amazing. It really delivers on that old promise of “a language that will make you a better programmer in other languages”. However, from my experience, since there is basically no syntax, all Forth programs tend to be a DSL for the problem at hand. It’s almost like having to learn a new language ok each new project. It’s like a complete opposite of what makes Go great.

In a sense, any API that has its own functions and data structures becomes like a DSL. For example OpenGL feels like its own language, even when you write it in C or C++, or C#.

Re: Levels of code in Forth programming (2002)

#17

Post by TeMPOraL »

petjuh wrote: post #16
haolez wrote: post #4

Forth is pretty amazing. It really delivers on that old promise of “a language that will make you a better programmer in other languages”. However, from my experience, since there is basically no syntax, all Forth programs tend to be a DSL for the problem at hand. It’s almost like having to learn a new language ok each new project. It’s like a complete opposite of what makes Go great.

In a sense, any API that has its own functions and data structures becomes like a DSL. For example OpenGL feels like its own language, even when you write it in C or C++, or C#.

Moreover, in any nontrivial application, you have modules and layers of abstractions - and those boundaries are DSLs on their own. It's actually good to think of them as languages the client code will use to write its solutions in (SICP makes this point early in the book too).

People are getting too hung up on the word "language", like it was something only the most experienced and smartest of programmers were allowed to build. Nope, programmers build new languages daily in their code; it's how you abstract things.

Re: Levels of code in Forth programming (2002)

#18

Post by jwilliams »

Eons ago as an embedded programmer I came to respect Forth. I encountered numerous situations where using Forth led to a much smaller footprint (size in particular) -- Why? For exactly the reasons that Chuck Moore espouses here; you are writing a purpose-built VM from the hardware up.

Even then I don't agree that portability/abstraction isn't important - it's got the potential to be an extremely reductionist position. Instead I'd argue it's incredibly expensive and should be treated as such.

Re: Levels of code in Forth programming (2002)

#19

Post by wwweston »

>I was also researching AI in Forth, implementing ideas from LISP examples and doing expert systems and neural nets and mixing them and building robots. In the software I added a layer for an inference engine for English language descriptions of rule sets and a layer for the rules. I wrote a learning email report and conversation engine AI program and had it running for a few months. My boss could not distinguish it from me. That was my idea of AI, smart enough to do my job for me and get paid at my salary while I took a vacation.

Is the author exaggerating here, or did they actually succeed at writing something that could pass whatever Turing test level his boss could offer?

If it's the latter, what then-current knowledge would they likely have sourced?

Re: Levels of code in Forth programming (2002)

#20

Post by brokenkebab »

wwweston wrote: post #19

>I was also researching AI in Forth, implementing ideas from LISP examples and doing expert systems and neural nets and mixing them and building robots. In the software I added a layer for an inference engine for English language descriptions of rule sets and a layer for the rules. I wrote a learning email report and conversation engine AI program and had it running for a few months. My boss could not distinguish it…

I can't know what the author means, but the thing which is known as chatbots now is very old tech, in fact:

https://en.m.wikipedia.org/wiki/ELIZA (1966)

Post reply on HN