John Passaniti
JapanIsShinto.com> wrote:> 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?
>
> 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.
True.
> 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.
That's true too. You can build the tools to use the different model in
Forth, but that's an extra step. And there might be nothing in Forth to
encourage the different model.
>> 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.
I have the idea that Forth is also good for allowing quick rewriting and
testing. So if you see a factor that doesn't work quite the way you've
been working, you can create the factor and relatively quickly rewrite
your old code to use it. You might consider that just more low-level
factoring, though.
> 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.
Tell us more about that? Has the Forth community been slow to use the
language-independent high-level factoring? Something new that's
available to us?
> 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.
OK.
>> 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.
That's incidental to my point. increasingly projects are getting
described as large projects, for whatever reason. However, as both you
and Elizabeth have pointed out, this often amounts to a collection of
mostly-independent smaller projects that are collectively called a large
project. When it's small projects that ahare nothing but different sides
of a specified interface, there's more chance for Forth to be used for
one of them.
> 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.
Surely there are cultural factors etc that have some effect. How useful
is it to try to dissect those here? Things work better when the cultural
stuff works, but what can we say about how to make it work? Probably not
much.
Here's a story from around the mid-1990's. On comp.lang.forth there was
a claim that -- in those days -- Forth could often get results
considerably faster and cheaper than other languages, that in fact it
could be 1/4 the cost. The claim was that some unnamed Forth shops would
attempt to get government contracts, and they would estimate their
programming costs at 1/4 of the competition. That is, they believed
their own claims. But these bids were never accepted. And it turned out
that the US government consistently threw out bids that were too low as
unserious. They did *not* believe it. One of the steps necessary to get
the contracts was to raise the bid closer to industry norms.
This does not insult US government management. They could have various
legitimate reasons for it. For example, they might sometimes get low
bids that result in predictable cost overruns. It does indicate a
reasonable response.
> 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.
My thought was that increasingly, funded projects are large. For
whatever reason. I was thinking that could make a difference. But it
doesn't have to make much difference. Maybe it just isn't important.
> 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.
Finding solutions. Outside Forth, about Forth's place in the world.
About interacting with management and customers and such. That's the
point, right? So, suppose someone were to find a newsgroup that real
honest-to-goodness software managers attend, and invite them to
crosspost here describing their needs.... Chances are they don't think a
whole lot about computer languages. That's just one of the early choices
they make, and once the choice is made it's hard to change it. And for
any project (or part of a project) there might be several languages that
are widely regarded as adequate, and some that are considered inadequate
for that particular sort of need, and they choose one. But if they say
what their needs are, it might suggest a software product that could
help to fill those needs, and that product could be written in Forth.
And a sense of what they think they need would help people who want to
work for them.
Would that be a good thing, or would we automatically argue with them
about why they should use Forth for everything, and why they're wrong
about whatever they happen to believe, etc?
> 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.
Sure. I never meant to say that Forth is the only thing that can be
useful. Here's my claim: Forth's promise is extreme simplicity at all
levels. That's where Forth is headed. To the extent that it delivers,
that's what it delivers. There's value in that though it isn't the only
value that's worth having. "As simple as possible but no simpler."
Am I wrong? Is there some other central value here?
