GEN, HLL+ [far26]

[Francois-Rene Rideau]

 I'd like to regularly post a list of pros and cons about a new language,
and its features. This is new version of far25.
 Here I compare to C++. I added C++ cons 6,7,8 and NewHLL req 5.
Please add comments about other languages. I'll summarize.


C/C++
~~~~~
Advantages:
1- We already know this language, and don't have to readapt to another
language syntax (see New Language Disadvantage 1)
2- We can test language functions immediately, without having to wait
for the kernel to be done (see Disadvantages 4)

Disadvantages:
1- does not include code as a standard object, thus creating a boundary
between using and programming. You can't both program and use at the
same time. That's the opposite of user programmer/user friendliness
(see HP calculators, which despite their lack of power, are much more
usable than my unix workstation, because code IS an object as anything
on the HP).
2- is not a structured language: procedures are all global; that's why
C/C++ will NEVER allow having independent light threads, and why it's
impossible to have a lightweight multitasking system under C/C++.
You may notice that this point is related to the preceding remark:
if procedure were objects, you could include them individually inside
thread objects, then each thread would have its own independent code.
3- C++ know only early binding (i.e., it only compiles directly executable
code), hardly knows about dynamic library linking (that's not a language
transparent feature; only a linker feature); C/C++ considers a program
to be complete, finished, and run in the absolute without interaction
with other programs, but through the system; that's why all ROI in C
must be explicitly done through system calls !!!
4- The "we won't have to rewrite a compiler" argument doesn't stand: if
the system is to be OOed, we'll have to adapt the compiler so as it produce
system requirements complying OO code. Thus, we can easily use code
language code that don't use the kernel, but adapting the compiler output
code to fit kernel requirements will be such that it's difficult to
test programs with the Kernel !
5- As it's a low-level language, either we'll have to have low-level specs
for the OS (as with Unix), so that we can't adapt to an architecture
different from that for the which the OS was designed; or we'll have to
rewrite a great amount of the C/C++ code on each system adaptation.
So we lose either system functionality, or language portability.
6- For the same reason (C/C++ being low-level), we can never achieve
object-level security, but by having a C/C++ program for each object,
which either disallows everything -however little- is an object in the
system, or requires many a low-level system (as opposed to language)
declaration in a C source, and/or requires having tiny C/C++ programs,
which contradicts the heavy compilation cost and the class philosophy
of the language.
7- The C++ philosophy contradicts the idea of late user-object binding.
C++ knows only of early compile-time object binding, or at best/worst
binding with compile-time defined virtual class realization through
virtual tables. So to make the slightiest add/change, you must recompile
the whole app.
8- The C++ preprocessor allows simple macro-definitions, but neither
macro instructions, nor recursive macro definitions. If #define DEF #define
was possible, for example, it would be possible to Ziv-Lempel compress
a source program from C to C.

New Language
~~~~~~~~~~~~
Disadvantages:
1- we have to relearn a new language syntax (see New language advantage 1).
Moreover, our system having a brand new conception, even with a traditional
language, we'll have to learn restrictions about our way of programming.
2- we have to debug the language specifications as we use it. But this can
prove useful to refine the language and the system specs.
3- we have to write a full compiler for it (but actually, as we'll have
a new object code format, we're bound to such thing one day indepently of the
chosen language)

Requirements
1- may be quickly (semi-)compiled at the same time as written, and
intermediate LLL code can be efficiently interpreted.
2- everything is an object, including code, including classes.
3 - parallelism is included in simple language constructs (not
so hard to build from executable code being object).
4- Meta programming easy in the language: the compiler is its own
preprocessor; the language is its own macro-command language.
5- Everything is parametrizable; even the compiler might be thought
as the specialization of a more general object compiler.
6- The language should allow a dynamical range of object binding:
HLL must be bounded as soon as possible to gain efficiency, as late
as possible to keep genericity.

Advantages:
1- We can design the syntax to fit our needs and ideas, so that it's
much easier to use. Moreover, even C isn't our natural language, and
whatever language we use, there will have been adaptating time to use
it.
2- We can correct the lacks of any existing language we would have used.
3- Portability: both the system and the language will be as easy to
port. All you need do is writing a LLL back-end compiler and
hardware specific lolos.
4- The language is perfectly is adapted to the system. No need of bizarre
and slow language -> system call translation.
5- being able to be interpreted, it serves as a shell language as
well as a programming language; being powerful, and easy to specialize
via standard libraries, it also replaces small utility languages
(sed, awk, perl, etc); finally, being high-level and knowing of
relations between objects, it is easily adaptated to an AI language.
So there is no more need to learn a different language for every
application; the same language is used for (almost) everything; no
more need to learn new syntaxes each time.


This isn't finished, but I post it as well. Feel free to add your
comments.

   ,
Fare


PS: BTW, what about far23, Andreas ? Even if it wasn't a fundamental
message, I'd like to have it in my collectin of all my mail about MOOSE.