Sat, 01 Apr 2000 09:15:01 PST
>From: Jason Marshall [mailto:firstname.lastname@example.org]
>> Recently, email@example.com wrote:
>>whiz-bang ways of implementing yet-another-language-with-some-
>>induction-logic is, while interesting, old hat, and does nothing for
>>readability before I've had my morning coffee, which is exactly when
>>I'm going to botch the code.
>Grin. I certainly understand that.
Here's where things get trickier. There's a severe shortage of
in the good-great category. We're short on architects (me), and we're
short on artists (also probably me), and so far, software engineering
an artform, no matter what people try to tell you. It's really no
architectural engineering. You want something to stand up, sure, but
want it to be functionally elegant, and to not fight you all the time.
honestly say I'd like that state of affairs to change, but then, the
works well for me already.
Anyway, that wasn't where I was heading with that. Where was I? Ah,
So since it's hard to find good help, this means I am always going to
at least one coworker who is, essentially, me without my morning
but all day long. Even barring this, there's always going to be The
Guy, fumbling around as s/he figures out how our codebase functions (or
doesn't, as the case may be). I would love to be able to stack the
in favor of the adequate programmer being capable of a significant
fraction of the tasks that a good/great programmer can accomplish.
I want an executive summary of my code. I further want to be able to
indicate that certain salient features of a module of code are
non-negotiable. They are what makes the module functional. I should
be able to watch that no one comes along and breaks this behavior,
in the name of new functionality, on accident. DBC and inheritance
try to accomplish this, but I don't think they cover enough aspects of
This essentially means that I want a delinter as standard equipment for
developers. I want to be warned when a feature of my code is lost or
gained. This should help track down unintended side effects, which
means fewer bugs. I have more interesting things to do with my time,
>>No one talks of formalized metadata, which is what I am after, and
>>I thought/think Fare is after. Why?
>Because you don't talk about it? I mean, if it's interesting, talk
>it! Don't dis my language because I don't talk about what you're
>Okay, the topic is a lot clearer to me. You want metadata, and you
>embedded in the language. IMO, it would be best as an optional thing,
>don't mind it being required. You don't actually object to
>languages; you simply want a language with metadata provided. (You
>have _said_ that, instead of just stating that concatenative languages
I want explicit metadata as a standard, yes. If it's not part of the
process, and doesn't improve static checking of the code, then I don't
how Useful it is. While it's true that a lot of metadata can be
assigned at the
function/method level, I am still not entirely grasping how you prevent
loss of information in the translation from brain-to-silicon within the
and signature of the method in a terse form that relies on deductive
>Okay, try this on for size: a concatenative language with two types of
>annotation. The first, in the form ( x -- y ), appears at the
>the word definition and is a type description (x and y may be any
>type names, seperated by spaces). The last item in x is the type of
>of the stack (as with traditional Forth stack comments). Types are
>entirely statically, and are fully polymorphic (including return
>The second annotation, in the form ( x ), appears anytime within the
>definition of a word, and is a stack naming (x may be any number of
>names). Names for stack elements may be traced at compile time, and
>consistent within a given definition.
> 3 2 ( adder addend ) swap ( addend adder ) + ( sum )
> ( number[myType] number[myType] -- number[myType] )
> ( adder addend ) swap ( addend adder ) + ( sum )
> 3 2 ( adder addend ) swap ( adder ) + ( sum )
>The last one of these demonstrates that the stack names don't have to
>everything on the stack.
I'm mostly worried about names between code modules, where most of the
trouble will crop up.
But if you name the variables, the system can labor to sort out which
order makes most sense, based on data alignment issues, frequency of
argument use, difficulty of reordering at the caller, etc. Your
implementation from four months ago will likely no longer maintain your
optimal ordering as you determined when you first wrote it, and woe be
unto s/he who changes the order of his arguments after everyone else
is already using his/her code.
>>> Of the two of us, who's more likely to reveal the most intent?
>>By sheer volume of citations of intent? Your users. You wrote the
>>once, and now everyone else is having to live with your mistakes (and
>>you are human, so don't imagine you haven't made any, because you
>You missed my point. Take two people, you and me, writing code in our
>seperate languages: yours with named parameters and mine being
>concatenative. Which OF THOSE TWO PEOPLE will reveal more intent by
>of their language's mechanisms which are designed for that purpose?
> - The concatenative language is designed for quick, easy factoring
>refactoring, allowing the author to create many functions which work
>together to solve his problem, and leave many component functions
> - The parameterized language is designed to allow the programmer to
>his parameters, and communicate those names to later reusers.
>Both languages have ways of communicating internal intent to the
>world, as well as structuring to preserve internal intent. Do you
>think that one of these MUST be more revealing than the other?
>>I am familliar with the classes of mistakes programmers in team an
>>settings make, in real development environments.
>>I understand that Kyle has grasped this, and that you see it as a
>No, I don't see it as a non-issue -- I simply see many other issues to
>with, which add up to readability.
>Note that Forth traditionally has no type checking at all (although my
>suggestion for type checking, above, is based on a Forth type
>even large projects in Forth don't run into that particular problem
>much -- almost certainly because it's so painful to use large numbers
>parameters in Forth.
I keep bumping into situations where static type checking seriously
the advantages gained by reflective code. Sometimes pushing error
discovery off until runtime comes back to bite you in the butt.
>>Not in the least. People want flexibility in a language in case
>>the environment isn't subtle enough for their tastes. Then they turn
>>around and complain because everyone comes up with a 'clever' synonym
>>for the code they would have written, sometimes correctly, sometimes
>>totally wrong, but either way, totally greek to their peers.
>>takes the edge off such concerns over abuse of power. Here is your
>>rope sir, but you have to justify any requests to tie it into a knot.
>The odd thing is that I think I understand what you're saying (both
>you've said it), and I'm just about certain I agree entirely with it,
>_still_ don't see what on earth it has to do with our discussion.
>this have to do with named parameters versus implicit parameter
Because formal logical naming of parameters is a type of formalism.
>>> -- except that you have a huge translation layer, and I have a tiny
>>I have a segmented translation layer, which is an important
>I have three low-level segments:
> - the quotation system (which defines a 'function structure' and
>ways of accessing its fields and compiling natively the function it
>indicates; the function structures contain properties such as
>data, frequency of calls, and so on; this layer is also written in
The segments to which I refer fall within the spirit of your quotation
>>You have a tiny translation layer, or you're falling victim to the
>>incomplete implementation fallacy?
>Well, there are two systems like this that I know of which have been
>commercial use for five to ten years now. Add a third, if you count
>(which uses a similar design but with a slightly different emphasis on
>>How big is your standard library going to be?
>If it includes everything TUNES wants, infinitely large. However, I
>it to fit on a floppy.
Okay, so in order to compete on the merit of size alone, my interpreter
has to provide enough extra value to reduce the verbosity of the core
libraries. I am hopeful that such will be the case. That was the
I was trying to get across.
>>Concerns over how big an 'unabridged' edition of the machine would be
>>have some merit, but not as much as you're attributing to the issue.
>Okay, here's the concern I'm expressing: contrary to your statement, I
>believe that my optimiser, with or without metainformation, will
>compact, efficient code. I base this opinion on systems similar to
>such as Quartus Forth and 4THCOMP.
How do these systems benchmark compared to C or C++ equivalent
code? I've been curious about how these other styles compare to
the rest of the industry.
>>There is no requirement that a compiler issue, or the
>>any optional data. If the optional data represents 80% of the
>>and 90% of the implementation complexity, who really cares? All I've
>>is provide a formal vessel into which optional tools can place their
>>data, in an attempt to avoid ad hoc formats. What does that hurt?
>>Nothing, according to the industry examples I can find.
>Our discussion used to be about a language which _required_ parameter
>to be included in every call. I don't know what you're discussing
>it's definitely not the same thing. Could you provide an URL, or give
>description of what you're talking about?
I'm discussing things you snipped from my previous letter. Your
size issues I assumed was directed at my general desire to have a
markup system for the code, of which parameter names were but one
markup. Apparently I misinterpreted where you were going with that.
>>Different environments will contain a different subset of the content
>>handlers for the language. My deployment environments won't care
>>debug data. My dev environment will. My palm pilot doesn't care
>>MPP or high precision math or vector math, or advanced speed-for-
>>tradeoffs. My workstation doesn't care about space-for-speed
>>but when I'm downloading a new multiplayer game off the net, I'd much
>>appreciate if it was usable the first time I ran it. No VM I know of
>>is giving me that.
>Check out Elate, formerly known as Tao OS, at
>http://www.tao.co.uk/2/tao/index.html. Very cool. Very similar to
>and I are building, and does exactly what you say.
And commercial, yes? If I've learned anything, it's that you always
give the razor
away for free, and then you talk about selling the blades. Every
someone has forced developers to buy has been marginalized. You want
money off a language? Fine. You wrote the thing, don't you think that
you to make a killing on consulting contracts? Books? Just please
stop this silly
nonsense of trying to sell the basic runtime.