Jonah Thomas wrote:
> John Doty
whispertel.LoseTheH.net> wrote:>> Jonah Thomas wrote:
>>> John Doty
whispertel.LoseTheH.net> wrote:>
>>>>> Your language reflects your ideas. When the language contains
>>>>> logical contraditions, it's sloppy.
>>>> Yes, but that can simply reflect the difficulty with language.
>>>> Einstein insisted that his ideas were visual, not linguistic.
>>> Language> has its limits.
>>>
>>> Sure. And when your language includes internal contradictions, that
>>> displays a difficulty with language that perhaps can be corrected.
>>> That's what logic is for.
>> There is no support in history for this view: it is merely a
>> traditional faith of our culture. Logic has a long history of failure
>> when applied incautiously to the real world.
>
> Of course logic can be mis-used. So can anything else.
But the True Believers in logic do not understand this. Real logicians
do, of course. Mathematician Reuben Hersh asserts (correctly, I believe)
that mathematics and logic find necessary properties of imaginary
objects. That's only useful in the real world to the (always imperfect)
extent that those imaginary objects correspond to real ones.
What error in logic or its use did Berkeley make in his logical
demolition of calculus? I know of none. Yet calculus, practiced in the
way Berkeley proved was logically wrong, is used successfully to this
day. I've never seen an engineer actually use either the ε-δ method or
nonstandard analysis. Your life depends on the results of the illogical
Newton-Leibniz calculus every day.
> You sure do
> pick-and-choose about what you believe.
It might seem that way if to you "truth" is a concept that applies to
the imaginary objects of logic and mathematics. But I'm interested in
practical, real-world truth.
> Illogic is also easy to mis-use.
The discipline is testing against reality. You compare your hypotheses
against experiment, observation, history, anything and everything you have.
The genius of the scientific method is that the reasoning behind the
hypothesis does not matter: it can be superstition (Kepler), flawed
mathematics (Newton), or simply a guess.
>
>>>>> Usually what has happened is that you've
>>>>> given the same names to two different things,
>>>> Are there different things? Language insists on dividing continua.
>>> If you have two different tests for soil pH, and one test tells you
>>> your soil sample is pH 4.6 while the other tells you it's pH 10.5,
>>> you have a problem. One or the other or both of your tests are not
>>> accurately measuring pH but measuring something else. If you call
>>> the result of both tests pH then you wind up with "The pH of this
>>> soil sample is 4.6 and 10.5".
>> But go for the hard case: what happens when they're close, but not
>> identical? The difficulty of dealing with this logically is at the
>> center of Berkeley's critique of calculus.
>
> When they're different enough that it causes problems, then you should
> distingush between them.
That's not a logical statement. It requires judgment.
> Of course no two things are identical so in the
> extreme case you'd completely avoid generalizing. But we're finite
> beings and we benefit by lumping things together to some extent.
Lumping the "truth" that pertains to imaginary objects with the "truth"
that works in the real world may indeed be part of our muddle here.
>
>>>>> and you use them as if
>>>>> they were the same thing. That's a clue to how to refine your
>>>>> language.
>>>> It's an infinitely long road.
>>> As is the rest of learning. But when you find contradictions in your
>>> language, that's a good indication about the first steps. Fix the
>>> mistakes in your descriptions and you won't confuse yourself as
>>> much.
>> How do you identify the mistakes? Logic is a very poor guide: it tends
>>
>> to force *internal* consistency on ideas at the expense of
>> disconnecting them from the real world.
>
> If you *lack* internal consistency then you get troubles from that.
Why? What if internal inconsistency does not cause failure of real world
tests?
> Ideally you want to get internal consistency and also have it match up
> to the external world. You gain nothing by leaving the internal
> contradictions in. That doesn't at all help you link up to reality.
Ah, but often it does, because removing contradictions breaks the link
with reality. Happens fairly frequently in physics.
>
>>> I've noticed when you don't like an idea you demand that it give
>>> perfect results.
>>> But when you do like an idea you only require it be a step in
>>> the right direction. If you have two different pH tests that are
>>> mostly comparable, no problem. When they measure two different
>>> things it might turn out that both tests have practical value. But
>>> it only adds to the confusion to give them the same name.
>
>>>>> You have done this "Either it's one or the other" in several
>>>>> contexts now. You consider the existing conventional wisdom and
>>>>> you consider one new idea, and you talk as if one or the other
>>>>> them must be right. This is unscientific. If you show that the
>>> CW is>> wrong, it does not mean that any particular alternative must
>>>>> right.
>
>
>
>>> Of course, if one
>>> of them has no particular following then you don't win much by
>>> showing it's wrong. And if you show the CW is wrong, people are
>>> likely to be slow to notice.
>> Not in physics. Overturning the conventional wisdom with a clean,
>> reproducible experiment (e.g. Muller and Bednorz, high temperature
>> superconductivity) is the fast track to the Nobel.
>
> Sure, if you have the prestige to get noticed. Easier when the guys who
> got the Nobel prize for the previous wrong interpretation were from an
> institution that your worldclass institution is in direct competition
> with.
Muller and Bednorz were very low profile until they made their discovery.
Another example that *would have* won the Nobel is cold fusion. The guys
who came up with that weren't even physicists, but there was
*tremendous* interest in it at places like MIT (I was there). Of course
it dissipated when the results could not be reproduced, and as more
details came out showing the original experiments were very sloppily
designed and executed.
>
>>> You could have made a mistake. People figure you
>>> probably did, when you get results that don't fit their
>>> expectations.
>>>
>>> It's utterly unscientific to claim that falsifying one hypothesis
>>> shows that another is correct.
>> A hypothesis that stands up to testing is better than one that
>> doesn't.
>
> Sure. At any given time we have all the hypotheses that stand up to the
> testing so far.
>
>>>>> They could easily both be wrong.
>>>> Happens all the time. But what can you do except look for a better
>>>> one?
>>> Exactly. Arguing at great length that there is only one viable
>>> hypothesis available is not particularly appropriate.
>> You are invited to do so.
>
> No thank you, I've done enough of that recently.
>
>>>>> If you define something named A, then you want the definition to
>>>>> nice and clear. If you get A and ~A at the same time, it means
>>>>> haven't defined A clearly enough after all.
>>>> The law of the excluded middle. Classical logic's most powerful and
>>>> sloppy postulate. Not always present in modern formal logics, and
>>>> often violated by physical models of logic (what happens if you
>>>> connect the output of a logic inverter to its input?).
>>> If you connect the output of a logic inverter to its input you get
>>> something that doesn't reach a stable solution. That's the physical
>>> analogue of finding a logical contradiction.
>> But it's not. Classical logic has no such behavior (while
>> Spencer-Brown's nonstandard logic can model oscillators not
>> regulators). The classical logic model and the physical model disagree
>> on what happens when you assert A=~A. Which is more applicable to the
>> real world?
>
> Is the cretan correct when he says no cretan ever tells the truth? If
> he's right then he's telling the truth. That means the statement is a
> lie. But if it's a lie then it doesn't prove a cretan has ever told the
> truth. So it could easily be true. But if it is true then he's telling
> the truth and it's a lie. It flipflops back and forth. You make models
> that take finite time to go through this cycle and you get an
> oscillator. Which is more applicable to language? If you're talking
> about truth, a statement that denies itself cannot be true.
And that one (the famous Epimenides paradox) cannot be false either. But
there are nonstandard logics that can accommodate this just as there are
non-Euclidean geometries. And these days, Euclidean geometry is no
longer our best model for the geometry of space: Riemannian geometry
currently holds that title. So why should we expect classical logic to
be the right model for all circumstances?
> Your
> physical model reflects that by oscillating, and if you interpret that
> as a model of language that contains an internal contradition then you
> have a good model. If you want to use your physical model to do
> something else, something that depends on the speed your system does the
> logic, that has nothing to do with the model of the language.
>
> If you had a tireless logician who never got bored, you could give him a
> piece of cardboard that had printed on it "The answer to the question is
> on the other side of this page" and you might depend on him to turn the
> page over and over in a regular rhythm. You could use him as a cooling
> fan. The rate of airflow would depend on the speed he happens to think
> it out and turn the page over, which does not at all depend on the logic
> -- except that the more complicated the sentence he parses the slower
> he'll do it.
>
>>>>> But it's a choice between A and ~A.
>>>>> It isn't a definite choice between A and B.
>>>> Bohr would vehemently disagree.
>>> Then Bohr would be wrong.
>> Wrong in science means that a theory makes incorrect predictions. Bohr
>>
>> was often right (none of us is ever always right).
>
> If Bohr got A and ~A then Bohr was confused. (Or he was scamming
> physicsts.)
There are trivial truths and the great truths. The opposite of a trivial
truth is plainly false. The opposite of a great truth is also true.
- Niels Bohr
He wasn't scamming anybody: he was creating a theory that *works*.
> You can always win if you can get away with "Heads I win,
> tails you lose."
Bohr's physics makes solid (although statistical) predictions about the
real world. It just gets there in a way that many find illogical. But,
despite herculean efforts, no reproducible discrepancy with experiment
has ever been found.
> If you have two theories that give different results,
> and you can arrange to use one of them whenever you get one result and
> the other whenever you get the other result, and you call them the same
> theory, you potentially have a scam. If you get to decide which theory
> to apply after you find out what the answer is, that isn't very good. If
> you have a solid workable rule to explain when to apply each theory,
> then you have something that works -- and you might as well give
> different names to the circumstances that fit the different theories.
You need to study some physics. It isn't like that.
>
>> You cannot justify judging right and wrong in the real world using
>> logic. You cannot show any evidence that logic is infallible: you have
>>
>> only a tradition of faith here. Honest examination of actual attempts
>> to use logic to find real world truth reveals millennia of failure.
>
> The trouble is, illogic is confusion.
Only if you insist on using logic. There can be no justification for
that except blind faith.
> You argue that it's better to be
> confused than to get it clear.
> But the search for clarity encourages
> good experiments. It shows up useful problems to resolve.
That is true. But one should not read any significance into a failure to
resolve the "problems". There is no more reason to expect real truth
from logic than there is to expect real truth from Euclidean geometry.
>
>>> The description I labeled A might not be a
>>> good way to describe whatever it is you want to describe with it. It
>>> simply may not make sense to say an electron is smelly or to say
>>> that it's odorless. But if the A description does make sense then
>>> you will not say that it's both A and ~A. When you find yourself
>>> making that claim you are saying that the description does not make
>>> sense.
>> Bohr would tell you that there is absolutely no reason to expect
>> classical logic to apply to the quantum world.
>
> Buhr was confused. He tried to apply concepts that did not apply, and
> the result was further confusion.
No, the result was a theory that *works*. You are using some of the
engineering fruits of that theory as you read this on your computer.
Besides, what is wrong with Bohr's statement? Why should you expect
logic to apply in an area far outside the experience of the people who
originally formulated it?
>
>>>>> Here's how I've understood your basic argument: If Forth was the
>>>>> best computer language it would have taken over the computing
>>>>> by now.
>>>> Gross exaggeration of my position.
>>> Yes, but effective. This is your claim when we remove the
>>> wishy-washy disclaimers.
>> Hmm, you accuse me of demanding perfect results above, yet that is
>> apparently the result of *you* removing the "disclaimers".
>
> Consider this a first approximation to your argument, with some of the
> confounding complexities removed.
>
>>>>> Various people have proposed other things that have kept Forth
>>>>> taking over the world. You have rejected each of them on
>>> dubious>> grounds. For example, there was the argument that Forth has
>>>>> gotten enough institutional support. You said that this
>>> couldn't>> have been The Reason because languages that got the *most*
>>>>> institutional support(PL/1, Ada, etc) have tended to fail and be
>>>>> replaced by other languages that got less institutional support
>>>>> C and Java. But consider -- would you be certain that Forth
>>> has only>> one Fatal Flaw, and that only Forth has one? Perhaps the
>>> languages>> that got the most institutional support happened to have
>>> fatal flaws>> of their own that kept them from great success despite
>>> that support.> Sure. You ever program in PL/I? Ugh! But then, there
>>> are also many > examples of languages with weak early institutional
>>> support like C and> Python that have done very well.
>>>
>>> Yes, you said that repeatedly. In general when you look at why a
>>> plant or animal hasn't taken over an ecosystem, you look at the
>>> *limiting factors*.
>> That'll explain the difference between a desert and a rainforest. It
>> won't explain which plants thrive where: you have to look at the
>> characteristics of the plants themselves.
>
> Each organism has its own limiting factors.
Indeed. So, what are Forth's limiting factors?
> Classical experiments with
> flour beetles showed that in competition one species died out when the
> moisture level was high, the other died out when the moisture level was
> low, and in between it was something of a tossup. Suppose the moisture
> was in the tossup range but you tried high and low salinity. High and
> low temperature. Etc. You might find other ranges where other variables
> are limiting.
>
> Sometimes you emphasize the subliminal programmer-psychology factor, and
> sometimes you deny it.
Huh? Example?
> You point out that successful languages cater to
> the way their users already think.
In some ways. On the other hand, you also have to show them something
better than they've got.
> But consider also that bragging
> rights make a big difference. In the old days, assembly language
> programmers had to be smart, they had the reputation for being the
> smartest. But they wrote code that went obsolete as soon as the
> particular processor went out of date. C let the elite programmers be
> *more* elite. They were the smartest, they wrote the fastest smallest
> code, they went hand-to-hand on the bare metal. C let them do most of
> that and also write portable code that didn't go obsolete so fast.
It, along with Forth, also put elite programmer power in the hands of
domain experts. That was a very good thing.
>
> Forth gave a similar mystique, but there were many incompatible Forths.
> Forth-83 made most of the Forth-79 code obsolete. And there was the
> claim that Forth was easy. Nobody said assembly was easy, and C was
> still hard.
But in my shop we just had one Forth, along with a large body of code.
Still, when C came along, people rather quickly found that it gave them
the ease of Fortran without the limitations. And by that time the
edit-make-run cycle was down to about 30 seconds, fast enough to make
Forth's interactivity seem a minor advantage.
> There's far more prestige in doing things that only very
> smart people can do, hard things.
Yes, but in my shop it was making the most sensitive and accurate
instruments, not sophisticated code.
>
>>> Plants need sunlight, and water, and minerals, and CO2. They
>>> need a place that doesn't have too many things that are poisonous to
>>> them, and they need the herbivore load not to be too severe. They
>>> need temperatures within an acceptable range. Some of them need the
>>> soil to spend some time dry enough. Etc. Whichever of their needs is
>>> in shortest supply is the one that limits them. Similarly, Forth
>>> might have run into some external limit
>> Why didn't C, in the *same* environment, reach the same limit?
>
> First, it wasn't the same environment. Second, it was a different name.
> Imagine you had two languages with two different names and there was no
> important difference between them. Chances are one of them would tend to
> win out. Why stick with two different languages when the weaker of them
> has nothing special to recommend it? Why did C win out over Objective-C?
> There were important differences in that case. Was it some fatal flaw in
> Objective-C?
As someone who preferred Objective-C, I think the answer is similar to
the answer for Forth: Objective-C has rather odd syntax, confusing to
ordinary users.
> How about Borland-C? Haven't there been a lot of C
> compilers that lost out? Did each of them have a fatal flaw? Are you
> sure that the survivors are all the best of breed?
They're good enough.
>
>>> Yes, you said that repeatedly.
>> Indeed. One more truth the Forth community doesn't like to hear.
>
>
>>> And self-taught programmers in those days may not have understood
>>> the lessons that are now generally known about maintenance. You
>>> build whatever shortcuts look useful today, and then you build new
>>> shortcuts tomorrow, and in 2 years you look at your old code and it
>>> doesn't make sense any more.
>> Why wasn't that just as much a problem for the self-taught C
>> programmers?
>
> At the time, C wasn't interpreted. Harder to build little scripted
> widgets that did whatever you wanted. So fewer of them got built. Or
> maybe some other explanation. I'm making this stuff up because I don't
> know the answers and you ask for answers. I can make them up faster than
> you can disprove them. And it's all historical stuff where we can't
> perform good experiments unless they happened to get performed and the
> results recorded. Unless we could get a time machine and access to a lot
> of parallel worlds.
The best we can do is what it is.
>
>>>>> More important, you have championed the idea that computer
>>> languages>> should fit in with the ways that people are predisposed
>>> to think.>> But you violated that idea by your presentation. What
>>> you're saying>> would be fine if you collected a bunch of guys who
>>> used to use Forth>> and who were kind of nostalgic for it, who had to
>>> quit using it>> because it didn't work for them. They'd be
>>> predisposed to believe in>> 3F. They might get all fired up to remove
>>> the 3Fs and create the>> language that will take over the world the
>>> way Forth should have. > But those who've given up think even less of
>>> its future. It's rocky > here, but it's bare lava there.
>>>
>>> Why do you persist in using this single approach that doesn't work?
>>> Why argue 3F when other paths lead to your results without needing
>>> 3F?
>> How can you improve a piece of engineering without recognizing and
>> fixing its limitations?
>
> When you talk about particular limitations that matter to particular
> users, people tend to respond. We've had some talk about how to improve
> library support, how to add type-checking, how to implement other
> languages in Forth, improved string handling, the problem of using
> libraries written in other languages (mostly solved for commercial
> implementations), etc.
It's all good, but not, in my judgment, adequate. Tinkering around the
edges, constrained by the delusion that the standard is something valuable.
When you say that Forth is fundamentally
> inadequate and requires fundamental changes to keep it from sinking into
> justified oblivion, people mostly disagree with you.
>
> Have you noticed this pattern yet?
Oh, I'm used to that pattern. It takes a long time to break down
groupthink. Do you have *any* idea how backward and collectively
stubborn NASA is? Nevertheless, one can sometimes get people to listen.
HETE-2 was an example.
>
>>> I'm glad to have a StrongForth option. But I think if we want a
>>> "user-friendly" language, we ought to re-think what we mean by
>>> "user-friendly". To my way of thinking, it means that the user can
>>> pay attention to the things he cares about and ignore the things
>>> that to him are boilerplate.
>>>
>>> Forth has always done some of that. When I looked at my first
>>> assembly language I found myself juggling registers. There were
>>> registers that were reserved for essential OS functions. I could use
>>> them if I saved them and restored them. Each subroutine I called
>>> would trash some registers and preserve others, and it required its
>>> inputs in particular registers and left its outputs in particular
>>> registers. It was a pain. But then I tried Forth. The registers were
>>> abstracted away. All my inputs were on a stack, and the outputs were
>>> on the same stack. I lost some "efficiency" because my Forth
>>> primitives were grabbing things off the stack and moving them to
>>> registers and doing the ops and moving the results back to the
>>> stack. But I was happy withi that. It was fast enough, and I could
>>> deal with the problems I wanted to solve instead of picky registers.
>
>> The problem is that the bar keeps rising here. As people do more
>> ambitious things with computers, they have less time for the
>> boilerplate. Evolve or die.
>
> Sure. Now, what Forth does is it gives you a chance to define what you
> need using the resources the Forth VM gives you. The fewer layers of
> abstraction etc you build into your solution the less cruft. That's fine
> for people who care about elegant solutions. Do we want people to use
> Forth when they just want to crank out a solution with no thought for
> how the VM does things? We're getting pulled in lots of directions here.
> We can add typecasting and it makes some kinds of optimisation easier.
> Or we can eliminate some of the types we already have and get easier
> programming at a resource cost. Different directions.
>
> There are various ways to hide Forth details so it's easier to get quick
> results. Like, locals in place of data stack ops. If we got enough of
> that we could make a Forth application that could compete as a scripting
> language. Is that worth doing? Why hasn't it been done more? I think the
> main reason is that it doesn't get results that Forth programmers want.
> We program for ourselves, not for scripters who might want a Forth-lite.
Forth is mainly for hermit programmers (and I include myself).
>
> At the moment it seems like pretty much everybody's going with
> abstractions. Solve the problem on an abstract level and get some sort
> way to implement the abstractions, and you don't have to worry about the
> details. Build up abstractions on abstractions. If you implemented the
> abstrations *correctly* then your abstract code will eventually deliver
> correct results provided there are sufficient resources available.
>
> Forth is the main place I see where there's an effort to keep the whole
> system simple. If there's some cheese in that maze, we're the ones
> who'll find it. Should we give that up so we can instead compete with
> other languages where they're strong? (Incidentally, am I wrong about
> that? Are there others I haven't noticed who're working at whole-system
> simplicity?
>
>>> Which details are worth paying attention to? Which are easy to let
>>> people ignore, and then when they want they can drop back to Forth
>>> and pay attention to those again?
>> The only way I know to attack these questions is to study successful
>> languages, and published code in them. Users can't tell you what they
>> would want, but their behavior speaks volumes.
>
> Another approach is to watch what works for you. If Chuck had studied
> successful languages in the 1960's, what would he have based Forth on?
> COBOL and Fortran?
A good approach would have been a "machine-independent assembler"
similar to the Forth he created, with an interactive Fortran or BASIC
layer above. Bob Frankston actually did something like that when he
created ECD BASIC a few years later, but ECD's hardware business lost
too much money and the company folded, so few ever saw the product. But
I did some of the early simulations for the RXTE (
xte.mit.edu) design
with it.
But Chuck was ideologically committed to a single layer of language, as
strongly as von Neumann had been to octal a generation earlier.
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor
necessary to establish practical, real world truth. Those who attempt to
use logic for that purpose are abusing it.
