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

21–30 of 53 posts

Re: Levels of code in Forth programming (2002)

#21

Post by dTal »

mr_crankypants wrote: post #9
haolez wrote: post #7

Earlier quoted context omitted.

I know. It’s a feature, but it makes it harder to share code (and Chuck Moore believes that sharing code is rarely worth it). Maybe he is right. His productivity is unbelievable :)

The more time I spend dealing with blowback from excess complexity being imported in the form of 3rd-party libraries that offer complicated solutions to simple problems, the more I think that Chuck Moore was very, very right on that point.

Ehh... the reductio of this argument is writing everything in assembler (libc? giant hunk of third party code right there). I surmise that, by comparison, the blowback you encountered was relatively minor.

Re: Levels of code in Forth programming (2002)

#22

Post by kreetx »

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.

Are there any good but not too large codebases where someone new to Forth could get a feel of how it's done? I'm intrigued by building DSLs, but a university course a long time ago left a totally different impression.

Re: Levels of code in Forth programming (2002)

#23

Post by astrobe_ »

dTal wrote: post #21
mr_crankypants wrote: post #9

Earlier quoted context omitted.

The more time I spend dealing with blowback from excess complexity being imported in the form of 3rd-party libraries that offer complicated solutions to simple problems, the more I think that Chuck Moore was very, very right on that point.

Ehh... the reductio of this argument is writing everything in assembler (libc? giant hunk of third party code right there). I surmise that, by comparison, the blowback you encountered was relatively minor.

No, not writing everything in assembler, this isn't about high or low level. It's about writing things yourself for what you actually need.

Because most of the complexity comes from code (esp. libraries and drivers) trying to solve a larger problem than you actually have.

That's the same reason why, when you follow that logic, you eventually write your own Forth. Not because it fun. Not because you want to learn about Forth or compiler. But because my Forth solves my problems the way I see fit, her Forth solves problems the way she wants, and your Forth is going to solve the way you want.

Re: Levels of code in Forth programming (2002)

#24

Post by astrobe_ »

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…

> 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.

People usually insist that software should be modular, so that you don't have to have millions of lines of code in your head when making a local change. That's what drove the procedural evolution and later the OOP evolution.

So if you're a good boy/girl/etc. you write your million-LOCs PC application as modules that are manageable for (ideally) a single person. Then you need an extra programmer to glue the modules together.

> 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.

Where does Forth prohibit peer reviews and pair programming? If you have a bus factor of 1, it is because you don't want to pay the price of increasing it. It has nothing to do with Forth; plenty of projects in super-high hyper-readable projects have a bus factor of 1.

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

Not really. It's easier to copy/paste/hack Forth code. The code is more compact for various reasons: point-free style makes it less verbose, you tend to factor more intensively and you code exactly what you need.

> 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.

No, that's the other way. When you code e.g. for a little-endian, two's complement CPU then you don't have to worry about big-endian and sign magnitude. You are actually also optimizing programmer's cycles too.

Being tightly coupled to the machine is what embedded programming really is about. Embedded programming is often about writing esoteric values at occult addresses in order to bang out bits on an SPI bus. Running a Python program on Debian on a rPI is not really embedded programming.

Re: Levels of code in Forth programming (2002)

#25

Post by ianamartin »

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…

He’s throwing shade on his former boss

Re: Levels of code in Forth programming (2002)

#26

Post by astrobe_ »

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.

It's the usually game of MPUs becoming cheaper or more stuffed for the same price because the demand allows to manufacture bigger batches, and the demand is to allow more portability by the means of more stuffed MPUs that allow more abstractions...

But it's a miniature of the same tragedy as Node.js applications that consume ten times the resources needed just because it allows people to do more with more... In a logarithmic way.

Re: Levels of code in Forth programming (2002)

#27

Post by markus_zhang »

astrobe_ wrote: post #23
dTal wrote: post #21

Earlier quoted context omitted.

Ehh... the reductio of this argument is writing everything in assembler (libc? giant hunk of third party code right there). I surmise that, by comparison, the blowback you encountered was relatively minor.

No, not writing everything in assembler, this isn't about high or low level. It's about writing things yourself for what you actually need. Because most of the complexity comes from code (esp. libraries and drivers) trying to solve a larger problem than you actually have. That's the same reason why, when you follow that logic, you eventually write your own Forth. Not because it fun. Not because you want to learn abou…

at least we can get rid of the bloated web apps once everyone begins to do so...but would it be possible if libaries are written in a way that it's easy to just integrate just a portion into existing code?

Re: Levels of code in Forth programming (2002)

#28

Post by rauhl »

mr_crankypants wrote: post #9
haolez wrote: post #7

Earlier quoted context omitted.

I know. It’s a feature, but it makes it harder to share code (and Chuck Moore believes that sharing code is rarely worth it). Maybe he is right. His productivity is unbelievable :)

The more time I spend dealing with blowback from excess complexity being imported in the form of 3rd-party libraries that offer complicated solutions to simple problems, the more I think that Chuck Moore was very, very right on that point.

I agree with you, but I wonder what his answer to stuff like GUIs would be. There’s a tremendous amount of complexity and domain knowledge in stuff like drawing fonts, and in cryptography, and so forth — and very very few of us have the time to become competent in even one of those, let alone all of them. Then consider the amount of work necessary to have a modern browser: text parsing of not one but three languages, language interpretation, more graphics, more cryptography.

It would be awesome to get back to first principles, but modern systems try to do so much that I wonder how practical it would be to reinvent them — and I would how practical it is to say, ‘well, don’t do that then.’

Re: Levels of code in Forth programming (2002)

#29

Post by pointfree »

kreetx wrote: post #22
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.

Are there any good but not too large codebases where someone new to Forth could get a feel of how it's done? I'm intrigued by building DSLs, but a university course a long time ago left a totally different impression.

"Over the Shoulder 1 - Text Preprocessing in Forth" https://www.youtube.com/watch?v=mvrE2ZGe-rs - Sam Falvo demonstrates writing a blog engine in Forth.

Re: Levels of code in Forth programming (2002)

#30

Post by snazz »

bcherny wrote: post #15
madhadron wrote: post #13

Earlier quoted context omitted.

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.

Chuck Moore’s software is somewhat famous for reducing the complexity of both the software itself as well as the requirements. In developing a web browser, he would probably eliminate all of JavaScript, the user interface, and most of CSS, and leave it to run only on a chip he designed for the purpose. His ideology is super cool, but isn’t what is expected of software like this.

For instance, OKAD (chip design and simulation CAD package) is 500 lines of colorForth. Although it includes all sorts of fancy tools, he also applied his ruthless minimalism to the requirements.

Post reply on HN