Qomp Reactions

See QompLanguage and QompItself for information on Qomp.

This page is here because PeopleArgueToFindOut.

Language specific reactions can be refactored into QompLanguageReactions, while general QompItself talk can be kept here... however it may be harder to address Qomp specifically.. so it is up to anyone to use this gigantic page, or modularize it.

Much of this page discusses "context" because the arguers and debaters and the Qomp author are obsessed with "context" and what it offers to humans.

It is hard to tell Who is Saying What and Who is Who in this page. Please fill in your names if your comment was marked with --someone at the end.

Folks were curious how I arrived at the "it's a neat idea" bit, while concurrently holding opposition to the language. Allow me to better clarify my position. --someone

To start with, looking back at my reaction, I was entirely too touchy. I don't know what irked me so, but I agree, my response was concurrently funny as hell, and humiliating. Do I apologize? Nope -- no harm is really done (how can it be when you're dealing with that level of preposterity?). --someone

Moving forward, I did read the wiki page, and I really didn't interpret it as a joke, as someone suggested it was. Moving forward.. is that a BuzzPhrase I hear?

[I don't believe so. I'm fairly certain it was a conversational transition - a segue into a change of topics. The phrase certainly used as a mechanism for marketing appeal.]

It is a "neat idea," in that it directly confronts one of the Algol-family's largest criticisms, that of its verbosity. Making nearly every keyword a single character long definitely drops its verbosity significantly, and definitely results in a language with about as much "visual clutter" as, say C, and arguably even less clutter than C++. Thus, for all you TerseLanguageWeenies, this language is perhaps the best thing since JayLanguage. --someone

I oppose the use of [ and ] for passing parameters, however. On every keyboard I've used so far (warning: AmericanCulturalAssumption), those keys are accessible only by the pinky, which requires a degree of muscular control that most people (myself included) lack, at least without taking more fingers off of the home row. Parentheses, however, require none of that physical effort. Touch-typists know that you access them by depressing the left shift key, while using your right middle and 3rd fingers to type the parentheses. This takes nearly zero effort, except for those with only one hand. --someone

The square brackets can be hit with your middle fingers and other fingers when not touch typing. Removing the fingers off the home row is done to hit the backspace and enter key for me.. and I also remove my hands off the home keys to hit the equal sign, minus sign, square brackets. It gives my fingers a break from all the touch typing. The round brackets require a shift key, no matter whether or not you remove the fingers off the home keys.. and therefore requires strain no matter what. Whereas the square brackets are shift-key less on American keyboards.

Sometimes the shift key does not get depressed due to MembraneKeyboards causing issues.. and then you have to use the backspace to fix your errors. This backspace is in an awkward location and you spend more time repairing your shift key errors. Hence the simpler solution is the key without a shift key in the first place, I think. This being said, the round brackets were going to be used and the square brackets were something that was debatable.

You seem to be of the belief that 'tersity' is a feature worth achieving in a language. Tell me, which is more terse: 'x:int. x=y.' or 'x:int=y'.

Tersity (terseness) everywhere is not good. Tersity some places is good. Would you rather type BEGINTHEFUNCTION or BEGIN. It's not always a linear relationship between tersity being always good and verbosity being always bad.

For the x:int vs x:int=y question... well in Qomp, this is what is offered: 

  pro procedureTest;
  v i: int = 6;     // initialize and declare
  b
    i += 200;    // fiddling with some number
    outln(i);
  e;

Someone mentioned below would not compile in a C compiler: 

  void main(int argc, char *argv[]) {
    int j = 0;


    for(int i = 0; i < 10; i++)
      j++;
  }
This needs to be addressed... the advantage of this syntax in a C++ compiler is that "i" is not declared and this helps programmers significantly enough for it to be a feature? And it is not available in C but is in C++?

Python is just as hard or offers just as many disadvantages to find being and end of code blocks with a search/find in your editor. Using a regex for finding the tabs of begin and end of code blocks is possible, but in Qomp it is even easier than in Python. The claim that b and e kill the language is just as stupid of a claim that = kills the C language or BEGIN and END kill the Oberon language.

I can search for the start of a Python block by typing "?:$" in Vi's command-mode, and I'm sure other editors have a similar search feature. Finding the end obviously is more difficult. However, for someone who has purportedly written millions of lines of code, I find it difficult to believe that he's never once run into 3rd party code where a single function definition has more lines than can fit on a screen. Being able to jump quickly to a scope's beginning is of immense value when maintaining such code. The claim that "noone searches for begin/end in their code" is most naive, to say the least.

Yes, and in qomp one can search for b and e; using a regex too... most IDE's offer a tokenizer anyway, and most code is scanned over visually using the page down key to find begin and end areas of IF logic and CASE statements. If you just search for the next 'begin' and 'end' you could land on the one you didn't want to anyways.. such as a for or while loop curly brace. This dumbfounded rambling about b and e being a problem is due to lack of real world developer experience by the arguers and debaters. The claim that the Qomp author has no real world developer experience is ironically hilarious, as the claims made by the debaters reach an IQ level of about 20 or less.

Which only goes to prove that you have zero experience maintaining large, multi-mega-line code bases written by thousands of engineers over the course of decades. Either that, or your previous professional work involved impeccably pristine code, written by people who obviously weren't human.

If the code was written by engineers and not script kiddies, then it would be pristine code. Even if you work with script kiddies then you should be refactoring that code without "searching for BEGIN and END". Searching for BEGIN and END with your search function has absolutely no sane productive use since it finds the next END which could be the next while loop or the next if logic loop "end". In a large piece of code you can't go to the "end" at the bottom of the procedure, because you'll hit other end's first, in a long block of code. Therefore your logic is flawed, that it is even useful to search for BEGIN and END in a long piece of code.. that takes even longer than using PAGE DOWN since you can't get to the right END that you want to get to, since there are so many wrong ones in the way.

Fancy editors and IDE's support all these cool "developer productivity" tools that we speak of. I rarely use them, and they are over hyped. I do use Code Insight sometimes, but it also gets in my way. What I find most useful is CTRL-SHIFT-DOWN to take me from the interface declaration in a unit down to the implementation section of a function.

As for looking for begin and end's in code, I use my eyes, indentation, and page down to find code. Sometimes the matching feature in my IDE that highlights the next END to match the BEGIN is useful. However I even find all these IDE features and shortcuts annoying since sometimes programmers have to get coding and stop diddling with all the productivity IDE features.

PAGE DOWN (huh, all caps, go figure) and UP are nice, but searching for the beginning of a block is quite a bit faster, and is completely independent of how many lines of code exist in the block. You can keep using your feeble teletype. I choose something more powerful.

But context is everything. The above paragraph doesn't phase me one wit, despite the use of all-capital words. I also wasn't phased with the PAGE DOWN quip either, but since you dislike caps so much, I observed you were hammering on them pretty heavily. In other words, your actions didn't match your publicly stated position. Punctuation also helps immensely. :)

The BEGIN and END and other CAPS LOCK keywords in Oberon are dead and retarded. Qomp has aesthetically pleasing keywords that are easy to type, concise, easy on the eyes. The keywords in Qomp are ones such as b, e, for, skip, do, or, etc.

I personally have no problems reading, nor writing, words in all caps.

[THEN COBOL IS THE LANGUAGE GOING FORWARD (CobolLanguage)]

Moreover, In the Oberon sources I've worked with, high frequencies of longish chains of all-caps keywords seems confined, at best, to type definitions in TYPE blocks. But, that is as it should be, since you write it OnceAndOnlyOnce, and refer to the type synonym everywhere else, which is usually expressed in CamelCaps?. Believe me, you're making a mountain out of an anthill.

It is not just CAPS LOCK that is the problem. One problem (out of many, I could write a book) is that BEGIN is bigger than END and things don't line up as easy when these different sized reserved words are used. Curly braces are matching, since they are one character long.

Paul Graham has some articles about what it takes to make a language fun and useful for hackers (and painters?). One demand from Paul is a language must "line up code". Programmers waste time lining up code. Qomp lines up nice. BEGIN gets in the way of lining up code. Paul Graham could be full of crap, but listen to several hackers and they will tell you the same. Also, FUNCTION is of a different length than PROCEDURE, just as BEGIN is different length than END.

I'm curious to know in what way separating variable declarations from its first use is more convenient than the opposite view? I've coded since I was 4, starting with Z-80 assembly language, going to BASIC, to 6502 assembly, then to 68000 assembly, then to C, then to Pascal, then to C++, then to ... I've coded perhaps in more languages than the years that I have been alive. It is pretty universally believed that high locality of reference isn't just good for computers, it's also great for coders as well. Separating declarations from first uses violates this principle. The longer the procedure, the worse it is for the code maintainer.

That comment about separating declarations from first use was being nicer than in C, was added in a bullet up there by someone who edited this page. I'm curious how this is something to worry about even, since separate variable declarations have advantages too? i.e. can't have it both ways. Or maybe you can. In modern Algol style languages, for convenience, Qomp offers below style initializations: 

  pro procedureTest;
  v i: int = 6;     // initialize and declare
  b
    i += 200;    // some silly number
    outln(i);
  e;

[Why the fsck should it matter what is "better for computers"? That's what optimizers are for. But, absent an optimizer, hand-coding 'locality of reference' is done by ensuring that the memory being referenced is likely to be in the same cache-block as the last piece of memory you went about accessing. By hand. And anyone who codes like that today really ought to find either better ways to spend his or her time, a better programming language, or a more flexible optimizer.]

The discussion was about why languages that can be parsed faster are better for computers... this is not related to optimizers by their known definition. An optimizer is what optimizes the binary program, not the parser. If a language can be parsed faster, this is not reason to make a language. But if the language is readable and it can be parsed faster, and it offers human benefits, there is reason to reap the benefits of a fast parser/compiler with also easy (sensible) readability.

I don't think languages should be designed in a way just so that they can be parsed or compiled fast. However, if they end up being fastly parsed languages and sensibly easy to read with readable syntax such as Algol style, and if it doesn't offer huge disadvantages, and if it even offers some more advantages over slower parsed syntaxes, then it means one has to ask: why not?

The compiler can compile code so fast with Delphi for example that it feels like you are in some rapid scripting environment that supports immediate testing and immediate repairing and immediate prototyping.

Parsing "optimizers" is completely out of context and has nothing to do with what we are talking about. You can optimize a parser, but this has nothing to do with the standard definition of "optimizing compilers", which are compilers that optimize the output program.. i.e. an optimized output of a GCC compiler has nothing to do with parsing speed of the compiler, and this is completely out of context. If you want to take it out of context and start moaning and rambling about how you "can optimize a parser" then go ahead, but that belongs on some other off topic page. You are arguing for the sake of arguing, pulling crap out of hats here, changing the definitions of common terms as you go. 

            pro test;
                pro loop
                v i: int; // local only to loop, not to the rest of "test" procedure
                b
                  for i =. 1 to 5 go outln(i);
                e;
            b
              loop;
              // the loop does not pollute the procedure namespace below, whereas declare 
              // anywhere could have a dangling "i" even if you don't need the "i"
            e;
Probably about the only thing he and I agree on is that dashes do rule; but I'd like to add to that question marks (for clearly indicating predicates) and apostrophies (which satisfies the arithmetic desirability to have primed variables (e.g., x', y') as well as properly expressing ownership (canWindow'sChildrenBeDrawn?))

--SamuelFalvo?

SamuelFalvo? was the first to react in shock and horror to the language. His original reaction follows:

What an incredible waste! It is a neat idea, (and everyone else is left wondering how you came to that conclusion...) but reading the Qomp website, he makes several seriously flawed arguments, besides outright insulting the reader:

I could go on and on. However, I won't waste my time. The executive summary is as follows:

Oh well. You can't please everybody. Fortunately, Qomp will never amount to anything. Not that I dislike the idea, just that I dislike the self-righteous attitude of its author.

--SamuelFalvo?

Hot damn, you got riled up over nothin'. Even Top has more substance to his arguments than you're responding to here. And, yes, Qomp will amount to nothing, just like every other language that lacks a clear agenda or purpose.

My response has about the same amount of substance to the claims made on the Qomp website. --SamuelFalvo?

I won't disagree. But I can't tell whether your immediate statement is a defensive riposte or a claim of humility. If you misinterpreted my statement above, and mistakenly took the it as an insult, note that 'than you're responding to here' references the amount of substance on the Qomp website and not your own reply. Pardon my rather archaic English.

I think this could be an elaborate troll. Consider this I found on their Google Groups page: 

  When doing subtraction in Qomp programming language, use the letter
  "m". The "m" is the minus operator.


  An example of the minus operator in use:


  if 5 m 4 == 1 do outln['yes five minus for is one'];
  if 5 m 5 == 7 do outln['five minus five is not seven'];
It's almost as funny as ProgFont.

--NickBensema

Wow, that is particularly bad. I really hope that I just got suckered. Because then I can look back on this and laugh about it. But the webpage I read gave zero indication, zero hints, that it was in any way a joke. -- SamuelFalvo?

I seriously doubt it's a joke. The use of 'm' might very well be the case, Nick... because-he-allows-dashes-in-identifiers, the author of Qomp might have done some hemorrhaging over how to get subtraction into his language. So, he uses 'm', then calls it a feature because he's not asking you to type 'minus' or 'MINUS'.

I'm on this page because Samuel's ranting amused me. Anyhow, you speak of context. Why did you not choose to handle '-' in context? it isn't even a shift-stretch. And you do have a lot of balls, believing you've the power to make people 'get used' to anything; your language will be fighting for acceptance with its unconventional syntax, and its lack of any clear features or greater expressive power will kill it the rest of the way.

Oh? What features does Qomp have to support communications, distributed computations, and parsing? And, honestly, if you're going to screw with the spelling, you at least ought to coin it the 'Qompiler'.

Oooh, I got a kick out of this comment on his rant-over-ruby page (http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Is-Ruby-457-Ways-To-Do-The-Same-Thing): 

 Defying the laws of Logic


      x = "(some fallback value)" if x.nil?


 What? Now we are adding IF LOGIC after the statement has already occurred? 
 Just for the sake of being cool and hip, yee haw! Yee haw! That's cool, I'm 
 gonna use ruby 'cause it has all these useless feature's n'stuff, and, like, 
 it's so cool, like so much clearer and bass ackwards man.
"... after the statement has already occurred?" Heh. Perhaps that helps you get into the mind of this 'L505' author. 

 If I go to the store, then I buy apples.  
 I buy apples, if I go to the store. 
 ? apples ? if I, buy? when I go to the ? store?
It is a gimmick. RTFWAA (Read The Fine Wiki Article Again). Gimmick, it is. Article read again, the wiki you should.

"after the statement has already occurred" is still in dreadful error. At what time does a person like you - who is writting a compiler, no less - believe the statement 'occurs'? And I'm a firm believe that languages should be flexible and extensible enough to simultaneously: (a) fit the problem, (b) fit the user, and (c) allow your program to be expressed almost like pseudocode. These, as goals, are hardly gimmicky... and are a far better deal than your "you'll get used to m" policy. Now, Ruby doesn't always succeed at this either, though it has had some successes (RubyOnRails and SQL handling). The ability to express a concept in many ways is necessary to support goals (b) and (c).

"After the statement has already occurred" is sarcastic of what a programmer sees the code as, on paper.

As a person concerned with the design of a written language, you should be at least nominally aware that sarcasm is transmitted primarily by tone of voice and posture. s Perhaps you should add some scoping rules... mayhap s and es for informing your readers of those moments you wish to be sarcastic es. Anyhow, are you truly claiming that you should be the one to dictate how programmers think? s Wow. You're so amazing es.

"Perhaps that helps you get into the mind of this 'L505' author."

Speaking of getting into his mind (ew!), I like this one: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Sexual-Coding

Some samples:

Ah. It all makes sense now.

People with no sense of humor will never understand Aleister Crowley. Glad you found the information on Magick and Knew Magick.

Popular trendy languages usually have a singular, vibrant personality behind them, that has shaped the personality of the language. Perl has lwall, Python has Guido, and Ruby has Matz. And so Qomp has a MopAdvocate, and as expected, the language seems to match the personality behind it.

LOL. A language with ego?

Absolutely.. having an Ego is essential in the True One Purpose and Great Work.

Does your language have any significant features?

Just like C, Oberon, or Assembly, it is a fairly simple language without too much focus on "features". Although it has them. Most importantly are wrappers, also known as modules and libraries. All general purpose languages like this are said to be turing complete. The syntax and libraries available is all that matters.

TuringComplete is a minimal baseline for general purpose languages, and is only about mathematical equivalence (not touching on safety, speed and space and resource costs, communications, etc.). Syntax is not all that matters: see ExpressivePower, KeyLanguageFeatures, BlubParadox, GreenspunsTenthRuleOfProgramming, AreDesignPatternsMissingLanguageFeatures, FutureOfProgrammingLanguages. What matters is the ability to directly and meaningfully express intent without implementing 90% of some other general purpose programming language inside your own.

Much of the rambling and moaning was refactored because the complaints were going on and on about things that Qomp already has.

[You seem to be of the mistaken opinion that "refactoring" means "delete any dissenting opinions, then offer a bunch of disingenuous marketing buzz, fallacy, and ad-hominems in its place".]

For example:

FebruaryZeroEight

CategoryProgrammingLanguage

EditText of this page (last edited July 9, 2010) or FindPage with title or text search