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.

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".