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 <at> furia.com> 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]
>
>
RSS Feed