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

31–40 of 53 posts

Re: Levels of code in Forth programming (2002)

#31

Post by pointfree »

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.

> Portability is not important. Portability is not possible. Real applications are closely coupled to hardware. Change the platform and all the code changes. If it didn't, you wouldn't have changed the platform.

Re: Levels of code in Forth programming (2002)

#32

Post by mr_crankypants »

rauhl wrote: post #28
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.

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,…

I don't know what Moore would say. Personally, I've retreated to the back end - used to be full stack, but I'm just sick to death of how overcomplicated front-end work has become.

I'm inclined to say that, e.g., the modern browser is a cautionary tale that complements the Chuck Moore approach to things: By forever piling thing on top of thing in an evolutionary way, you end up with a system that ultimately feels more and more cobbled together, and less and less like it ever had any sort of an intelligent designer. Perhaps the lesson is that it can be worthwhile to occasionally stop, take a real look at what things you really do need, aggressively discard the ones you don't, and properly re-engineer and re-build the system.

Obviously there are issues of interoperating with the rest of the world to consider there, and Moore has made a career of scrupulously avoiding such encumbrances. But a nerd can dream.

Re: Levels of code in Forth programming (2002)

#33

Post by dTal »

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…

It is entirely and completely about high level vs low level.

"High level" means details abstracted away and solved so you don't have to think about them. Our CPUs understand only the most primitive of instructions; the purpose of all software is to climb the ladder of abstraction, from a multiplication routine abstracting over repeated addition, to "Alexa, set an alarm for 8 AM." To write things yourself is the very essence of descending to a lower level.

Abstraction comes at the price of loss of fidelity, yes - Alexa might not ask you to specify exactly what form your alarm will take - but the benefits are a vastly increased power/effort ratio. It's worth it, because most of the time you don't care exactly how a task is done - you just care that it IS done. And - mostly - your needs are not that special.

Frankly, sharing information on how to do things so that others can build upon them is the only reason we have technology at all. Perhaps you've read "I, Pencil"? With a lifetime of effort and study, you would struggle to create a single pencil drawing from "scratch". Chuck Moore's supposedly astonishing productivity notwithstanding, I notice that all of the software I actually use is a heavily layered tower of abstraction (and, curiously, none of it is written by Chuck Moore). It appears that by and large the choice is between layered, multi-author code - and no code at all.

https://fee.org/resources/i-pencil/

Re: Levels of code in Forth programming (2002)

#34

Post by pointfree »

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

If it were a complex application it wouldn't be very forthy would it? Factor the problem instead of trying to factor a preconceived solution.

> 2. What is “sourceless programming”? Where is a good place to learn more about it?

Sourceless programming was used in Okad a vlsi design tool written by Chuck Moore.

http://www.ultratechnology.com/mofe16.htm

Brad Nelson also experimented with sourceless forth:

https://docs.google.com/presentation/d/1wL2eqf7eHGEybsK0C4MU...

https://github.com/flagxor/bicol

Re: Levels of code in Forth programming (2002)

#35

Post by couchand »

dTal wrote: post #33
astrobe_ wrote: post #23

Earlier quoted context omitted.

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…

It is entirely and completely about high level vs low level. "High level" means details abstracted away and solved so you don't have to think about them. Our CPUs understand only the most primitive of instructions; the purpose of all software is to climb the ladder of abstraction, from a multiplication routine abstracting over repeated addition, to "Alexa, set an alarm for 8 AM." To write things yourself is the very…

There's a significant practical difference between importing the complexity at build time versus as part of the running application. Building on top of a compiler is not the same thing as importing external code.

Re: Levels of code in Forth programming (2002)

#36

Post by nickpsecurity »

jwilliams wrote: post #18

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

Using a cross-platform framework isn't incredibly expensive in time or performance cost. It's done by one-person projects and large businesses alike. There's issues but that's way overstating it.

Then, there were 4GL's like Lansa and Windev that made it easier to do than creating non-portable, native applications. Those weren't used for performance-sensitive code, though. Mostly business apps.

Re: Levels of code in Forth programming (2002)

#37

Post by rcombine »

astrobe_ wrote: post #24
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-L…

It kinda sounds to me like Forth wants to be used in the context of embedded programming, then.

Re: Levels of code in Forth programming (2002)

#38

Post by astrobe_ »

dTal wrote: post #33
astrobe_ wrote: post #23

Earlier quoted context omitted.

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…

It is entirely and completely about high level vs low level. "High level" means details abstracted away and solved so you don't have to think about them. Our CPUs understand only the most primitive of instructions; the purpose of all software is to climb the ladder of abstraction, from a multiplication routine abstracting over repeated addition, to "Alexa, set an alarm for 8 AM." To write things yourself is the very…

> Chuck Moore's supposedly astonishing productivity notwithstanding, I notice that all of the software I actually use is a heavily layered tower of abstraction (and, curiously, none of it is written by Chuck Moore)

Perhaps you never saw the images from the Philae space probe? Because that's an RTX2010 that powers it, one of Chuck Moore's designs.

Maybe you don't use Moore's software directly, but you never know when it has been used for you [1].

[1] https://wiki.forth-ev.de/doku.php/events:ef2018:forth-in-tha...

Re: Levels of code in Forth programming (2002)

#39

Post by astrobe_ »

rcombine wrote: post #37
astrobe_ wrote: post #24

Earlier quoted context omitted.

> 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-L…

It kinda sounds to me like Forth wants to be used in the context of embedded programming, then.

Not only. Checkout Forth Inc. last year's projects [1]. In one of them, Forth is used everywhere from micro-controllers to the monitoring PCs.

[1] https://wiki.forth-ev.de/doku.php/events:ef2018:forth-in-tha...

Re: Levels of code in Forth programming (2002)

#40

Post by jacquesm »

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.

I don't see the semantic difference between calling a subroutine or using a Forth word.

65 emit

vs

putchar(65);

vs

(print 'A')

It's all the same to me.

Post reply on HN