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.'' * I humorously use CAPS LOCK throughout this page to show you how much it gets on your nerves. See how even though I just inserted it ONCE, you got annoyed at my PAGE DOWN? That is why NOT JUST LONG STREAMS of CAPS LOCK are annoying, but also little SHORT BURSTS of them TOO. As seen in OberonLanguage/ComponentPascal. ''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)] * I DISAGREE. I WOULD HAVE TO SAY THAT ForthLanguage IS THE LANGUAGE GOING FORWARD. ACCORDING TO ANSI STANDARDS, FORTH'S CORE WORDS ARE UPPERCASE, TO FACILITATE CASE-SENSITIVE IMPLEMENTATIONS OF THE LANGUAGE CODE COMPATIBILITY WITH OLDER SOURCE CODE FILES/BLOCKS, BUT RECENT VERSIONS ARE CaseInsensitive and CasePreserving. --SamuelFalvo 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. * [I agree that we shouldn't design languages to parse or compile fast; we should design them, rather, to readily reflect programmer intent in a manner that is as clear and straightforward as possible for the problem at hand. But contrary to another of your claims: parsing speed CAN be optimized with an optimizer. Optimizing an LL(K) or LALR parse-grammar is exactly the task performed by tools like YACC and its many cousins. Further, the edit-compile-test cycle compilation speed can be massively optimized by some rather simple search-optimization techniques that take advantage of the fact that very little changes during the edits. As far as oberon and pascal being 'easy to read', I must ask: 'relative to what?' In my experience, the languages that are 'easiest' to read are those that are designed to handle ambiguity in an intuitive manner rather than those that force you to inject all sorts of extra notation to avoid ambiguity - i.e. languages that traditionally allow for backtracking.] ** out of context, you are talking about optimizing a parser which has nothing to do with what was being discussed. Freepascal does not use YACC or any GCC back end nor does Delphi and it is extremely fast compared to the GCC or Visual C compilers. Optimizing a YACC compiler.. go ahead, but this has nothing to do with what the context of this parsing discussion was about.. which was about the speed of compiling a language that is readable, versus the slowness of a language that seems equally or less readable. ** [That was in-context when it was written. It isn't my fault that he felt the sudden need to delete all his intervening comments in a discourse involving parse speeds and choosing a syntax/grammar for parse-speed vs. for programmer convenience and readability.] *** The discussion was about the speeds of languages compiling, and the fact that languages are still readable even if they are fast to compile. Compilers that optimize are compilers that optimize the output binary. What is out of context was your twisting of words, claiming that a compiler that optimizes could be a compiler that has an optimized parser. That is out of context and was made up. *** [Damn you're dense at times. Optimizing the output wasn't ever part of the context. Parsing was. I was, indeed, talking about optimizing the parse speed. And no, it is not "made up". You claimed like some ignorant newbie that parsing can't be optimized, but it can be - it just takes a parser optimizer.] **** The definition of an optimizer, and what programmers know as an optimizer, is this: "Compiler optimization is the process of tuning the output of a compiler to minimize or maximize some attribute of an executable program." http://en.wikipedia.org/wiki/Compiler_optimization **** [So, by what you're telling me, you honestly believe at least ONE of the following statements: (1) a compiler is not an executable program. (2) parsing speed is not an attribute of a compiler. Which one is it?] ***** Aha, and you said "optimizing the output wasn't ever part of the context", and now you are saying optimizing the output of the compiler executable is part of the context. Hmm. Interesting that you are twisting it to your way again. ***** [Optimizing the parser has been the whole context the whole time, Mr. Olson. It is you who has been attempting to dodge the issue by claiming "but, but, but... you CAN'T optimize a parser!". Now you're attempting to dodge again. You really deserve less respect than I'm giving you, which isn't much.] ***** Parsing is a complex task and one way is to use stack variables instead of heap for speed. No optimizer can magically turn all your heap variables to stack variables, and human intervention is "the optimizer" in parsing and compilers. Some optimizers even slow things down on new hardware, and would be detrimental. An example is when putting certain command line options on with GCC and FPC to speed up the program, only to find out that the options which made the code smaller, made the code faster than the fast options. Not just compilation speed, but linking speed is a biggie too. In fact optimizing the compiler may be a waste of time if the linker is three times as slow to link the executable. ***** [Complex tasks are the best targets for optimization, Mr. Olson. And parsers, being a complex task with distinguishable properties of which advantage can easily be taken, tend to have dedicated optimizers. Your ignorance of the tools available to you in this field is staggering. And yes, I did mention that other components take time: parsing, compiling, typechecking, linking, testing. It was part of the reason I said that having a 'fast parser' isn't really worth it if the expense is 'poor readability or less programmer ability to directly express intent'.] ****** Really, then why is it that the fastest compilers in the world, Delphi, Freepascal, are all hand optimized by humans in a non automated manner? Which is not the definition of an optimizer.. which is my point that in conversation when one speaks of an optimizer, we speak generally not of human optimizers... And the C compilers have never been optimized to be faster than Pascal style ones, so the optimizer you speak of, why isn't it in use to make GCC faster or close to as fast as the FPC and Delphi compilers? Maybe because optimizers are not so much used for parsing as you think, since parsers are a hand craft.. even generic parsers like YACC have to be optimized at their lowest denominator, which most likely involves making YACC use more stack and less heap, and hand optimizing many routines. ****** [I wasn't talking about hand-optimization. And the fastest compilers in the world are for languages expressed with simplistic grammars - BrainfuckLanguage, ForthLanguage, LispLanguage - which, being less complex, benefit less from automated optimization (because, when dealing with low complexity, humans tend to 'see' more than do human-written automotons, if only because we are unable to encode all our domain knowledge into them). And C is a more difficult language to parse than is Free Pascal - it has reduce/reduce ambiguities. That doesn't mean the parsers haven't been optimized. Your current line of logic seems to be: "if it isn't the fastest in the world, it wasn't optimized". Hate to point it out, but your logic is seriously fallacious.] **i.e. there is no advantage of changing a language to have first use declarations when Algol languages today already have initialized variable syntax.. along with the other advantages in separating variable declarations from first use. This is a page about Qomp, and not about your perfect LanguageOfTheFuture. I suggest a lot of your rambling about "what could be" and "if only declarations could be on first use" and "but this feature doesn't offer any real advantages and is good because" be moved to a page like LanguageOfTheFuture. ** [Complaints about Qomp are about Qomp, not about the perfect LanguageOfTheFuture.] *** [If you are an expert and hand-writing and hand-optimizing parsers, or if the language you're parsing is particularly simplistic, you ''might'' be able to do better than YACC.] *** [I've not argued for declare-anywhere variables in your language, nor any of the other arguments you're attributing to me. But if you inferred that my argument implies a preference for declare-anywhere variables ''because'' they more directly express programmer intent, then you've already made a proper case for them.] **** People haveve written confusing phrases on this page which Google brings zero results for. Phrases such as "first use definitions" are not technical terms according to Google or any other website. **** [What SamuelFalvo meant by "first use definitions" is the ability to declare a variable at the site where it is to be first utilized. A canonical example would be the 'C' for(int i = 0; i < n; ++i) loop - an example that SamuelFalvo did, in fact, provide for you. In its most general form, one could apply them most anywhere - e.g. (0 < (int x = expr)) && (x < 10). The advantage is keeping things highly localized in the source. The disadvantage is determining the proper scope for the maintenance of 'x'.] ***** I started asking why Declare Anywhere syntax was beneficial and then someone flamed me for saying that "I did not understand, that first use declare syntax was not what DeclareAnywhere meant." Now we are saying that we can declare integers anywhere you like such as the beginning of a loop.. and that this is the definition of first use definition/declaration. Contradicting and confusing. ***** [Not "first use '''before''' declaration". You are the source of your own confusion, you don't even read what is written.] ****** ''The variable is used before you declare it, and hence my humorous play on words (good, now I've confused you.. mission accomplished). When you use an "i" variable in a loop, you are using it before declaring it.. hence "first use before declaration". When you enter the loop and start using the "i" variable as an integer of some form, you finally have now declared what the integer is, if it is even an integer. Also, the zero in the loop is declared after the "i" since the zero comes after the equal sign. Therefore "first use before declaration" is a humorous attack and flame on the C++ language'' ****** [Let me look again: for('''int i''' = 0; i < n; ++i) -- hmmm... the declaration. Let's look for the first use: for(int '''i = 0'''; i < n; ++i) - Wow! It is AFTER the declaration! or maybe even AT THE SAME PLACE! I think that would be "first use declaration", not "first use '''before''' declaration". Who'd've thunk it! My gosh, if I was going by what he told me, I'd have been dreadfully confused, wouldn't I? I'll have to remind myself to check carefully when he says things because he is often confused. He sounds soooo sure of himself, though. Poo.] ***** keeping things highly localized in the source is also a benefit of nesting procedures, which many people hate who are the same ones that love the declare anywhere variables. Not saying you two lovebirds are these people, I am just making a point that at least one of you will agree with partly (or disagree with). However, whoever it is who agrees or disagrees I will not know.. because the two love birds (or four) may not sign names. WikisSuck. ***** [Actually, I quite like nested procedures, so long as they possess static scoping and clear semantics for returning such a subprocedure from a procedure (UpFunArg). When they are done wrong, though, I could hate them. One can have both nested procedures and declare on first use variables.] ****** A nested procedure can eliminate the need for "declare on first use" or "use before first declare" variables. Consider that the supposed advantages of declare on first use variables was local scope.. but a nested procedure offers even more locality. '''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'''; ****** [I'd want declare-on-first-use nested procedures.] * Computers parse languages that are not like C much faster than languages that are like C. ** Absolutely no argument here; that keywords to direct the parser ''always'' preceeds the content of interest allows for single-pass LL parsing, even home-grown, that is lightning quick. OberonLanguage was, bar none, the second fastest compiler I've ever used, the first being Forth (which, really, doesn't even parse; it just lexes). ** [While fast parsing is a nice property for a language, using it in an argument implies that it is your intent to make things easier on the ''computer'' rather than for the ''programmer''. Even 'slow' parsed languages ''parse'' fast enough. In a ''statically typed'' or ''optimized'' language, especially, it is often a minority of the cost. If you have unit-tests as part of an edit-compile-test cycle, even those will generally cost more than the parse.] ** [That's fine. I didn't argue that fast parsing for a computer is good for humans.] ** [If it is faster and more readable AND '''just as expressively powerful''', then you could call it a 'WinWin'. C++, however, is a great deal more expressively powerful than pascal or oberon. You do need to be a TemplateMetaprogramming guru to take advantage of it, unfortunately, and I'll agree that C++ is far more verbose than is necessary (especially when it comes to functional support, use of small classes, etc.). But unless you can match the expressiveness of C++'s TemplateMetaprogramming with ModernPascal or OberonLanguage, you don't have a leg to stand on when claiming that you've a 'WinWin' situation.] * For humans, keep the procedures short, so that you can see the variable declarations. For those times when you have really long procedures, split them into smaller procedures, sub procedures, case statements. When you cannot see the variable declarations, maybe your procedure has gotten far too long and it is a ''warning sign''. ** Positively agreed, except that I don't always control the code I'd like to refactor. However, for my own stuff, and for the stuff my company produces, I'm doing precisely this. * Even Object Oriented design uses small methods when designed well. ** Yup, I largely agree with this. The only disagreement is that I find declare-on-first-use to be more ''convenient'', and the kinds of things you'd use it for are private, implementation-specific things that would never appear in a contract anyway. It is definitely a feature I miss. I'd like to further emphasize that your recommendations are true for classes as well; when working for a well-known search engine company, we had classes that were, albeit "well factored" from a functional point of view, not at all well factored from a code maintenance point of view. They were huge, and interleaving methods with object state became a necessity for ease of maintenance. Perhaps this isn't what you're referring to, but it is nonetheless related. 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'': * Python is just a wrapper around C? OK, so modern Python compilers are coded in C (and Java, for Jython), but the ''language'', which the author himself claims is nothing more than syntax and typing, has ''absolutely zero'' to do with C, and in fact, seems to be as opposed to C norms as you can get. Also, what's to prevent me from coding a Python runtime environment in raw assembly? What does that make Python then? * The use of 'b' and 'e' will be ''positively, 100%, absolutely, unquestionably '''disastrous''' '' for the language. Searching for 'b' to find the start of a block will fail whenever your search lands on a variable like, "bankAccout", or "contributedFunds" or some such. ** ''Actually, no. A reasonable parser can define keywords that are clearly distinguished -- using context, and/or surrounding whitespace or tokens -- from identifiers, function names, etc., even if they contain or start with the keyword. E.g., C easily supports variable or function names like ifSpleen, switchwoggle, whilefish, etc.'' ** Actually, yes; you're refuting an argument I never made. Load up a Qomp program in Vim or Emacs. Or any editor for that matter. Place your cursor on any b or e statement. Now do a search for the next 'b' or 'e' element. Or, search for its compliment. Either way, you're search will hit any and every intervening symbol that has the letters 'b' and 'e' in it. --SamuelFalvo *** ''Muy bad. For some reason, I thought you were referring to a general ambiguity between the block indicators and identifiers and function names, which would affect parsing as well as manually searching the source code. I guess it was the "'''disastrous''' for the language" phrase that threw me; this problem is actually disastrous (relatively speaking) for the language ''user''...'' ** [A good, refactoring browser would be able to find beginnings and ends of blocks and would allow structural searches. Training my eyes might take a little while, though - after considerable exposure to the normal symbology derived from parentheses and ALGOL, curly braces seem quite natural compared to 'b' and 'e'.] * The Algol-derived syntax prevents instantiating variables where they are first used. This is ''incredibly'' convenient, and I miss this when coding in C. * Most symbols he abbreviates saves only one, maybe two, characters per keyboard. '''e''' versus e'''nd'''. '''els''' versus '''else'''. And, yet, he has the ''raw nerve'' to tell the reader of his webpage to "get real." Get real? Sorry, sir, but you need an ''abject lesson in cold, hard reality.'' * Vehement opposition of the use of ALL CAPITALS for language keywords. ''Give me a break!'' I love the people who _____ and moan about how hard their life is because of the placement of the CapsLock key, claiming that, "Screw this, it has no use! None! So why is it here?!", and yet they turn around and _____ and moan ''even more'' when presented with a language that actually uses the dang thing. Get real indeed. I could go on and on. However, I won't waste my time. The executive summary is as follows: * The use of shorter syntax for shutting up the "pro-terse" contigient of the C-derived language group is innovative, but ultimately useless. * The bemoaning and crybaby tactics about the capital keywords is annoying; he repeats himself several times on the website, without providing ''a lick'' of factual data to support his opposition to them (it's OK to have an opinion, but to claim that they are ''the reason'' for the failure of a language is positively absurd without hard, factual data). Yet, these are the same folk who are all pride-n-joy when it comes to their favorite syntax-highlighting IDE. Yeah, let's use colors instead of caps to highlight the syntax. (Note: AmigaBasic allowed you to type in a program in all lower-case letters, and it will "syntax highlight" by capitalizing keywords ''for you'', so please don't tell me that syntax-highlighting IDEs are better because they're "automatic.") '''That being said,''' I also enjoy lower-case keywords. If given the opportunity to use them, I will. But, if a language uses capital keywords, well, to paraphrase the plaque in my aikido dojo, JustShutUpAndCode. * Lack of first-use-definitions for variables is a really big negative in my book. ** This is still confusing, as google brings up nothing about the phrase "first use definitions". It is possible that you mean declaring variables clearly is a bad thing and that one should mix declaring his variables with his code. I have no idea. 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'.'' * Modules, not features. ------ ''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.''' * It was written very clearly with a humorous sarcastic tone. Oh, my, ruby, such a cool bass ackwards language. So hard to tell. So hard to tell. ---- "''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: * "By magickally transferring all energies into the guitar and discovering that the guitar is not a guitar, but rather a human.. we can make greater progress in our works." * "For a compiler is only pregnant with programs, and touching your keyboard with one hundred percent orgasmic focus will produce better babies." * "There are of course always risks in Magick, such as becoming even dangerously less social, becoming a lunatic (been there, experiencing that, etc.)." 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, KeyLanguageFeature''''''s, 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: * Qomp already has unicode string support, not just ansistrings. The moaning about "You are Behind Times and Qomp doesn't even have unicode blah blah blah" was hilarious though ** [Watching you promote your 'ansi string' support as some sort of great feature was quite amusing.] *** A compiler that creates executables and libraries with low footprint that is as fast or near as fast as GCC with ansistring abilities, is indeed a promotion. Not many other LowLevelHighLevel compilers come close, other than D language, Oberon. Popular scripting languages, do have strings, but not so many Low Level languages (i.e., take for example ones which can write an OS). Even C++ doesn't have a built in string and uses classes (which, some find inelegant). So, Qomp can promote features which are in some ways more elegant than say C++ or C. *** As for pointer to chars being a feature: it is a feature since many languages don't have this feature, believe it or not - it helps greatly when interfacing with C libraries directly (without going through loop holes). *** [Keep telling yourself that. You deleted the "garbage criticism" because you couldn't respond to it appropriately. And now you're claiming "YouJustDontGetIt" with "Hard for the arguers and debaters [and moaners and ramblers] to understand why? Absolutely". Disagreement doesn't mean a lack of understanding. And low-level languages don't need explicit access to pointers any more than they need direct access to Assembler - it's a shortcut, but one with significant disadvantages. You cannot have strong type-safety, or perform certain optimizations, in the presence of pointer arithmetic. You go on and on about strong typing in other locations. One use of char pointers, and it becomes extremely difficult to justify a claim of 'strong typing'. You've made statements to the effect that WeakTypesLie, correct? Has Qomp been lying to you about its char pointers?] **** Actually a lot of it still is garbage and should be deleted soon **** Pointers to chars are available in safe languages such as Oberon too. They are handy for interfacing into other C libraries. They can be wrapped into much safer modules, while making use of existing infrastructure. This also has nothing to do with WeakTypesLie, since one strongly declares a PChar. ''[Which immediately creates a TypeSafety loophole. See StronglyTypedWithoutLoopholes.]'' Ruby is unsafe whenever it uses C libraries since the C libraries can do wrong things too. Python is the same. This is a straw man argument. Making use of existing infrastructure in Qomp, and wrapping it into safer modules is a huge benefit. So by allowing pointers to chars only for people who need them (just as Oberon and other known safe languages offers them), this is a feature. If you cannot see this as a feature, I suggest you look at PHP and ask yourself.. why can't I use PHP to call DLL's directly without going into loop holes first? Why can't all the Ada compilers create DLL's that are compatible with C since the compiler doesn't support DLL's yet? ***** [That would be because (1) Ada truly is a safe language, whereas Oberon is not. (2) PHP is not a LowLevelLanguage.] ****** Ruby and Python can interface to C easily. Qomp makes it easier. PHP can't, not just because it is not a LowLevelLanguage. Python and Ruby have less trouble interfacing. In PHP one can write extensions, but they are much harder than in Ruby or Python is what I've heard. ****** Ada attempts to be a truly safe language, but it still interfaces into C libraries if one wants, therefore nothing is truly safe. Oberon by default is safe, unless you use the SYSTEM (in caps lock I think) module. I.e. the default safety of a language is nice. The ability to escape this default safety is one of the critcisms Brian K. made about Standard Pascal, and Qomp is able to escape. * Qomp has plenty of features, but programmers focus way too much of their time on Cool Features ** [Frankly, 'features' are the only reason programmers might be motivated to switch to your language from the language with which they are already comfortable. Even if you are of the opinion that programmers focus too much of their time on features, you're not going to change their nature. Features answer, to the inquisitive programmer: Why the ebbin' keck should I care about Qomp?] * Qomp is not Perl or Ruby and does not intend to focus on Cool Features at all, even though it has neat features ** [So, from the above two, I can surmise that Qomp has lots of things ''you'' happen to believe worthy of the term 'feature', but that I'd dismiss as dated or perhaps as an anti-feature, and that your language lacks much more expressive capability than other languages like free pascal (which already has lots of programmers and documentation).] *** This "expressive" capability is vague. Ruby and Perl are expressive, C is expressive, Algol is expressive. It is all relative. Qomp is expressive like C and D and Algol because it is more like these languages. It combines the advantages of Algol, C, D, C++ without the need to put up with C or C++, and without the need to put up with Big Algol language or big Ada Language. Since expressive capability is relative, can you please describe what exact expressive capability it is that is so needed in todays languages, if people are already happy with C/D/Java/Algol/Ruby style syntax? What people are not happy about is that C is hard to use strings with and is too low level, Ruby is slow, Java is slower at times with no native compilation, D is the same syntax as C++ and doesn't even compile C++ code since it is incompatible... And Qomp? Oh.. it is not faster than Ruby, it is not more concise syntax than Algol or Ada, it does not use existing modules, it is harder to use than C and Assembly, it is expressive like languages that everyone already likes so this means no one will like it's expressive qualities since everyone likes its expressive qualities, and since '''everyone already knows Qomp''', no one will find it easy to know and learn. **** [You've been directed to pages like ExpressivePower and BlubParadox, and I've even extended HighLevelLowLevelLanguage,so you should be capable of learning what 'expressive capability' means. The word isn't 'vague' so much as your brain lacks a 'clear' understanding of the subject. All things seem 'fuzzy' when you're looking at them through bad eyes.] ***** The phrase "expressive power" is a marketing BuzzPhrase. Lisp is so expressive that you can create unreadable programs in it with your own mini languages inside Lisp. That's why '''lisp is used by almost everyone today''', because of its '''expressive power'''. It takes expressive power to make a language really useful, especially the so popular Lisp language. It also takes expressive power to make a language clearly structured and easily readable. I should become the sarcastic marketing department leader. ***** [The phrase "expressive power" has a mathematically measurable property based in strong and weak equivalency. But, yes, it IS good for your language's marketability if it is more expressively powerful than others. That's why '''lisp is still used today''', despite bing far older than any other language in common use, lacking a variety of modern features, being a bit awkward to utilize for device-drivers, and having a syntax with all the variety of oatmeal. And your sarcasm is so wonderful, I'm sure you could make all sorts of money; go for it.] ***All the documentation is already here for Qomp, since the existing FPC docs apply to Qomp (only more Qomp specific features need docs). ****["(only more Qomp specific features need docs)": from which one must make the logical conclusion: NOT "all the documentation is already here for Qomp". You contradict yourself.] ***** Wow, and not all the documentation for Java is available. Damn. Can't use Java. Not all the documentation for the Windows API is available. Damn, can't use Windows XP. Throw it out. People already know Qomp, and documenting the extra Qomp features takes less time than documenting a brand new spanking language that makes use of no existing infrastructure, no existing libraries. As I said, you are here to argue for the sake of arguing. If you don't like Qomp, I wish you would not show any interest in it and ignore this page. But it seems you are obviously in love with Qomp and wish to continue to find out more about it. That's nice, I like that. ****** [Your attempt to be sarcastic in this instance won't earn you any Emmys. And I already told you I'm here for the sake of arguing. About once a month, I need a fix of arguing on the Internet. It's addictive.] *** The libraries are what needs to be documented. They already are. Oops. Darn. All freepascal modules (binary or source) work with Qomp, all freepascal modules that are documented are also documented for Qomp, since all people know QompLanguage already, without even knowing Qomp. How is that possible? Because Qomp is not new. Everyone knows Qomp. Algol, C, freepascal, D.. these people already know QompLanguage. They may not know QompCommunity, but they know QompLanguage. Getting to know the community is not hard. * Qomp is for modular programmers, not "features are cool" programmers. Use Perl or Ruby instead if looking for features, please. ** [Many languages support modular programming ''and'' have cool features. Erlang, for example. What do you say to your competition? *holds the microphone up*] *** As I already stated, Qomp has cool features and supports modular programming, so what is your point? Erlang for one, Qomp for the other. Pick the language you want. *** I do not think cool features are as important as other things, such as modular programming, even if the language has both. Ruby has and other languages with cool features have '''modular programming also''', as if it is an aside. With some languages, the authors and websites do not even make a big deal about modular programming even if it is available, since they are '''so focused on cool features and OOP purism'''. Qomp, on the other hand, will make a big deal about modular programming, community, infrastructure, reuse (not through OOP hype), no matter if it has cool feature or not. They (the other languages) make a big deal out of the gimmicks and OOP fallacies. Qomp will declare laws such as "reuse is possible not just through OOP like the other purist languages can imply". *** And if Erlang is cool and Python is cool and Qomp is cool, does that make it bad? Nope. Use whatever you wish. * Qomp is able to use existing modules (units) from FPC ** [Your compiler is able to do so. Will you commit to maintaining that ability as part of the Qomp standard (when you get around to writing one)?] * Qomp can link to GCC object files, and can create GCC compatible object files * Qomp is able to create DLL/DSO compatible with GCC DLL/DSO * Qomp is able to import GCC based DLL/DSO * there is nothing one can do in Qomp which cannot be done in C, but in Qomp it is much much much easier (minus two (too) much's). ** [That is a bold claim, Mr. Olson. DemandForEvidence.] ** It is not a bold claim. ** [Oh, then what does "much much much easier" mean to you? Perhaps the same thing as "slightly easier, some of the time"? To me it means: "much^3 easier", which means I should be able to get coding done "much^3" faster, or perhaps "much faster" with "much^2" fewer shipped errors. Now how much faster is "much faster" (or "much" fewer bugs)? Well, 5% isn't much faster. I'd perhaps say that 15% is significantly faster. So, perhaps 20% can be called "much" faster. If so, then "much^3" faster means: get it done in half the time. And that's a bold claim.] *** The pointer to Char issue kills the C language for modern prototype programming. Language that doesn't require using pointers to chars is much easier to use than C. Using pointers to chars bloats the code up with verbose MemAlloc clutter along with plenty of security risks and bugs. This is not the only thing that makes almost any modern language easier to use than C... there are many more reasons. If I described it here in these bullets, I think it will need a new page like WhyQompIsEasierThanCee or similar. The fact that Python and Ruby are easier to use than Cee is nice too. But Qomp is not a scripting language, it is a language like C and D, but easier to use. The "much factor" depends on your hatred toward C. ** Almost any language today, such as Ruby, Python, etc. are easier to use than C. Qomp is a low level language like D language or C++ language, but it is not C++ and it is not D. That is the best comparison I can give. Please go on the D language page and the C++ language page and ask what features does C++ have that Ruby and Python doesn't have? Then you will understand.. what features does Qomp have that C++ doesn't have? None. Sorry. This isn't about features. One "feature", if you like to call it, is to reuse thousands of libraries that already exist. Apparently people's reaction to this was that Qomp is useless because it makes use of existing code and that is bad because "it is not a revolution" since it reuses existing old code and "doesn't use brand new incompatible code" which it should. ** [Using existing modules isn't 'bad', but it isn't something that will have other people using your language, either. Even DeeLanguage hasn't become successful, and it does offer many advantages over CeePlusPlus wrgt. management of arrays and memory and various syntactic cruft.] *** DeeLanguage cannot use existing modules or C files, it is incompatible. It can use DLL's and DSO's, but nearly every real compiled language can. Qomp is not after popularity anyway. SawzallLanguage like I said is not popular, and is used by a small community. Qomp is more general purpose than SawzallLanguage though. As for using existing modules not having other people use your language? LibC and the Unix API is a module that people use over and over again, only because it is modular. Not because it is revolutionary. Unix is old spartan modular API's that people use. A new language requires a jump start. Either one codes all the stuff himself and reinvents what all other infrastructures are doing, or he makes use of them and adds on to them. * Qomp is not revolutionary, it is evolutionary. Revolutions are violent. Evolutions are successful. ** [Now this statement is exactly what the phrase "insubstantial marketing buzz" was strung together for.] ** No, an evolution is Algol to Oberon. There is nothing wrong with describing for example C++ evolving from C. ** [Heh. "Revolutions are violent. Evolutions are successful." Wrong on both counts. But it does make good "insubstantial marketing buzz". There is nothing wrong with describing C++ evolving from C, but there is something wrong in assuming you've got some sort of winner here with Qomp simply because it is making small strides, and there is something wrong with implying that Revolutions can't be just as successful.] *** All revolutions might just be gigantic evolutions. *** [And all pigs might just fly.] **** In a computer game, pigs can fly. Programming is Magickal, where one can demand and order the computer to perform any Magick he wishes. **** [Not all pigs are in computer games. And programming is not 'Magickal' - not even if you could get your computer to write poetry and plays and compositions matching the great artists of yore, which, at the moment, you cannot.] ***** ''Programming is Magickal if you had studied that Magick is not Magic. Magick is different than Magic, see wikipedia for details. Your description of Magick implies Magic, not Magick.'' ***** [Of course. You can do 'Banishing' with your program. http://en.wikipedia.org/wiki/Magick#Banishing *turns to the men in white coats* Take him!] ****** In Knew Magick, the Backteria are removed and Kastrated from the program. * the moaning and rambling about Qomp being No Good because it Uses Existing Infrastructure and it being No Good because it is able to reuse existing modules (thousands if not tens of thousands) was ridiculous, and was refactored ** [I won't deny it's a feature of the compiler. But I'm still unconvinced it is a feature of Qomp - the language.] ** This is where you do not understand Qomp. Qomp is not a language. It is a compiler, a scripting system in the future, it is a language, it is a community, it is modules. It is not a ''just'' a language. UCSD Pascal was an entire operating system. Small talk is an entire environment. Don't think on a language level, think on an infrastructure level. Unix and Windows were the infrastructure for C. ** [So, if you traded out your compiler, you'd have to stop calling it 'Qomp' (or at least change the version number)? Anyhow, you can liken 'Qomp' to a Linux distribution, if you wish. But you ought to keep in mind that this page ''is'' over QompLanguage, not Q''''''ompTheOperatingSystem or Q''''''ompTheFramework or Q''''''ompTheCommunity.] *** It is called QompItself now, because it is not just a community, nor a framework. It is Qomp itself. Words do not describe Qomp. Qomp is itself. *** [Disagree. As the author, you only get to name the system 'Qomp' and attach a language. After that, everyone else certainly is free to use words to describe Qomp and its components, like QompLanguage. And, believe me, we've found words to describe it. For example, 'terse', and 'possibly a bad joke'.] **** The C language was a bad joke. This page has grown outrageously large. It seems to be doing quite well. Qomp is doing quite well so far. Remember, bad publicity is good publicity. * the moaning and rambling about Qomp not having benchmarks is ludicrous since the computer shootout already has the benchmarks for freepascal, and Qomp uses the same optimizer and backend as freepascal, with freepascal already beating GCC in memory footprint and coming close or equal in CPU time * the moaning and rambling was all a bunch of unstudied guesses and/or assumptions instead of valid polite questions * the tone of writing and voice of the arguing folks shows signs of either jealousy that Qomp has so much existing infrastructure (since that is a bad thing and it should not use any old code at all and should use completely different paradigms), or it shows simple outright dumbfoundedness and therefore was refactored ** [The "moaning" seems to be in your head alone - nobody on this Wiki is using your language, and thus nobody on it ''really'' cares about it. As far as your "refactoring" goes: it seems more like you deleted a bunch of stuff like a child throwing a tantrum. Refactoring leaves the thesis and support for the arguments intact. And I can say for sure I am not "jealous" of qomp. I'd welcome a new language that actually offered me something. But I am a bit irritated a bit at the attitude of the author... and a bit amused, too.] *** You would not be here if you didn't care about it. Or, maybe you just simply do not value your time, or you are here because you have no life.. which is okay, because neither do I, hence my reply. *** [No, I'm here because I need to get a regular fix of arguing on the internet. It's addictive.] *** I have the old page saved, and was in the middle of refactoring it while you came in here and disrupted my editing. I am filling in holes with more precise language since I tend to speak verbosely. One of the reasons I speak verbosely is because I do not have a language which I can speak which allows me to express it in a terser manner. English is verbose. Programming languages, luckily, can be tuned. English is much harder to tune as it is fixed. *** [You are not the only person disrupted. I had to switch to short edits to avoid losing changes to local spots.] **** I applogize, Wiki's are not always the best places to be when two people are hammering away.. maybe a Forum would have helped.. but then again wiki's also offer other advantages. * Qomp is not a LanguageOfTheFuture since the L''''''anguageOfToday is more important, considering languages last for more than 30 years (C started in 1970's) ** [Feature-wise, Q''''''ompTheLanguage is a L''''''anguageOfTwentyYearsAgo.] *** You do not know Qomp, it is not explained here. This page contains mostly off topic rambling. *** [But I ''have'' asked about Qomp, and received lists of what you considered to be its features. And I ''have'' read your Wiki page and Qomp sample code until I grokked it. And I ''have'' read the majority of your mailing list posts on the subject. And I ''have'' learned Pascal in the past, so I'm aware of the basic features you're leveraging with the compiler. Don't assume I haven't a clue about Qomp and its capabilities.] **** You have not asked about Qomp. You have only mocked it, putting question marks at the end as insult markers. Each question mark you add is in a clever place that implies insult and/or sarcasm. When I speak of you, I speak of most everyone here. Not just you, but all of you. Yet these hypocrites are disgusted when the Qomp author treats others as they treat him. Karma. Oh, ''you'' are so special. So special. ''You''. **** [I did ask. I asked, and I quote, "Does QompLanguage have any features other than being 'easy on the hands'?" And, seriously, you'd been stressing so hard how being 'easy on the hands' was a big feature, and I could see how it could qualify, so I went ahead and counted it despite my belief that syntax can be and ought to be ephemeral. But I waited for an honest answer, to see what you believed qualified as features of QompLanguage. It is true that your answer merited a little mocking. Statements like "being easy on the hands might mean clever design" do not qualify as features, or even a proper answer.] ***** The main reason people use Ruby is because of it's terse syntax. It's OOP features are actually terse syntax (hiding other verbose syntax that would require casts). Syntax is a major complaint of the Algol languages and Qomp addresses this with Ego and Style. To explain all the advantages of Qomp that are not related to syntax (languages are just syntax though) will take days and days. ***** All languages are terse compared to assembly code. Terseness or tersity is the main reason people use programming languages.. so they don't have to write out verbose assembly code. VerboseLanguageWeenies do not understand this idea that programming languages are all terse forms of assembly. One terse statement in C or APL or Ruby is just a bunch of assembly calls if you look at it in a disassembler. ***** [You seem to have a fundamental gap in your comprehension of what a language ''is''. A terse statement in 'C' would only be 'just a bunch of assembly calls' if it always expanded to exactly that set of assembly calls regardless of its context or compilation environment (e.g. like a macro expansion). Since the set of assembly calls does vary based upon compilation environment and surrounding context (due to optimizations, register colorings, etc.), C is very clearly not just a bunch of assembly calls. Because of the post-processing, CeeLanguage isn't just SyntacticSugar for Assembler. Nor is Ruby or APL or almost any other compiled language.] ***** ''Just a bunch of ''different'' assembly calls is just a bunch of assembly calls. Your logic is flawed. Arguing for the sake of arguing. Programming languages are terse ways of telling the computer to do something, instead of sticking your finger in and flicking 1/0 switches yourself. The amount of 1/0 switches you'd need would multiply to such a high number - a verbose amount of 1/0 switches.'' ***** [Incorrect. A collection of assembly calls that vary based upon the context of the statement has VERY different properties than a does just a fixed collection of assembly calls. And I can only point you towards useful knowledge, not make you accept it. If you wish to persist in your fallacy, feel free.] ***** ''Nowhere did I state a language produces fixed assembly patterns consistently. I said "if you look in your disassembler" which means in context that if you look at your Qomp code as assembler, it is just assembler.. If you look at it from a machine code view inside the computer, then it is just a wrapper around machine code. There are only fixed (finite) number of assembly codes humans can can grok, which is much easier to understand than 1010101010101010. This is why I use an analogy or metaphor.. that all languages are just wrappers around our CPU's or our 10101010's (or assembly since it maps to humans easier than 101010). If you prefer, all languages are just wrappers around our CPU switches. '' ***** [Still incorrect. 'just a wrapper' is just wrong. If languages truly were pure syntax, without semantics, that would be true. But semantic post-processing violates your assumptions here. Types and type-checking violate your assumptions here (show me the 1001010101010 associated with a type declaration.) Variable names violate the assumptions here. Optimizations violate the assumptions here. Context-sensitivity violates the assumptions here. Portability violates the assumptions here. Your gross and inconsistent misunderstanding that 'languages are just syntax' has lead you far astray.] ****** ''Optimizations are not part of a language. You are making crap up and pulling it out of hats now. That is true magic, without the "k".'' ****** [Wrong again. Ever heard of the TailCallOptimization? it's a required part of several languages (including Scheme and Erlang). '''Any optimizations that are ''part of the language standard'' are necessarily ''part of the language''.''' And, once again, your ignorance of the field in which you're dabbling is staggering. Fortunately with language design, unlike 'magick' or whatever, you're unlikely to get burned.] ******* ''You seem to think there is "wrong" and "right" in this world. That portrays that you have a big ego, and it portrays you do not do research before or after yapping. Let's look at the "right" definition according to a dictionary, and then you can shut up or continue to make a fool out of yourself. A language, according to Webster's dictionary is "any means of communicating". Tail optimizations are not communication. Optimizations are specific to certain version of SchemeItself.'' ******* [There absolutely is 'right' and 'wrong' in this world. 'right' = 'right' is right. 'right' = 'wrong' is wrong. Proof complete. The fact that YOU seem to believe that you are somehow ''above'' being wrong is the mark of true ego. And the rest of your logic is horrible... as usual. A person who '''knows''' that there is right and wrong in this world would have a tendency to do research before yapping. A person like you, who believes that there is no 'wrong', and therefore that he can't '''be''' wrong, would have a tendency NOT to do research. You should follow your own advice: shut up before or continue to make a fool of yourself. And communicating in Scheme (ANY Scheme that adheres to the standard - which means anything you can legitimately call 'Scheme') means that you are communicating ''intent'' to perform the TailCallOptimization. Because it is part of the language. Therefore, the desire for the TailCallOptimization is being communicated by virtue of speaking in Scheme.] ******* ''"standard-compliant SchemeImplementations are required to support ProperTailCalls." You are mixing up implementation with language.'' ******** [Incorrect. Standards compliance is about adhering to the language definition. I could write a non-standards-compliant version of 'Qomp' and install it on a robot such that it interpreted every sequence of characters 'pro' as being a command to shoot at the nearest rabbit, but that wouldn't be Qomp standards compliant, would it? Or do you honestly believe that this would ''merely'' be an implementation issue, and that your language is, in this case, properly used for the programming of rabbit-killing-robots?] ******* ''First you said I was WRONG, now you are claiming there is no right or WRONG. CAPS LOCK justified for sure.'' ******** [I did not claim that there is no right or wrong. YOU claimed that. I denied it. AND I proved my claim. 'right' = 'right' '''is right'''. 'right' = 'wrong' '''is wrong'''. Are you illiterate, stupid, or do you just 'portray a person who does not do research before or after yapping' even when the research material is fully available by ''reading the paragraph'' before responding to it?] ******* ''Webster's dictionary: A language is "a special set of symbols used in a computer". A language is "the particular style of verbal expression". Tail optimizations are not part of language, even if there is a standard out there that says "these scheme's must have tail optimization". I can create a scheme implentation without tail optimization, and it can still be a SchemeLanguage.'' ******* ''C99 is not known as a language. CeeLanguage is known as a language. Certain versions of C or certain implementations of it can have specific optimizations. '' ****** ''Try and make a language without any syntax please. Language is syntax. You can speak a language too, but in programming generally we do not do so. That is why I make a big deal out of Qomp not just being a language, because it is more than that... optimizing Qomp is not optimizing the speed of the language. Although, of course some languages can be more easily optimized than others - but this doesn't make optimizing part of the language. The language is just the syntax. From the syntax, the context can be taken, the output binary can create different things. The compiler can be optimized, but a language is not part of the complete QompItself. Which is exactly why I made the distinction between Qomp and QompLanguage.'' [And is also why we're free to have QompLanguageReactions.] ****** [Syntax and grammar are ''part of'' a language; you can't express a language that lacks syntax. But language '''is not''' syntax - you also need semantics. In SeparateMeaningFromPresentation, syntax is the 'presentation' and semantics is the 'meaning'. Why don't you try and make a language that is '''just''' syntax?] ******* A Language "Mask" or Language "Mode" can change notation and syntax though, without affecting semantics. ******* [QompLanguage gives '''pro''' a meaning - semantics that are utilized by the language compiler when figuring out ''what to do'' with the symbol. Create a language without the semantics, or you have failed to do it with ''just'' syntax, and thus will have failed to prove that "Language is syntax." And of course a language is a way of communicating. But if I gave you the string: "bbjje34m23jd,a1", plus a pushdown-automata parser that could properly parse it (proving that it had proper syntax and grammar), it still wouldn't ''communicate'' anything to you. You ''need'' semantics to have a language. There is no getting around it.] ******* Qomp can be a notation and syntax mode (mask) for an existing backend or existing semantically defined language though. That's why I prefer not to call a page QompLanguage since it could even be QompMode or QompNotation or QompItself for now. ****** ''A language can be used on virtually any reasonable platform, it is the compiler support for it or the interpreter support for it or the CPU support for it that is the problem. Qomp can run on Windows and Linux and BSD and... but does that have anything do with the Language? No, it is the compiler implementation. If a certain CPU does not support 32 bit integers and if Qomp has 32 bit integers, then the language syntax for integer can be abstracted to support 8 bit integers. However, a strong LongInt or Int32 would not be used on the 8-bit CPU. The language syntax can remain the same if integer is undefined, while Int32 and LongInt are specific. That's just a type in the language, and not even the language. Types are just dumb parts of the language. Language, they way you are abusing and twisting it, in fact is a vague term.'' ****** [Before you said that "language is syntax". Now you believe it is "vague". 'Vague term' is usually a strong indicator that 'I have only the foggiest of notions what I mean when I use this term' - this is true whether it is your understanding that is muddy or if the term ''really is'' vague. It is time to face the facts: admit to yourself at least that you haven't a clue what you're going on about.] ******* One can actually define a new language mode (or mask) via only notation and syntax with the same semantics as another language, was his point. French Pomme is just a mask for Apple, as an example - yet the meaning of an apple on a tree stays the same - no matter what label/symbol/notation/word is given to the apple. ******* [I submit that he does not comprehend the implications of the Dictionary definition. I submit that he does not believe 'expression' or 'special' to carry any relevance, despite having parroted the words.] *** Languages thirty years ago had good ideas, and humans had good features thirty years ago. *** [Sure, but there are a bunch of thirty-year-old ''ideas'' that are also very good that never made it into the languages of thirty years ago. The languages of thirty years ago were based on the ''ideas'' of forty years ago. A modern language ought to fusion the best of the old in a very elegant manner.] *** Qomp is not new, it is old, Just as C is old, and C++ is old, and just as Java is actually UCSD Pascal reinvented. *** [Agreed.] *** Repeat: this is not about features *** [If you want Qomp to be a L''''''anguageOfToday, it's about features.] **** If that were true then C wouldn't be used today. Old languages are the language of today, because the language of tomorrow doesn't have infrastructure. **** [CeeLanguage is hardly a L''''''anguageOfToday. That doesn't mean it isn't used. Even Cobol is still used. But both of those languages are clearly nearing or at the end of their lifetimes.] **** This remark is outrageously funny. Ruby, Python, Java, Unix, Windows, Perl, and all those projects are written in C. End of its lifetime, end of Perl's lifetime, end of Python's lifetime, end of Java's lifetime, end of Unix's lifetime, end of PHP's lifetime. Yet Qomp is written in Qomp. Go figure. **** [Ruby, Python, Perl, etc. have ''implementations'' written in CeeLanguage - if CeeLanguage disappeared, they'd just build new implementations (and could easily bootstrap, since they're already working). CeeLanguage was designed to create Unix, of course, but a compliant system can be written in almost any language (not that Unix isn't also dated). Windows is written in CeePlusPlus, which is not CeeLanguage. ] ***** One cannot rewrite Linux and OpenBSD and such operating systems in another implementation if you study the personalities of the people in charge. Linus hates C++ and considers it a disease, loves C, hates Pascal. Theo of OpenBSD also hates C++. Cee will last a long time. At least 30 years. Cee is one of the LanguagesOfTheFuture that powers most of today's and tomorrows technology for a long time. This is because Cee is the LanguageOfYesterday. Which was my point about reusing infrastructure. ***** [One doesn't need permission from Linus or Theo. But, as I said, Unix is quite dated anyway... no point in cloning a poorly designed operating system, especially when you'd have such well-polished competition already in place.] ****** What well polished operating system will run on Web Servers? Oberon? Microsoft Windows? A rewritten OS from scratch that makes use of no existing infrastructure? Cee is here to stay for at least 30 years, because CeeIsUnix. ****** [I'm betting on a rewritten OS from scratch that makes no use of today's existing languages. It will still take advantage of standards and internet protocols and such, though. And Cee will probably be around for another 30 years, I've no doubt - languages tend to be generational (i.e. as in ''human'' generations), but it will be losing adherents and support and community over that period.] ****** ''One idea would be to bring back somewhat of a UCSD Pascal like operating system (but without Pascal's baroque verbosity flaws) where instead of the Bash Scripts and Perl Scripts, we'd have Qomp Programs and Qomp scripts. Bash is ''crap'', and there is no reason an operating system cannot be powered by a RealLanguage for sysadmin tasks. People don't use C for shell and sysadmin tasks since it is too hard to work with (especially because of pchars and allocations).. Qomp concise syntax, strings, and quick prototyping abilities makes it perfect as a language for sysadmin. A compile/run mode compiler that doesn't require separate compiling, linking, running makes it even easier. A program can be run right after it is compiled, almost like a scripting system'' ****** [You're not the first person with such an idea. Nor will you be the last. It is quite possible to do, but also a much larger project than is worth pursuing unless you have a clear concept of how to get a result that is superior to the already existing operating systems. Maybe go peruse NewOsFeatures for ideas... or not; Qomp, after all, isn't about features.] ****** OberonSystem and Apple operating system had some interesting ideas relating to this idea. * [And your terse QompLanguage seems to possess a compiler written in another language, too. Are you claiming now to have bootstrapped it?] ** Qomp compiler bootstraps itself, known as a "make cycle". * the arguers and debaters here have their own languages which have a zillion features but no actual parsers/code to back them up, whereas Qomp already has all its compiler and parser infrastructure in place. Theory: the arguers and debaters simply haven't a clue about what it takes to get a language out the door and want a Perfect Language with three zillion features. They also have been working for 5-10 years but have nothing to show yet other than wiki pages. ** [The arguers and debaters here know that getting a language out the door, in a real way, requires either enough features and polish to generate marketing buzz by its own virtues, or a fistful of cash the likes of which Sun and Microsoft can throw around while promoting .Net and Java.] *** Repeat: this is not about features. This is not about Buzz. This is not from Sun. This is not from Microsoft. This is from an oddball programmer who has no interest in making it a mainstream language, but if it does, that is okay. *** [You seem to want a 'community' of more than one oddball programmer.] **** Yes. **** [You seem to believe that IfYouBuildItTheyWillCome. You forgot that, in the real world, 'I''''''fYouBuildIt'''A''''''ndYouMarketIt'''T''''''heyMightComeButOnlyIfItGainsThemSomething.] ***** I need not worry if Qomp does not become mainstream. Even Google's SawzallLanguage is used only by a small Google Staff Community and all their internal Google indexing work; yet no one cares or knows about SawzallLanguage. So. ***** Are you building Qomp to impress a girl? That's something I haven't tried yet. ****** Yes. ***** If so, don't bother with QompOs. There's a difference between "sweet" and "trying too hard". ****** Too soft. ---- FebruaryZeroEight CategoryProgrammingLanguage