Jonah Thomas wrote:
> John Doty
whispertel.LoseTheH.net> wrote:>> Jonah Thomas 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.
Note that this is not especially controversial among 21st century
logicians (I am the proud father of one). But our common culture still
holds logic in a superstitious regard it manifestly doesn't deserve.
You're using a device that can evaluate logical propositions billions of
times faster and more accurately than you can toi look at this message.
Can it think rationally?
>
>>> 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.
>
> Similarly, if you wind up claiming that the same political candidate is
> a reactionary conservative and also a wild-eyed leftist radical, your
> language is faulty. Better to use language that better describes what he
> wants to do instead of the labels that don't work well.
>
>>> 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.
>
>>> Give the different things different names and the contradictions go
>>> away. The language gets easier to use, because you don't have to
>>> "just know" which times the names refer to one thing and which times
>>> to another.
>> It requires an infinite vocabulary, but we are finite creatures.
>
> 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 then
>>> you consider one new idea, and you talk as if one or the other of
>>> them must be right. This is unscientific. If you show that the CW is
>>> wrong, it does not mean that any particular alternative must be
>>> right.
>> Unscientific? *All* scientific inquiry is like this. Science proceeds
>> by falsification. One can *never* in science prove a hypothesis is
>> true.
>
> The big value in comparing multiple hypotheses that all fit the known
> data, is that they may give different predictions for data that hasn't
> been collected yet. So they give a clue for what data is worth
> collecting next. If they disagree, at least one of them will be wrong
> when you look at the results they predict differently.
Yep. That's how I make my living.
> 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.
> 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.
That's proven to be an effective path to practical knowledge. But
scientific hypotheses are generally false in a logical sense. Pretty
much all of the physics we teach engineering students is just
approximations of the real thing, falsified by experiments outside the
domain in which we expect it to be used.
>
>>> 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.
>
>>> If you define something named A, then you want the definition to be
>>> nice and clear. If you get A and ~A at the same time, it means you
>>> 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.
Eh? In my ASICs I do exactly that to get a stable regulated voltage at
the gate threshold. Very stable. With multiple gates you can make nice
oscillators. Very useful.
> 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?
>
>>> 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).
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 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. And note that "under what
circumstances may we apply this logic?" (there are many "logics" these
days, just as there are many "geometries") is a perfectly respectable
question among modern logicians.
>
>>> Here's how I've understood your basic argument: If Forth was the
>>> best computer language it would have taken over the computing world
>>> 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".
>
>>> It has not done so. So it must have one or more fatal flaws that
>>> keep it from being great.
>> Consider the history. Forth *was* a widely respected and used language
>>
>> circa 1980. But C ate its lunch. And the explanations that do not
>> involve flaws in Forth (including its culture) don't work.
>
> They can work. You can argue that the 3F claim works better.
>
>>> The obvious conclusion from that is that we should
>>> form a harmonious group that searches through everything we know
>>> about Forth and other languages to identify Forths Fatal Flaws
>>> (appreviated 3F). Once we get a consensus what the 3Fs are then we
>>> can harmoniously cooperate to fix them. This will give us a new
>>> language that we can label "Forth" which will inevitably take over
>>> the world.
>> Nah. We should be *experimenting*. We should be publishing stuff
>> people will use (not yet another Sudoku solver).
>
> Well, in one extreme that says we should all go ahead and do whatever we
> were going to do anyway. The result (apart from arguing about it) is
> experimentation. In the other extreme we should try to cooperate on a
> large common project to leverage our efforts.
>
>> "Underground Forths are needed."
>
> It could be argued that we have an adequate number of incompatible
> Forths already.
Yes, but mostly the differences are trivial incompatibilities, not major
innovations.
>
>>> Various people have proposed other things that have kept Forth from
>>> taking over the world. You have rejected each of them on dubious
>>> grounds. For example, there was the argument that Forth has never
>>> 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 like
>>> 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.
> 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?
> before it reached the limits that might have been
> imposed by its chaos of incompatible compilers, or by its mass of
> self-taught programmers with no common coding standards, or its lack of
> standards for library construction, etc.
>
>>> While C and Java got *enough*
>>> support that the lack of it didn't stop them.
>> C? AT&T's support for C came *after* its success was clear. Before
>> that, it was just a toy to keep their CS research group happy and
>> productive.
>
> Yes, you said that repeatedly.
Indeed. One more truth the Forth community doesn't like to hear.
>
>>> And Forth got none.
>> Forth had lots of institutional support in astronomy: why didn't it
>> continue to thrive there?
>
> I could make up various stories. I can imagine that C had the cachet of
> being a portable assembly language, the coolest of the cool at the time.
Nah. The cool stuff isn't the software.
> Forth may have been easier for astronomers to get results in for
> themselves, but when they did they had to keep getting results for
> themselves. After you build a system in Forth can you hire a journeyman
> Forth programmer to maintain it for you? Astronomers may have noticed
> that using Forth tended to send them into a career trajectory where they
> did more programming and less astronomy.
Yes. Forth was harder to maintain.
>
> 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?
> A giant mess of kludges. That doesn't have to happen in
> Forth but Forth makes that very easy if you're heading that direction
> anyway. You wind up with a great big pile of unmaintainable code that
> you can't fob off on paid programmers. So you dump Forth and start over.
>
> Sometimes external forces matter a lot. There was a time when
> WordPerfect was a leading word processor. But Microsoft Word mostly took
> over. At the time a lot of people said Word was inferior. They wanted to
> go on using the system they were familiar with. But they kept getting
> documents from other people in Word and they had to be able to handle
> that, so they had to switch.
Before 1980, the imported code in my area was essentially all Fortran.
Forth held its own against that. But C was tougher competition.
Importation was not a factor early in the eclipse of Forth by C
(everybody was writing their own C code, just as everybody was writing
their own Forth code), but later on it certainly accelerated the process.
In the legal field though, a lot of judges
> wouldn't go along. They refused to accept Word documents, they wanted
> WordPerfect. Judges were so important everybody else in that arena had
> to be compatible with them. As late as 10 years ago lots of legal stuff
> was still done with WordPerfect because of it. If astronomers already
> had to deal with C (machinery they bought that was already programmed in
> C, numerical stuff that was getting converted from Fortran, etc) then
> they might not be as effective as the legal profession in resisting
> those forces.
>
> I could probably make up lots of other stories. But i wasn't there. You
> were there but I've seen little reason to believe your explanations.
> They could be true but you don't look reliable on the topic. For me it's
> an open question.
What I say just doesn't match your prejudices, I think.
>
>>> I
>>> remember when Forthers were tremendously excited because Harris
>>> Semiconductor was making the RTX chips. It wasn't just that there
>>> were going to be 16-bit specialty Forth chips. It was that Harris
>>> was providing Forth with its first ever institutional support. And
>>> then Harris mothballed the RTX. Forth has survived with no overt
>>> institutional support whatsoever, except for what Harris provided.
>>> Whatever institutional support Forth has gotten has come from
>>> classified military programs and secret business ventures.
>> Pure nonsense. Was it just hobbyists using Forth at MIT, SAO, NRAO,
>> KPNO, etc.?
>
> Perhaps we mean different things by institutional support.
Could be, but I fail to see what difference it makes, except if you're
desperate to avoid facing the problems in Forth.
>
>>> 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?
>
>>> But what if you instead presented interesting ideas. Could we build
>>> an extension onto Forth that wasn't postfix? Of course we could. We
>>> mostly haven't bothered because we haven't much wanted to. If we had
>>> such a thing we could measure how much extra complexity it added to
>>> a Forth compiler. We wouldn't have to argue about whether it would
>>> be too complex, we could measure it. We could measure the slowdown
>>> in runtime and the slowdown in compile-time. There might be people
>>> who'd find those penalties acceptable.
>> You're going down the MAGIC/L road. It almost worked for Loki. What
>> was missing there? Can it be fixed? What can we learn from their
>> failure and other successes? I think Python is telling us a lot about
>> libraries.
>
> OK, let's look at Python. What people say is that Python is great
> because it has a lot of libraries. And Python has a lot of libraries
> because they have a culture that encourages library-building?
Also a really, really easy and effective import mechanism.
> And as a
> result they have software tools that make it easy to write libraries and
> find libraries you might want, and install libraries etc. OK, if a Forth
> can interface to a Python library, how much harder would it be to
> automatically define Forth commands that have that interface? If you
> could automate that process then for every public-domain Python library
> you could create a Forth library that does the same thing, with little
> effort.
But the languages are fundamentally different, and have different
application domains. Python's foundations are wrong for Forth jobs and
vice-versa. The point of looking at Python is to study the support
structure atop the foundations: syntax, scoping, importation, etc. A
21st century Forth might do well to superficially resemble Python, but
fundamentally it should be very different. Otherwise, what's the point?
> The big effort would be creating the documentation and example
> code etc. But it looks like a start to have a long list of Forth
> libraries, even if the documentation is weak.
>
> I googled "Python library" and picked a random reference on the first
> page.
>
http://www.scipy.org/
>
> Then I picked a random library.
>
http://abel.ee.ucla.edu/cvxopt
>
> I picked documentation for a random collection of routines.
>
http://abel.ee.ucla.edu/cvxopt/documentation/users-guide/node14.html
>
> 3.2 Level 1 BLAS
> The level 1 functions implement vector operations.
>
> scal(alpha, x)
>
> Scales a vector by a constant:
>
> \begin{displaymath} x := \alpha x. \end{displaymath}
>
> If x is a real matrix, the scalar argument alpha must be a Python
> integer or float. If x is complex, alpha can be an integer, float, or
> complex.
>
> So we'd have a Forth routine named scal that takes parameters x alpha,
> where x is somehow an array in Python format. How would it know whether
> to get an integer from the stack or a float from the float stack? Python
> knows. That would have to be in the interface. Probably Forth would need
> at least two routines, one for an integer alpha and one for a float
> alpha. A third for a complex alpha. I don't see how to fully automate
> this. Some of the work could be automated.
>
> nrm2(x)
>
> Euclidean norm of a vector: returns
>
> \begin{displaymath} \Vert x\Vert _2. \end{displaymath}
>
> Better. nrm2 is the name, x is the parameter. We might need some kind of
> datatyping so the Forth code would know what kind of array it was.
>
>
> It doesn't look completely straightforward. You have to have your data
> in a format Python will understand. That can be automated but you have
> to tell the automated routine what kind of data it is. You can probably
> automate the calls easily enough so that users don't have to arrange
> that themselves, and some of the documentation looks easy to dump to
> Forth. But there are parts of it that would be hard to automate.
>
>>> Please! Give up the worthless side issue of Fatal Flaws and tell us
>>> about things we can try out.
>> "Underground Forths are needed". I'm very pleased by the recent
>> StrongForth discussion, as it seems to me that the StrongForth
>> approach fixes some major issues that prevent traditional Forth from
>> being used as a reasonable foundation for a user-friendly language.
>
> 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.
>
> I liked your idea of using 8-byte cells for every data type. When memory
> is not an issue, that makes lots of things simpler. A Forth that does
> that could import standard code just fine. Redefine C@ 2@ F@ as @ .
> Redefine D+ as + . Etc. Your code won't export to standard systems but
> code that ignores memory use will probably have to be rewritten anyway
> for systems where that matters.
>
> If performance isn't an issue, you can do implicit datatyping. You know
> what type a number is when it's first entered. You can track what type
> to expect off each arithmetic operation, when you know the types of the
> inputs. You can do dynamic typing and the user never has to declare
> types. Of course the result is extra complexity under the hood, hiding
> things from users. But if datatypes aren't the problem I want to solve,
> why not? Ignore the stuff you don't care about (like registers and CHAR+
> CELL+ ALIGN ALIGNED etc) and solve the problems of interest. Then when
> it's working if performance turns into an issue you can go back and
> optimise.
>
> 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.
--
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.
