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

Chuck Moore, Extreme Programmer

cs.uni.edu

Post reply on HN
Print view View original

31–40 of 186 posts

Re: Chuck Moore, Extreme Programmer

#31

Post by Chiba-City »

atotic wrote: post #28

I've worked with another Forth disciple in the late 80s. He was on a PC, and thought that my Mac GUI was neat. So he wrote a portable GUI framework from scratch in Forth that had dialogs, buttons, pull down menus, text inputs, graphics, mini Mac clone. It was magic. I think it was way under 100K. After that, I really wanted to become a Forth wizard. I tried, but it never clicked, my code was very clumsy, write only.…

FWIW, I wrote a graphing menuing system with primitive scalable fonts (for Arabic) in Turbo Pascal in '89 on US taxpayer dimes for live variable twiddling graphing of demographic simulations. It was all roll our own back then on 512K PC's. I implemented a Common Lisp compiler packaged in a DLL for Windows before the net took off. Some kind of "hardware and syscalls up" exercise should be part of more CS programs. It is a great experience to engineer truly reusable (and reused) code before the mosh pits of corporate labors. Good times make for useful memories.

Re: Chuck Moore, Extreme Programmer

#32

Post by derefr »

teddyh wrote: post #7

Quote from ( http://www.ultratechnology.com/1xforth.htm ): “ I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. ”

I'm not surprised that the general principle that helps Moore reduce his code size eludes him. Authoring something blinds you to your own style—both to your mistakes, and to your brilliances. It's why prose writers can't be their own editors: you need someone who wasn't in your head during the writing process to actually be able to see what's ended up on the page, rather than just seeing reminders that immerse you back into your own implicit context.

I would expect that, if you took five of these rewrite projects of Moore's, and compare-and-contrasted their source with the source of the originals, principles would leap out at you.

(Why don't we programmers, as a culture, read code this way? It really seems like the only way to deduce novel facts about programming for yourself. Is it just that a rewrite where both the old and new codebases are shared-source is rare?)

Re: Chuck Moore, Extreme Programmer

#33

Post by jacquesm »

pmoriarty wrote: post #18
andrewla wrote: post #14

Earlier quoted context omitted.

> from scratch This is even understating it -- it's not like he used existing software to lay out the chip, and then ran tests using PSPICE to verify the functionality. He wrote his own chip design software and analog simulator, and designed the chip in his own environment, and created the CPU, the GA144: a working 144-core processor designed to run "ArrayForth", a parallel version of Forth that he designed and autho…

I've heard of the wonders of Forth for many years -- about how it was just as good at metaprogramming as Lisp, how it was very powerful and yet extremely light-weight, about how you could run it on bare metal, and write your own OS and utilities in a fraction of the time it would take in other, more well-established languages, and so on. I got really excited about it, and when I finally started learning it, I had ver…

Forth is no different from other languages in that you can write good code and bad code in it. The 'Forth way' is not always intuitive and in that it fails from the purpose of being a language friendly to newcomers, it's a bit like being dumped on someone else's farm without power, water or sewage and a pile of tools and raw materials for you to use.

Taking a step down like that when coming from a modern environment is really hard. But when looked at from the other direction, as a step up from assembler and a way to become much more productive while at the same time reducing the amount of space bugs have to hide in it makes a lot more sense.

But in the present day it's no longer very useful unless you are doing something embedded or if you want to entertain yourself with an eternal match of code golf.

Re: Chuck Moore, Extreme Programmer

#35

Post by Cyph0n »

trhway wrote: post #29
Cyph0n wrote: post #23

Earlier quoted context omitted.

Before I put on my cynical hat, I'd like to say that it's pretty impressive stuff for a one-man shop in the 90s. ----- So it seems like OKAD is basically a layout editor, simulator, DRC checker, and GDSII compiler. The simulator uses a very simplistic transistor model that would only work at very old process nodes (>350nm?) due to the low impact of parsitics and leakage. Not even a moderately complex digital chip fro…

>Given the absence of "higher-level" constructs, the resulting OS will never be as complex as something like an NT kernel i wonder whether you've worked with Forth - in my view of Forth (spent 1987-89 mostly in Forth running on 8088 clone based terminal of USSR clone of IBM 360, so Forth is my second language after mandatory Pascal and the first true "computer" love really) what you said is a huge advantage and natur…

That was an analogy attempting to explain what OKAD does. The kernel represents the circuit being designed, while the assembler represents the OKAD toolchain.

The goal of the analogy was to demonstrate that OKAD is not suitable for designing large circuits, just like using assembly to write a modern kernel is not practical.

Re: Chuck Moore, Extreme Programmer

#36

Post by derefr »

andrewla wrote: post #14
DonbunEf7 wrote: post #6

Earlier quoted context omitted.

He designed CPUs from scratch using a bare-bones minimal Forth (ColorForth) as his preferred way of writing code. The resulting chipset is utterly fascinating: http://www.greenarraychips.com/

> from scratch This is even understating it -- it's not like he used existing software to lay out the chip, and then ran tests using PSPICE to verify the functionality. He wrote his own chip design software and analog simulator, and designed the chip in his own environment, and created the CPU, the GA144: a working 144-core processor designed to run "ArrayForth", a parallel version of Forth that he designed and autho…

I feel like a desire to program in Forth is more the consequence of being a crazy-in-the-good-way programmer, rather than something that aids in becoming that sort of programmer.

Moore, from my perspective, decided to bootstrap a computing architecture from as primitive and restrictive of a starting place as he could come up with. Forth makes sense as a language if you imagine yourself as a time-traveller stranded in the 1970s (or even earlier!), trying to get a "foothold" into your futuristic programming environment using the wimpy computers of the era, so that you could design and build the hardware on which would run the software that you actually wanted to write. (Which would, in turn, fix your time machine or whatever.)

Learning Forth isn't really a step on that path. Rather, designing your own minimalistic language under the constraint that it'd have to 1. run on the wimpiest hardware you can imagine, but 2. allow you to be productive in the rest of the bootstrapping process — that's the first step on the path to being Chuck Moore.

Re: Chuck Moore, Extreme Programmer

#37

Post by dewster »

THE central problem with pure stack machines and stack languages:

The programmer knows in their heart that moves, swaps, dupes, drops, etc. - any stack manipulation that doesn't involve a functional change to the data itself - is an inefficiency to be minimized, but this effort isn't in any way related to the problem at hand (writing a program to do something) so it's unwelcome mental overhead.

I like puzzles as much as the next person, but not so much when they seriously impede the solving of a bigger more serious puzzle, nor when the sub puzzle solving is an exercise in the minimization of something bad rather than the elimination of it.

Re: Chuck Moore, Extreme Programmer

#38

Post by Cyph0n »

jacquesm wrote: post #30
Cyph0n wrote: post #27

Earlier quoted context omitted.

TL;DR Not really as impressive as it was made out to be.

You're entirely missing the point made by Chuck Moore and by extension probably don't understand why his way of looking at programming and the Forth language in particular are a big deal even this long after their invention. This kind of minimalism and stripping things down to their essence is a powerful tool to allow you to focus on what matters rather than at all those things that don't really matter. If you don't…

> This kind of minimalism and stripping things down to their essence is a powerful tool to allow you to focus on what matters rather than at all those things that don't really matter. If you don't actually need 4 GHz chips and billions of transistors to get the job done then why would you?

I agree entirely. I just wanted to point out that it's not accurate to equate what Chuck designed (i.e., OKAD) to a modern EDA toolchain and technology node.

If it works for him, then great!

Re: Chuck Moore, Extreme Programmer

#40

Post by coliveira »

dewster wrote: post #37

THE central problem with pure stack machines and stack languages: The programmer knows in their heart that moves, swaps, dupes, drops, etc. - any stack manipulation that doesn't involve a functional change to the data itself - is an inefficiency to be minimized, but this effort isn't in any way related to the problem at hand (writing a program to do something) so it's unwelcome mental overhead. I like puzzles as much…

Traditional languages are pushing and dropping data from the stack every time a function or procedure is called, they just give it another name: parameter passing. Making it explicit, at least Forth tries to reduce the need of copying things from the stack to local variables.
Post reply on HN