Re: Intercepting the text interpreter.

Andrew Haley wrote:
I am saying that base prefixes are not sufficiently useful to justify
the additional complexity they add to the language. The fact that
some of your programmers routinely say things like "A-thousand" does
not affect this in any way.

And with this, we see your priorities. You don't care about the programmer actually using the language. You care about the language itself.

How? This argument is fundamentally about a judgement call. There
are advantages and disadvantages to be weighed. Presumably you admit
that adding prefixes to numbers adds additional complexity to the
specification of the language and its implementation. Also presumably
you admit that, as a general rule, additional complexity is bad.
However, for you base prefixes are so useful that the additional
complexity is insignificant.

No, I don't think it adds complexity because my concern is for the conceptual complexity of the language. I think the current situation with regard to how numbers are handled is *more* conceptually complex for the various reasons I've stated and provided examples for.

And yes, as a general rule, adding complexity is bad. The exception is when that complexity provides a benefit. The Forth language itself is more complex than assembly language. Does that mean Forth is bad? No-- the added complexity of Forth has numerous benefits.

Your talking about complexity in the abstract to me is like trying to compare numbers without units. Is 40 better than 85? It is if it's a measure of the lines of code I have to write to express an idea. It isn't if it's a salary being offered. Words like "complexity" mean nothing without a context to understand them in.

How can anyone provide an example of why one is more important than
the other?

The point of an example in this case is to illustrate priorities. My examples point to number prefixes reducing the conceptual complexity for users of the language. My examples point to the elimination of a class of bugs. My examples point to reducing the number of concepts a programmer has to deal with when writing code.

You on the other hand just issue opinions. Again, people are free to judge which is more compelling to them.

But really, this is pointless. We've now moved from arguing about the
point to arguing about arguing.

Yes. And that has the benefit of helping people think more critically about the quality of argument offered in comp.lang.forth.
.

Relevant Pages

  • Berlinski paper presented 1985 at Applied systems analysis
    ... Complexity, Language and Life: Mathematical Approaches, ... This paper explores the idea that life comprises a language-like ...
    (talk.origins)
  • Re: Boxing and Unboxing ??
    ... It also increases language complexity, which can increase programmer ... adding one simple parameter qualifier and removing a complex qualifier. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C or C++
    ... that the beginner programmer is an adult --- they're like innocent ... it is indeed a simpler language (from a certain ... even though it is an extremely complex language, the complexity ...
    (comp.os.linux.development.apps)
  • Re: Programmers unpaid overtime.
    ... The cache solution's execution time formula is a function of the total ... The campaign is part of what I consider the deprivation of language by ... You can't, in other words, document, and management wonders why ... >> complexity with a few benchmarks. ...
    (comp.programming)
  • Re: Kolmogorov complexity and logical languages
    ... I have looked into the Kolmogorov thingie a bit. ... it is hard to say that one language is more complex than another. ... with linguistics. ... instead of the more abstract notion of complexity. ...
    (sci.lang)