Live data from Hacker News

Levels of code in Forth programming (2002)

ultratechnology.com

51–53 of 53 posts

Re: Levels of code in Forth programming (2002)

#51
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…

Software today is developed by teams, not individuals. Systems custom-fit to an individual programmer are next to useless. You need libraries of common code in order to collaborate effectively without duplicating effort.

See also: Emacs, the ultimate customizer's editor, easily shapeable to your particular needs -- and currently losing badly to Visual Studio Code which is only readily customized with configuration options and third-party packages. When you need to pair or mob, having a common toolset and vocabulary beats having a special-snowflake environment.

Re: Levels of code in Forth programming (2002)

#52
post #46

Earlier quoted context omitted.

“I agree with you, but I wonder what his answer to stuff like GUIs would be.” Couldn’t say exactly, but it’d probably look something like this: https://en.wikipedia.org/wiki/Display_PostScript :)

As far as I recall, Display PostScript was display only - what you really want is NeWS which used PostScript for display and for building applications: https://en.wikipedia.org/wiki/NeWS

Potayto, pohtato… it’s all Polish to me. ;)

Re: Levels of code in Forth programming (2002)

#53

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

I wasn't being specific enough - I meant expensive in the most general sense. e.g. An abstraction is a cost not only in terms of (potential) performance, but developer headspace, etc, etc.

The right number of abstractions is very powerful. Too many any you'll sink under the weight of them.

Post reply on HN