
Chuck Moore, Extreme Programmer - ingve
http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2017-10.html#e2017-10-31T15_44_15.htm
======
wyattk
I want to take a moment to reflect on what a great community HN has. It never
ceases to amaze me.

The link is from the CS department at the University of Northern Iowa in Cedar
Falls, IA. It sounds obscure, but that's my hometown. I grew up a couple
blocks away from it. I sat in on classes there. I even know the author's
family. That's small town Iowa, for ya.

I never thought I would see anything related to that on here. This is truly a
place for all.

~~~
ham_burgers
I work in the fast food industry, don't code, and I'm not even particularly
interested in tech, but spend hours reading the articles and comments here.

~~~
netten
I was a network engineer and would do the same, can't place the exact reason
why, but today i am a python programmer doing network automation. I do think
HN had a major part to play in this change

~~~
Art9681
Network Engineer here too. I learned to code with Python and now do full-time
PowerShell automation at work. It completely changed my career. Best decision
I ever made.

------
teddyh
Quote from
([http://www.ultratechnology.com/1xforth.htm](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._ ”

~~~
derefr
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?)

~~~
throwaway7645
I'm a big Chuck fan, but I get the feeling that he isn't on a short deadline
to build some standard business app like 90% of coders where you almost have a
template...sure it has lots of code you don't need and to paraphrase Rich
Hickey, it isn't simple, but it's really easy (at least in the short run).
He's doing things where he is allotted the time to really understand the
problem and deliver a minimal solution. Listening to his interviews make me
sad as they call up images for how programming could be if we'd gone about it
differently. Small teams writing small and efficient software where you can
grok the entire thing at once.

~~~
mikekchar
Chuck Moore was amazing before I even knew how to code (and was a big
inspiration for me), so I'm not going to even pretend that I know how to do
what he does. However my view of this is that we, as programmers, can't just
look at our jobs from a technical perspective. _Nobody_ is given the time to
make great solutions. The best programmers know how to work so that they can
get the time they need. This is not trivial.

You can't just wander up to management and say, "I need X to make an optimal
solution". They will negotiate you down. That's _their_ job -- to negotiate
into a position of advantage. When you need protection from the chaos that
surrounds the rest of the organisation, you can count your lucky stars when
you have an expert negotiator on your team. But when you go up to that expert
negotiator and say, "I want X", the _first_ thing that's going to go through
their minds is, "I wonder if I can get that cheaper".

So programming _has_ to be a balancing act of constantly delivering
functionality while at the same time ruthlessly refining your vision of how
it's going to work. If you are delivering quickly, regularly and constantly
_nobody will touch you_ for fear of screwing it all up. But knowing how to do
that while still marching inevitably closer to simpler and simpler solutions
is hard. A normal person needs to practice (and get it wrong) a long time
before they get good at it.

Chuck describes a lot of his techniques in his books, but it's fluency that
you need -- and it's fluency _while things are hitting the proverbial fan_
that makes all the difference. You need great judgement to look at what you
need and to prioritise it appropriately. If I deliver X quickly, I'll show
progress. Do I need to show progress now? How fast? Can I refactor Y while I'm
here? Is all of this necessary? And so on and so on.

It's tempting to think, "If only I was given lots of time.", "If only I didn't
have incompetent coworkers", "If only people would listen to my advice", "If
only management could look past tomorrow"... But that's not useful. Anybody
can be a great programmer if we remove every problem before they start. The
measure of your worth is how many of these complicating factors you can deal
with _while still producing great code_. That's what's rare.

------
CarlHansen
Based on the Silicon Valley Forth Interest Group email list, Chuck Moore has
declared that he has retired from social media, he has not retired from Forth.
He is scheduled to speak at Forth Day, November 18, 2017, as he has for years.
[https://svfig.github.io/](https://svfig.github.io/)
[http://www.forth.org/svfig/next.html](http://www.forth.org/svfig/next.html)

------
acjohnson55
> Moore also has a corollary called Do It Yourself!, which encourages you, in
> general, to write your own subroutines rather than import one a canned
> subroutine from a library.

The other side of this coin is NIH Syndrome. I've seen that go wrong in all
sorts of ways.

One of the key skills of being a great engineer in the real world is
exercising good judgment whether to "build or buy".

~~~
logfromblammo
In the real world, anecdotally, my employers have always preferred to buy 160
hours of my time rather than share 480 hours of someone else's time with 1000
other customers.

It may have been because that person is then 1/1000th as responsive to their
specific needs. It also may have been because that person wasn't cleared, and
paranoia requires their code to be vetted before allowing it within breathing
distance of our network. Or it may have been because buying a third-party tool
requires approval of the manager's manager's manager, while rolling your own
is the manager's call.

I have never seen a company that makes it easy to buy a third-party license,
and never a company that makes it easier to use a gratis licensed software
than a paid one. They're all afraid that GPL will infect the code, and it will
dance out of our source control onto the Internet like children following the
Pied Piper.

And on the other side of that coin, I have also seen licensed third-party
software become vastly more trouble than it was worth, especially when it came
time to upgrade it to a newer version. In general, though, if a third-party
tool already does exactly what you need it to do, and you never need it to do
anything else, it is always better to license it, configure it correctly once,
and then never touch it again (aside from security-related patches).

~~~
dllthomas
> I have never seen a company that makes it easy to buy a third-party license,
> and never a company that makes it easier to use a gratis licensed software
> than a paid one.

Meeting anecdote with anecdote, I've never worked at a company that made
paying for licensed software easier than using gratis.

------
orf
> If you have read any of Chuck Moore's work, you know that he is an extreme
> programmer in the literal sense of the word: a unique philosophy that
> embraces small, fast, self-contained programs in a spare language and an
> impressive development environment

I haven't read any of his work, what is impressive about his development
environment?

~~~
DonbunEf7
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/](http://www.greenarraychips.com/)

~~~
andrewla
> 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 authored, just as he designed ColorForth, and just as he
designed, once upon a time, the language known as Forth.

Any of the tasks above seem like it would be a reasonable accomplishment for a
good programmer. Combined, they make me question whether I even qualify as a
developer by this standard, and make me wonder whether I should take a year
off of development and just really learn Forth.

~~~
stefantheard
Your ending summary was exactly my thought process as I read the first
paragraph. I essentially went through the 5 stages of grief as I realized I am
no longer a developer.

~~~
ianai
Round every circle a larger may be enscribed. Don’t be downtrodden but be
inspired.

------
atotic
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. I admired my coworker as an
almost alien intelligence.

I think it really works well for coders spiritually close to hardware.

~~~
Chiba-City
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.

------
sitkack
Charles' extreme minimalism philosophy aligns well with Forth, but it can work
in many compact environments. Scheme and Lua come to mind. It is difficult at
first but powerful and liberating to realize that one has full agency over
their program. With other runtimes, there is no possible way to either
understand the whole thing, or effectively fork it and fix what you want. Not
so with Lua, Forth or a small Scheme.

I _really_ like that Lua doesn't ship much in the standard lib, but what it
does ship can be used to build the world.

~~~
ansible
The _economy_ of Lua's design has impressed me.

You've got just one data structure, the table, and from that you can implement
just about anything else... efficiently.

------
protomyth
Forth was always fun for me because it really was fun to build up a dictionary
of words that solved your problem. It practically forced coming at the problem
from the bottom. I do admit that I liked some aspects of Postscript better
than Forth, but both are experiences.

Thinking Forth is a pretty good starting point and in general a great
programming book [http://thinking-forth.sourceforge.net/](http://thinking-
forth.sourceforge.net/)

~~~
dewster
It's called factoring with subroutines, and Forth hasn't cornered the market
on anything by calling them words.

~~~
protomyth
No, but Forth provided one of the nicest, most immediate, and interactive
environments to explore a problem. Instead of multiple files in a text editor,
you build and test your app live and then dump it all to a text file. I have
rarely had that experience with any other language except Smalltalk. I
understand some Lisp environments act that way, but Forth was available places
Lisp and Smalltalk were not.

~~~
dewster
Developing on the target is just so last century. Now that programmers have
developed the IDE you'll have to pull them from their cold dead hands.

~~~
protomyth
I don't think I've used any IDE (other than Smalltalk) that was vaguely in the
class of using Forth for interactivity and building of programs from the
bottom up.

Whats up with mocking everyone you reply to on this thread?

------
mmel
I found this video of Chuck speaking in 2011 just awe inspiring
[https://www.youtube.com/watch?v=odBjuSCX8jE](https://www.youtube.com/watch?v=odBjuSCX8jE)

~~~
eadmund
I really worry for what we'll lose when he dies and no-one carries on his
work. Reading about his systems is like peering into an alternate universe of
engineers and technicians making the world go 'round.

------
frou_dh
Is Moore okay? His charming homepage
([http://www.colorforth.com/](http://www.colorforth.com/)) has been down for a
while now.

~~~
teddyh
Last working archive on archive.org is here:
[https://web.archive.org/web/20160414102635/http://colorforth...](https://web.archive.org/web/20160414102635/http://colorforth.com/)

------
Nokinside
If our technological civilization collapses and we need to recreate it from
scratch, Chuck Moore could do significant part of that.

~~~
buckminster
Off topic, but we can't. All the readily available sources of energy have been
used. As someone else said, this is literally the last great civilization.
Best not screw it up!

~~~
kbenson
That's a note on whether a future civilization without access to our knowledge
attempted it, no? I imagine some good physics and engineering texts from now
might help a future civilization bootstrap itself technologically, even you
have to slowly and painfully jump a few steps that would be easier with
readily available oil.

------
carapace
Legend has it Chuck Moore had a 3D wire-frame CAD program he used to carry
around as a punch-card deck in his shirt pocket.

~~~
rvense
I've heard he just types it in from memory when he needs it.

~~~
hoosieree
Not from memory: from scratch, every time. Adapted to the problem at hand and
not carrying unnecessary baggage.

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

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

~~~
dewster
I don't think the stack in a traditional languages is the same as stacks in
stack machines and languages. It's a lump of memory that gets allocated to a
thread for stuff, and the allocation is indeed done in LIFO fashion, but I
believe access to individual memory locations in the allocation is random.
Name is the same, LIFO and all, but the mechanism granularity makes it quite
different.

~~~
coliveira
It is true that traditional languages lump local variables and return
information in the same stack. But the difference is only in the way this is
handled by the program. In traditional languages the programmer has no idea
how parameters are passed in the stack and the compiler does everything. In
Forth this is made explicit, but on the other hand there are no formal
parameters to worry about (notice that Forth can use local variables if you
want, it is just not the idiomatic way).

------
Chiba-City
I used to go to the NASA Forth User Group meetings in the early 90's to hang
with compiler and language nerds. Chuck Moore is a genius problem solver. His
Starting Forth is one great example of an introductory language text.

~~~
SonOfLilit
Starting Forth by Leo Brodie is an excellent book, considered one of the best
programming books ever written.

[https://www.forth.com/starting-forth/](https://www.forth.com/starting-forth/)

~~~
Chiba-City
Sorry I recalled the author wrong. I'll leave your correction. Thanks.

------
feelin_googley
The "Do Not Speculate!" idea reminds me of the practice of delivering "the
kitchen sink" when only a small program that does one thing would suffice.

It reminds me of when, e.g., a 1990s-2000s Windows user needed a small program
that does one thing, and in order to get it, the download from Microsoft was
an installer with hundreds of megabytes of unneeded binary files. It was not
possible to download only the single program, which was no more than 1-2MB in
size.

It reminds me of this quote: "The problem with object-oriented languages is
they've got all this implicit environment that they carry around with them.
You wanted a banana but what you got was a gorilla holding the banana and the
entire jungle." \- Joe Armstrong

It reminds me of bloat, of giving users things they do not need. A problem
that continues to this day.

Instead of bloated, complex UEFI, I wish something like
OpenBIOS/OpenFirmware/SmartFirmware/OpenBOOT would be available for today's
hardware. I have played around with fgen on i386 and read some of the history.
They even provided courses on how to write drivers. Besides OLPC, why did this
not catch on?

IMO, Forth is the most elegant and flexible language for initializing
hardware.

~~~
throwaway7645
This is what I like about Rebol & Red...pity Rebol didn't catch on more. The
full Rebol download is a single executable (no real install) and can build
GUIs, and so much more in a very small amount of code.

~~~
hdhzy
Not to mention Red can cross compile for multiple OSes and the parse dialect
that is basically generalized, readable regular expressions.

My personal theory why Rebol/Red didn't succeed in the mainstream is steep
learning curve, it's hard to discover how to do things if you haven't already
done some substantial programming work in it. While built-in help is good you
need to know what you're looking for. (Delphi had better help in this matter,
with examples etc.).

By the way I wonder why Pecan's post is [dead], it doesn't seem to be
violating any rule.

~~~
spinningarrow
> didn’t succeed in the mainstream

Is that true of Red? I was playing with it the other day and it looked really
promising, and I was under the impression that it’s still quite new and hasn’t
reached 1.0 (my point is that it might not be at a stage where we can write it
off).

~~~
hdhzy
> it’s still quite new and hasn’t reached 1.0

According to the main page [0] the project was unveiled 6 years ago. For
comparison Rust (a random example) started 7 years ago [1] but compare results
for "Rust" and "Red/Rebol" on Algolia [2] (sorry no deep links). It's clear
Red is niche.

I'm not writing it off. It's definitely one of most interesting languages and
runtimes but it's super hard to capture people's attention nowadays when you
don't have support of large companies (Go, Rust, .NET).

[0]: [http://www.red-lang.org/search?updated-
max=2011-03-29T15:38:...](http://www.red-lang.org/search?updated-
max=2011-03-29T15:38:00%2B02:00&max-results=7&start=40&by-date=false&m=1)

[1]:
[https://en.m.wikipedia.org/wiki/Rust_(programming_language)](https://en.m.wikipedia.org/wiki/Rust_\(programming_language\))

[2]: [https://hn.algolia.com/](https://hn.algolia.com/)

~~~
spinningarrow
Hmm, you're right. I didn't realise it was 6 years old!

