Impressions

[Erez]

Filiba has directed me to your project, and I've read it relatively
thoroughly.
I like the directions in which you are trying to take the programming
world. These are directions I was trying to take myself, and I've
found many of your ideas on par with mine.
I have much to say about what you wrote, but instead I've decided to
dump my own thoughts first.

Since languages in general are an interest of mine, I will write a
little about that.

In trying to create a new programming language, it's important to
realize this: Programming languages are languages. As such, they are
used communicate between entities. But unlike natural langs which
communicate between humans to humans, prog-langs communicate both
between humans to computers, and humans to humans. Many unjustly
dismiss the latter.
Also, humans are more often in the "listening" end than in the
"speaking" end.
Therefore, it is crucial that both computers and humans can understand
quickly and fully. An implied solution is to make the programming
language as close as possible to a natural language, while keeping it
readable by computers. I like this solution, however it's not the only
possibility.
This, btw, enforces the common suspicion that Perl was never meant for
human beings.

I found that languages are used in 3 ways:
1) Querying information (how much is this pen?)
2) Providing information (it costs 1$)
3) Commanding actions (give it to me)

These can be found in programming languages as well. In fact, they are
embedded in the main paradigms of programming:
1) Querying information - basically functional in nature. (It's
obvious for SQL, but also most (pure) functions are about answering
questions, such as "what is the cosine of 48" or "does this string
contain the other?" etc.)
2) Providing information - Data structures, Meta-languages? (<item
name="pen" price="1$">)
3) Commanding actions - Imperative programming style

A language branches its information (for all usages) by categories,
which can be conceptually accessed by questions: What, How, Why, When,
etc.
Looking at an imperative language reveals many of these branches:
* Function names and comments serve as "what" (what to do): concat,
print, read...
* Code serves as the "how" (how to do it).
* In-Code Comments usually used to state "why". (when not used to
rephrase the how in a more humanly understandable way)
However, this is a poor language construct, both in the richness of
branches and in the way they are described. Also, the need for a meta-
language (comment) to complement the current ones is catastrophic
(excepting the "why" which should remain meta-).

The key to a human-and-computer readable programming language is thus
revealed: Enforce these branches correctly, and allow as much
communication as possible to occur within the language rather than in
the meta-language.
To be a more concrete, the language should:
* Support a full detail of the "what" - this means not only specifying
a name, arguments and return type, but describing the exact input,
output and side-effects (if any) of the function/method. If some of
this could be generated automatically (side-effects?), all the better.
* Completely separate the "what" and the "how": When reading code it's
important to understand what is done (and why), with little concern as
to how (except for cases where your interest lie). Hide the how = more
readable for humans. Nowadays the separation is poor - implementation
details propagate, and mostly since the previous point isn't done. A
GUI with a tree-like view of foldable (collapsible) "how" for each
"what" will make this both easier to write and to read.
* Add more constructs. Why not be able to say "CheckQueue() every 5
seconds" or "CallMe() when Queue.count != 0" ? etc.


Well, I have other thoughts regarding laziness and solidity of code,
but i think i babbled enough for now.
I hope you found any of this interesting. If so, you can reach me by e-
mail.