# Thread, a vaguely related query language (and hello!)

## glenn mcdonald — 2010-09-29 14:47:31

    Hi. I came across this group while poking around the web looking for

    discussions of language-design issues. I work on www.needlebase.com, a

    database system of sorts that includes a path-oriented query language called

    Thread.

    Thread isn't strictly concatenative in the pure sense, as its built-in

    operations do take parameters, but it uses a working set similar to the way

    concatenative languages use the stack, and many functions (counting, math,

    etc.) operate in a postfix, parameterless way. So, for example, getting the

    difference between launch mass and empty mass for a bunch of satellites

    would look like this:

    Satellite|(..Launch Mass,Empty Mass._-)

    If you're interested, there's an introduction to this language at

    https://pub.needlebase.com/docs/ThreadManual.html.

    glenn

    [Non-text portions of this message have been removed]

## chris glur — 2010-10-11 14:07:15

    A> I came across this group while poking around the web looking

     > for discussions of language-design issues.

     Like I used to say: 'surfing, is "going nowhere" while waiting to fall off'.

    The language-design space seems to be getting cluttered.

    Woman's-design/fashion is also cluttered, but its goals are more fuzzy and

    more difficult to articulate, than language-design; which IMO should be

    goal-directed. And the goal/s should be stated up-front, and serve as a

    disciplining guides for less 'surfing' and more directed effort.

    I'll give an example [which could be completely wrong]:-

    The aim of computer 'language-design' must be to increases productivity;

     ie. more value-added for less pain.

    Major problem sources are the difficulties to control complexity.

    Without analysing complexity, I'll define it as the number of reltionships.

    So, eg. the number of function args and returned values.

    If 'point-free' can reduce the arg-count, it will reduce complexity and

     increase productivity.

    Again, from the well known fact that the pain/error-proneness increases

    drastically with the numbers of concepts/relations that need to be retained

    during the mental-design process: the pipe-lining capabilities of concat

    languages helps productivity, because 'separation of concern' reduces

    coupling  -  the need to know other stuff.

    With the pipe-lining/data-flow approach, we only need to be concerned with

    the previous and the next function/transformation. We can ignore all other

    stages -- what a relief!!

    My latest utility in this style [which you all need: to find that file that

    you were recently reading which mentioned A, B, C]; is conceptually simple:-

    = get the files [in dir tree D] which are less than [N days old]

     but keep only the ones containing "ussia"

     and of those keep only the ones containing "water"

     and of those keep only the ones containing "evelopmenmt"

    .... filter more if needed, with minimal incremental effort.

    ------

    Apparently 'factor' is a new language which impresses many.

    Again I only find 'fuzzy statements' to claim it's advantages.

    Here's an attempt at CONCRETE criticism of 'factor'.

    ---

    ] Reportedly, increased readability comes from increased factorisation.

    This is because of the increased effective documentation/commenting

    which comes from meaningfully chosen names. Straight documentation, would

    achieve the same - with it's price.

    NB, you notice the "Reportedly" fuzzy-talk: ie. 'I don't want to make a

    concrete scientific assertion', but it 'feels better'.

    ] "Use Cleave combinators and Spread combinators instead of

    ] ShuffleWords to give your code more structure."

    You shouldn't even EVER be thinking about a stack.

    We abandoned having to think about registers & mem-locations decades ago.

    It's enough of a mental load to have to think of the problem domain.

    We want to leave the semi-conductor physics and other layers to others

     to worry about.

    ---

    IIRC from a mere 2 days ago - because I don't WANT to clutter my mind with

    these new-fad languages: factor's 'IfThenElse' construct's syntax is:

    [<predicate>] [<then statement>] [<else statement] "if".

    Some reasons why this is INFERIOR to languages from the previous millennium are:

    * The 'IfThenElse' construct is an entity which has 3 parts. So the 'IF ID' and

    the 3 parts should be immediately obvious. Factor almost achieves this.  But, by

    the principle of 'top down analysis' and 'we read from left to right',

    factor fails.

    It's better to say: "it's a table. It's got 4 legs and it's brown", than to say

     "it's got 4 legs and it's brown. It's a horse".

    Saying "a little, red hat" requires the "little" & "red" to be

    stacked/cognitive-load,

    waiting for "hat" to arrive to resolve the concept. So

    'hat:little:red' is better.

    The reason why factor and other new-fad languages put the <IF ID> at the end, is

    for the convenience of the compiler.  What am I paying for, if I have to do the

    compiler's job?!

    So then I analysed how Algol-family eg. Oberon does it:

    "IF <predicate>" : put the ID up-front, PLUS allow it to serve as the delimiter

     for the predicate, instead of introducing a redundant/extra token "[".

    "THEN <TstatementS>" : use the mnemonically valued token "THEN" to

    carry intelligence

         PLUS do separation.

    "ELSE <EstatementS>" : ditto.

    "END" : this 'good name' doesn't use up tokens like "]", "}" which are

    needed for

    maths expressions.

    --

    Although it's never stated, I suspect the apparent 'visual compactness' makes

    many of these <the programmer does half the compiler's job>/languages>

    attractive.

    Provided programming is still done by entering chars, this argument has merit.

    IMO the <IfThenElse> construct should just be selected off a menu, and

    the 'args'Variable typing is a different story, which I can't comment

    on.

    Also, there are big advantages in having the reserved-words all in UPPER-CASE,

    to emphasize that they form the separators of the 'concepts'. Ie. 'you are now

    entering/leaving a new-concept.

    ---------------

    Decades of *nix usage has shown that the pipe-line/concat style is economical,

    for scripting, provided the functions which do the heavy-lifting already exist.

    Apparently factor was started as a scripting-language.

    So at the hi-level it could be good. OTOH the *nix utilities are very baroque;

    and apparently not an integrated design. I'm confused that/how sometimes the

    input is from the left and sometimes from the right.

     >  If you're interested, there's an introduction to this language at

     We need a 'Hello world'/<minimal demo that/how it will pay its rent>.

    Or even better, a list of it's design decisions.

    == Chris Glur.

    filled-n, spreadsheet like.

    Not only should we not have to do half the compiler's job, but we should be free

    of all syntax quirks that are for the compiler's convenience.

     On 9/29/10, glenn mcdonald <gmcdonald@...> wrote:

    > Hi. I came across this group while poking around the web looking for

    > discussions of language-design issues. I work on www.needlebase.com, a

    > database system of sorts that includes a path-oriented query language called

    > Thread.

    >

    > Thread isn't strictly concatenative in the pure sense, as its built-in

    > operations do take parameters, but it uses a working set similar to the way

    > concatenative languages use the stack, and many functions (counting, math,

    > etc.) operate in a postfix, parameterless way. So, for example, getting the

    > difference between launch mass and empty mass for a bunch of satellites

    > would look like this:

    >

    > Satellite|(..Launch Mass,Empty Mass._-)

    >

    > If you're interested, there's an introduction to this language at

    > https://pub.needlebase.com/docs/ThreadManual.html.

    >

    > glenn

    >

    >

    > [Non-text portions of this message have been removed]

    >

    >

## William Tanksley, Jr — 2010-10-19 23:41:56

    chris glur <crglur@...> wrote:

     > The reason why factor and other new-fad languages put the <IF ID> at the end, is

     Guys, it's official: concatenative languages have hit the big-time.

    We're a fad now! :-)

     > Although it's never stated, I suspect the apparent 'visual compactness' makes

    > many of these <the programmer does half the compiler's job>/languages>

    > attractive.

     Check out Arc, Paul Graham's language at

    http://www.paulgraham.com/arc.html. He clearly and explicitly states

    that compactness is a primary measure of the power of a programming

    language. The APL people said that long ago --- they actually decided

    to give up almost all maintainability in return for extreme terseness,

    with the assumption that a new maintenance programmer would have to

    normally rewrite a function from its design and/or specification in

    order to modify it. But since a function is normally a single line

    long, that's not THAT bad.

    Concatenative languages, in my experience, don't tend to take a hard

    position on the terseness scale. Some of them, like Forth, have some

    communities that strongly emphasize terseness (Chuck Moore's 1xForth);

    others look at more variables.

     > Provided programming is still done by entering chars, this argument has merit.

    > IMO the <IfThenElse> construct should just be selected off a menu, and

     You're overlooking the advantage of being able to SEE more of your

    program. (Menus have their own tradeoffs, plusses and minuses; but I

    tend to agree that as far as function names go, we have good solutions

    like autocomplete that do the job.)

     > Apparently factor was started as a scripting-language.

     You could look at its history (and see that it wasn't).

     > == Chris Glur.

     -Wm

## Chris Double — 2010-10-19 23:50:54

    On Tue, Oct 12, 2010 at 3:07 AM, chris glur <crglur@...> wrote:

     > IIRC from a mere 2 days ago - because I don't WANT to clutter my mind with

    > these new-fad languages: factor's 'IfThenElse' construct's syntax is:

    > [<predicate>] [<then statement>] [<else statement] "if".

     Factor's 'if' is:

      boolean [ then ] [ else ] if

    You might be thinking of Joy which is:

      [ predicate ] [ then ] [ else ] ifte

    Chris.

    --

    http://www.bluishcoder.co.nz

## glenn mcdonald — 2010-10-20 00:06:13

    >

    > ...compactness is a primary measure of the power of a programming

    > language.

    >

     A slightly different way of looking at this is that the more a program looks

    like it's about what it's actually about, the better the interaction between

    programmer and program will be, and ultimately this has a positive effect on

    the quality of the produced software. Thus terseness isn't exactly an end in

    itself, but a tactic for keeping the mechanics of the language out of the

    way of the program and the programmer. Chris Glur's exhortation to put

    LANGUAGE KEYWORDS IN ALL CAPS is pretty much the opposite approach, a kind

    of shouty programming-language narcissism in which the programs are more

    about the act of (trying to) program than they are about their nominal

    subjects.

    [Non-text portions of this message have been removed]

## chris glur — 2010-11-01 02:18:57

    chris.double wrote:----------

     Factor's 'if' is:

     boolean [ then ] [ else ] if

     You might be thinking of Joy which is:

     [ predicate ] [ then ] [ else ] ifte

    --------------

    Yes and 'canonical' asm [what the CPU wants from the compiler] is

      <predicate expression>

    JMPtoELSEifFale

      <ThenStatement>

      JMPtoExit

    ELSE: <ElseStatement>

    Exit:

    The point is: these are designed for the hardware.

    The language should be designed for the HUMAN.

    So, the criteria should be psychological considerations.

    We techies, aren't trained to openly discuss these vital aspects.

    ---------

    Again, the reason why the token indicating the structure type should be FIRST,

    is to avoid the 'German-like' situation, were you get the first clue of the verb

    at the start of the sentence, and then have to retain/stack the rest of the

    sentence until the closing part of the verb allows 'resolution'.

    Especially for nested IfThenElses, this unnecessary cognitive load is bad.

    -------

    gmcdonald wrote:-

    Chris Glur's exhortation to put  LANGUAGE KEYWORDS IN ALL CAPS

    -------

    No it's NOT my idea. It's from pascal/oberon, designed by one of computing

    hi-priests, who was part of the Algol design committees in the 60s.

    Like y'all, I've been 'just doing it for years'.

    Only recently, did I start to analyse, and realise that the new-stuff is

    inferior.

    -----------

    Terseness contributes to 'being able to see as much of the CONCEPT at once'.

    OTOH the java-style of LOngDescriptiveNouns has merit.

    BTW compare YOUR English sentences to mine re. terseness.

    -----------

    Because you kiddies choose to use blogs and stuff which can't conveniently

    retain a thread, like Usenet, which was designed by engineers CAN, I don't know

    if I mentioned Backus.78's, which elaborates this topic. Or was that ONLY in

    my <Backus'78 style for increased productivety> usenet post?

    ----BTW re. shouting the keywords; I'd go further. I love syntax

    colouring editors.

    A comment by Manfred von Thun that his 'posts were coming out all jaggered'

    confused me.  I hate technical-text which is formatted in equal length lines,

    with word splits like "con-veniently". I.e. with no structure.

    But why should my psychological preferences over-ride yours.

    OTOH these subtle aspects need to be discussed.

    It's economical to use colour, UPPERCASE and 'layout' to convey the several

    'dimensions' of the concept-stream; instead of relying on 'linear-decoding'.

    It's uneconomical for transfering complex technical concepts between people

    for each to need to be a wordsmith, with the same assumptions.

    Admit: ya'all speak English just because that's how you were born.

     On 10/20/10, glenn mcdonald <gmcdonald@...> wrote:

    >>

    >> ...compactness is a primary measure of the power of a programming

    >> language.

    >>

    >

    > A slightly different way of looking at this is that the more a program looks

    > like it's about what it's actually about, the better the interaction between

    > programmer and program will be, and ultimately this has a positive effect on

    > the quality of the produced software. Thus terseness isn't exactly an end in

    > itself, but a tactic for keeping the mechanics of the language out of the

    > way of the program and the programmer. Chris Glur's exhortation to put

    > LANGUAGE KEYWORDS IN ALL CAPS is pretty much the opposite approach, a kind

    > of shouty programming-language narcissism in which the programs are more

    > about the act of (trying to) program than they are about their nominal

    > subjects.

    >

    >

    > [Non-text portions of this message have been removed]

    >

    >