This is the Qomp programming language home page.
It is a rough copy.
Future downloads will be located on this site.
To learn more about Qomp see
Qomp (short for Qompute) is the concise, precise, structured, modular programming language.
- inspired by Algol family languages, Modula, FPC, Oberon
- build small simple modular programs
- build large modular programs
- objects when you need them - but not as a religion
- some resemblence to Ruby (poetic and precise) but
- Qomp is not super complex
- Qomp does not encourage a developer to do the same thing a thousand ways, i.e. Ruby
- Qomp implementation is not slow, it is as fast as FPC or Oberon
- Qomp is not influenced by Perl. The "use" keyword is pure coincidence.
- algorithms and data structures minus spaghetti = programs
- nail down a prototype in minutes
- reuse millions of lines of existing code not written in Qomp
- performance without having to write extensions in Cee, but you can link to Cee if you really want
- Qomp compiler compiles itself
- sound type checking
- stack or heap, no religious following of one
- code reads precisely and from left to right
- automated types (reference counted strings, dynamic arrays)
- no need to use pointers to chars, but can when you need to (interfacing to C libs)
- utf8, wide strings for unicode
- low level when we really need it (memory allocation, embed assembly, write an OS)
- no "everything is a" attitude
- discourages overly complex solutions
- vote for simple, but no simpler
- run on BSD, Linux, Windows, Mac OS X, and many more
- considering many innovations in the future: such as a truly relational add in or built in language via Codd, and The Third Manifesto specifications
Interesting Info
While developing Qomp, I noticed a couple of other languages pop up which are strangely similar. One is
Nimrod, a programming
language which can compile itself which was originally written in FPC but later converted to
Nimrod itself.
I'm skeptical if Nim (Nimrod) has got exceptions done right, as errors in programming are an open issue that no one has really solved.
I've also noticed other languages pop up like Go Language which has similarities too. Their error system (instead of exceptions)
is also interesting, as it literally plagiarizes everything
I wrote here,
and implements it into GoLang using just slightly different syntax. But pretty much exactly the same.
Many years ago I developed an online FPC web compiler which was novel at the time, and now I see Go Language
home page allows you to compile/run code through the web browser. They get right to the point and let you start coding immediately.
This I am also a bit skeptical of (a person should learn a programming language before diving right in and experimenting and
obtaining bad habits) but it's most interesting. I do program in GoLang now.
If other languages end up solving the problems Qomp is trying to solve, then there is less need for Qomp. Therefore I am
still researching other languages while developing Qomp further. Specifically I am thinking
about a QompOberon.
Also, Qomp was first called "Qompute" and later shortened to "Qomp". In the case of Nimrod, it was shortened to "Nim". This is
also a strange coincidence, but nothing to be too concerned about ;-)
Example Qomp Code
use
module1, module2, etc;
proc Intro; b Ln('Welcome to Qomp'); e;
func Life: byte;
c ALMOST = 41;
b
res =. ALMOST + 1;
e;
proc Notify;
b
if life = 42 do Ln('Life answer: ', life);
e;
b
Intro;
Notify;
e.
Platforms?
Not specific to a certain CPU or Operating system platform, and current implementation
can run on too many to list. An interpreter and byte code generation
(LLVM) will most likely be available too. The first implementation of Qomp is via
an existing cross platform back end compiler.
When?
Some of the Qomp code was lost due to a corrupted hard drive. This lost code is being rewritten again. The code was
not on SVN or CVS or Github at the time the data was lost. That was the FPC backend. During
creating Qomp with an FPC backend I discovered FPC was very complex with too many compiler
modes, which led to the thought of
QompOberon, a Qomp compiler based on Wirth's Oberon.
That's the direction that GoLang went, and they succeeded.
Implementations Available
Currently Qomp has an implementation powered by the back-end originally crafted by Florian Klampfl and friends.
Qomp however is considering an Oberon compiler due to much higher reliability, and simpler code.
The FPC compiler has been proven buggy and overly complex with way too many compiler modes supported, and feature-itis.
Other implementations are of course possible. Qomp will not limit itself to a specific
product implementation, although the first available compiler and literature will heavily define the
direction of Qomp and Qomp standards.
Head Start
With an FPC backend, Qomp can compile existing source code already written by thousands of other software developers
from the fpc and delphi communities, and can link to Cee code.
On the other hand with an oberon backend,
QompOberon could compile existing Oberon source
code modules which there are many of. However Oberon is not nearly as popular as FPC.
Language Design
Qomp was not thought about via a committee in a month or over a year, or months.
Rather it is a study
for several years ongoing, with community input. The problem with this sort of development
is that it takes longer than say, releasing something like AlgolW, Standard Pascal, or C,
fairly soon, without carefully thinking first.
If Niklaus Wirth had really thought
about Standard Pascal carefully, he wouldn't have made the mistake of getting strings
wrong. In an old Standard Pascal program, strings could be different fixed lengths,
and you had to write a separate procedure for each string of a different length, rather
than having a more generic string. There was also the problem of limits to 255 length
long which today is absurd, since strings can go up to 1GB or more.
Oberon continues to get strings wrong today still yet. Trying to inform Oberon
programmers of this problem, is like pulling teeth, or worse. They are in denial and
are not conscious of the problem. Some are semi-conscious, but not fully.
C offered flexible strings but
cumbersome to use as you had to allocate memory each time you use one, a huge pain in the
rear end. Reference counting was not well known of back in the day when these languages
were released, and garbage collection was to resource intensive and not well researched
enough.
When C or Standard Pascal was released there
was no internet, to get feedback, and you basically stayed at work or home and wrote a
compiler over months and released it. There was very little feedback from others. Then a
book on the language was written after releasing the compiler, and people were just supposed
to accept the book as the ultimate truth about the compiler you released.
Wirth still does this today, without communicating with developers properly. GoLang on the
other hand has learned from history.
With algol you had a big committe filled with politics, ivory tower, and featuritis. The
basic problem with C and Standard Pascal is they didn't get strings right, and no one
really likes the syntax of C or Standard Pascal that much. GoLang solves a lot of this
problem, and languages like Python have tried - but the dynamic typing makes a lot of
people nervous. The advantage of Oberon over GoLang is that it is a true system language
for writing Operating systems, whereas GoLang claims to be a system language when in
fact it's an HTTP and server language.
QompOberon would be a language that people use like Oberon to write operating systems, or
software applications for desktops, without the noisy verbose obnoxious CAPS lock syntax.
Oberon never had a string type, and had ugly kludges like ARRAY OF CHAR which were almost
as bad to work with as C (pointers to chars). QompOberon would have a string, similar to
freepascal's string, or GoLang's string.
The question is what's the point of QompOberon if one already has GoLang and freepascal?
Well GoLang is more for HTTP related software, and with all its features it is quite a bit
more complex than Oberon. Freepascal suffers from complexity with it's million different
compiler modes, and C++ like featuritis. QompOberon would be more like Oberon, but with
some added neccessities like a string. It would not suffer from super complexity. GoLang
is certainly doing a good job at remaining fairly simple, though. There are definitely
overlaps between Oberon, Qomp, FPC, and GoLang. Even Nimrod, Rust, and other languages
overlap in many areas, despite people claiming they are "not competitors".