Re: The Promise of Forth

Jonah Thomas wrote:
You next move into the false dichotomy of paying people to think or
pay people to crank out solutions.

I didn't mean that to be a false dichotomy. The basic ideas that claim
Forth has an advantage, claim that Forth has an advantage for
programmers who think. We haven't claimed an advantage on the other
side. Should we?

The base premise is faulty. And insulting.

All non-trivial programming is thinking. It's thinking about how to use the power of the language to express a solution. Thinking in Forth means viewing problems in terms of explicit manipulations of state and (ideally) defining linguistic constructs that map well to the problem domain. But that's not the only way to think about programming. Equally valid is for programmers to think in terms of implicit application of functions to data, avoiding state. Another equally valid way to think is to model the world as bundles of state and behavior.

Saying that "Forth has an advantage for programmers who think" only considers a Forth-centric way of thinking. It ignores that there is a wealth of programming paradigms that are expressed in terms of languages, libraries, and techniques. And sometimes, a more clear, simple, and elegant solution can be made by choosing a different model.

So at best, if you're going to go with this premise, you should be specific about what you mean by "thinking." You mean that the programmer is concerned with explicit manipulation of program flow and state. You mean that (typically) that the programmer spends their time building up the necessary infrastructure instead of focusing on reusable libraries. You mean that (typically) programs have a low level of abstraction and because they are optimized for the solution, (typically) a low level of reuse.

Forth is good for factoring, and factoring is good for simplicity, and
simplicity is good for debugging speed, and correctness, and easier
maintenance. Forth is also good for being interactive which is good for
debugging speed and development speed and maintenance. But there are
lots of other interactive languages now. So I stress the factoring.
Factoring is good for people who think. It does not give Forth an
advantage for employers/customers who want people to quickly crank out
routine solutions. This is a limitation for Forth. I don't see what to
do about it beyond try to be good at what Forth is good at.

Forth is only good for a specific kind of low-level factoring. That is, Forth makes it relatively easy to extract from a word a sequence of words and give it a name. There are various mutations of this (colon definitions, DOES> definitions, vectored execution, macros) and it's done for different reasons (eliminating common terms, defining new control structures, crude polymorphism, etc.). But that's pretty much it.

There are other kinds of factoring. There is factoring towards larger patterns that have proven themselves. While the Forth community was spending time endlessly reimplementing Forth and arguing over how to define string literals, the rest of the world was busy rising up above the low-level kind of factoring that Forth allows and looking for larger, more substantial kinds of factoring. And along the way, they noticed something-- that this kind of higher-level factoring is (for the most part) language independent.

So at best, if you're going with this premise, you should be specific about what you mean by "factoring." You mean that because Forth isn't an expression-based language, it allows fine-grained extraction of sequences of words within definitions. That's it.

I love how nearly every discussion in comp.lang.forth that discusses project management usually degenerates into a series of insults about management.

This stereotype is not limited to Forth. See for example Kelly Johnson's
Rule #14.

http://en.wikipedia.org/wiki/Kelly_Johnson#Kelly_Johnson.27s_14_Rules_of_Management
There's a time-honored tradition that part of managers' compensation is
related to the number of people they manage. That wasn't invented on
clf. Of course it isn't true everywhere, as Kelly Johnson and others
have created counterexamples.

Please provide evidence that this is still common today. Does it exist? Sure. Is it common enough to even bring it up? I have little evidence for it. So prove it.

It was a large project because it was... large. It combined the
skills, interests, and insights that would be extremely unlikely to
find any one person had.

Sure. And they chose that 30-person project instead of two 15-person
projects that would predictably be faster and cheaper to complete
because.... because it worked for them to.

You're amazingly fearless in discussing projects you know nothing about. The project in question was fluidly factored into N-person subprojects over the project's lifetime. That is the norm, in at least the various industries I've worked in.

> They had a reasonable belief
that this one could be a success, that's vital. Was it the most
plausibly profitable use of those resources? Maybe. Maybe the corporate
climate had something to do with it too. Some people's career trajectory
might have benefitted more from this project than a smaller one. Etc.
I'm in no position to say that's true -- I don't know anything about
your project except what you say about it. But is it at all plausible
that nontechnical factors might have had some influence on which viable
project was undertaken?

Not specific to what you're writing here, but the larger tone of what you write seems to have a whole lot of assumptions about people's motivations in how they approach a project.

So here's a fun challenge for you:

I know that there are a set of axioms that many people in comp.lang.forth seem to accept without question. One meta-axiom is the nature and motivation behind the business decisions used by software managers. Stated informally, this meta-axiom is that Dilbert isn't a comic strip, but a shocking documentary in comic strip form. This feeds into the mythology of Forth-- that Forth is just "too good" and that a pervasive culture of waste drives everything away from Forth. Gosh, if we only sprinkled magic Forth dust on everything, every project would be done on time, on budget, and would have zero bugs. Oh, and it would make everyone's teeth whiter, disinfect bathroom surfaces, and make your car get more miles per gallon.

But let's say that instead of accepting all these as axioms, you instead took a more curious stance. Instead of assuming people having nefarious motivations, you think instead about people just trying to do their jobs competently, with practical decisions they think are best. Instead of viewing decisions in terms of some underlying "career trajectory," you realize that most people have an honest desire to do good work.

So my challenge is this: Rework your statements without predicating them on an assumption of nefarious motivation and without the insults. Whenever you think "gosh, large projects are only large because some manager wants to get paid more," question where that assumption comes from. Find a source. Demand proof.

Yes, I know. If everyone in comp.lang.forth started to ask the basic kinds of questions I repeatedly ask, this might be a newsgroup more about finding solutions than reiterating sour grapes. But I can dream.

I don't claim any tremendous expertise about such things. But I think
you're agreeing with my conclusions even though you disapprove of some
of the stereotypes I base those conclusions on. We can expect increasing
project size and Forth will mostly not be the dominant language for
these projects. For Forth to have a role in any of them, we need
relatively small niches that Forth can fill inside the large projects.
Which you have been doing. You prove it's possible.

It's possible when people stop thinking in terms of language choice being a zero-sum game. It's often cited that part of what Charles Moore was doing with Forth was getting rid of layers and getting rid of a multitude of languages. And in some contexts, that's a very good thing.

But it's completely wrong in other contexts. Not every language out there is just another variation of Algol. Forth is just one model for computation-- imperative, procedural. It's not the only model. Charles Moore may have successfully replaced imperative procedural languages that didn't need to exist. But he didn't replace the variety of programming paradigms that exist.
.

Relevant Pages

  • Re: I get it
    ... > the important upper-medium level management in the company and gives ... There's a brain-freeze in our industry whereby people are locking themselves ... language> ensures there's a pool of employable people available to draw ... it's a programmable programming language. ...
    (comp.lang.lisp)
  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (comp.lang.asm.x86)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (alt.lang.asm)
  • Re: LSP and subtype
    ... What is the class of problems solvable using UML? ... the language of physics cannot describe. ... whatever paradigm equivalent to 2GL/3GL ... there is still a great need for reuse and generic programming. ...
    (comp.object)
Loading