'''Counter-arguments against ItsTimeToDumpCeeSyntax''' *Not until you have something to replace CeeLanguage with. Guess what, you don't have it now, you won't have it for a while. You'd better get to work for that if you want it. **OberonLanguage more than adequately fills the same role that C does (there are no less than four working OSes written in it to prove it too). Some might argue that Oberon lacks unsigned types, and that its all-uppercase keywords are problems; OK, so make a new Oberon dialect that uses lower-case keywords and supports an UNSIGNED (oops, sorry, '''unsigned''') type (e.g., TYPE Foo = UNSIGNED INTEGER;). In fact, we've had an adequate replacement for C ever since TurboPascal came out. ***''Rebuttal/discussion moved to bottom of the page.'' *** TurboPascal was not a replacement for C.. it had some flaws that Standard Pascal had and it has improved into freepascal.. but never would TurboPascal replace C. For one, TurboPascal was a proprietary product that basically was only intended ever to run on Dos, and maybe Mac. ** AlternativesToCeeSyntax suggestions, sort of a Pascal/C/VB hybrid. *Never use the word '''dump''' for something that represents a life's work of some very respectable and knowledgeable people in TheArtOfComputerProgramming. And CeeLanguage is already a part of computer history. ** Well said. The question should at least be phrased politely, and it is not, here. ** The name is already part of "wiki lore" here. It too is "historical". And, just because something is established does not mean it cannot be improved upon or replaced. *You first have to know why CeeLanguage is the way it is, understand the real life concerns that led to this evolution of CeeLanguage over the years ** That would make an interesting topic or sub-topic. I always wondered whether they considered modifier words and types coming after instead of before variable names, and why they made that choice. ''See below under "Before and After''. *You have to think what do you do with tens of millions of lines of code ( maybe hundreds of millions ) in active development ** If we always have to make something backward compatible, we won't progress. And making an OSS translator shouldn't be that hard. *You have to have respect for differences of opinions, you have to show tolerance. You never say it's time to dump other honorable people's point of view, and after that '''pretend''' a Positive Dialog Community !!!! ** As descried above, it is "stuck" in wiki-lore as a phrase. There's a lot of it on this wiki, witness RelationalWeenie, and one just gets used to it over time. ---- '''Some strong personal reactions against ItsTimeToDumpCeeSyntax''' ItsTimeToDumpCeeSyntax started as a very opinionated pattern from someone who didn't know enough C to make a proper judgement. There were many assertion in there that were misguided, untruthful, condescending from a false position of superiority. There were many that showed intolerance. Now that most of them were finally removed I thought it was the time to create this page at the suggestion of FalkBruegmann. A discussion on wiki forum about ''dumping'' CeeLanguage is inappropriate to begin with. The majority of people here are concerned with ExtremeProgramming, ObjectOrientedProgramming, SmalltalkLanguage, JavaLanguage and the likes, and it was absolutely to be expected by the authors that they would meet little resistance to their ideas here, more they would be acclaimed by a few. The authors could have chosen to show their vision and superior understanding in a forum such as news://comp.lang.c or news://comp.lang.c.moderated. Starting such a discussion on wiki is like I'd go into a heavy metal club and I'd propose an elevated discussion ItsTimeToDumpJazz. I would be really smart, wouldn't I? Now the bulk of the arguments for ItsTimeToDumpCeeSyntax are gone, and the people there are complaining that Ceelanguage is not appropriate for some tasks (like teaching beginners who'd like a little easy scripting). Guess what, there's no silver bullet. Maybe you should try a page CeeLanguageIsNoSilverBullet, and thank you very much for the truism, everybody knew that for a long time. For these reasons I sustained (and still do) that ItsTimeToDumpCeeSyntax is still a shame for the wiki community, and maybe it would be time for the authors to dump ItsTimeToDumpCeeSyntax. As a matter of fact they did it once, but somebody had the bad inspiration to put it back again. This would truly show a PositiveDialogueCommunity. -- CostinCozianu ''How about first we find a new consensus name. When settled, you can then volunteer to do the text refactoring and back-reference work. Personally, I think it is a very minor issue, but if you feel strong enough, then you can fix it via some elbow grease. '' ---- '''Discussion''' The wiki consists of not only programmers, but utilizers of programs. It is obviouse to anyone who has tried that the CeeLanguage is not easy to learn or use. One who is a novice finds it easy to lose his way and to write bad code. Those who do not program in C or Assembler or other languages that can access the machines internal memory, registers, its IO, may not understand the need for code of this nature, but without it, there would be no "higher level" languages. The choice of a name for a page may not adequately demonstrate the underlying problem the writer is trying to express. I understand it as an expression or a complaint that programming is far to complicated, and that one must be a full-time programmer to have access to the considerable capabilities of the modern computer. I believe even accomplished programmers will use scripts to manage the complexities of code development or will use productivity aids to produce the tedious and repetitive steps necessary in the programming, compiling, linking and executing the code. By using such an aid, a programmer can produce a C language program with thousands of lines of code in a matter of a few hours if not a few minutes. This does not mean that the CeeLanguage is dumped, it however has removed some of the complexity by utilizing pre-programmed automation. The syntax is still there, but not all of it has been developed by the application programmer. Those who try to write programs without such aids must be experts, not novices. Pardon those of us who do not have that kind of expertise if we seem to think that programming can only be done at a low level and that only experts can program. I believe users can rightfully expect that programming can be made more accessable. Do you contend that it cannot be? ''It should be pointed out that dumping C and dumping C syntax are different things. Many languages borrow syntactical idioms from C and this is the practice that bothers me the most. We need a new reference standard for new languages more than we need to replace C itself in it's own niche. Many of C's apparent idiosyncrasies may even be a benefit in it's own niche. "Fixing" them may break other things. However, those reasons may be irrelevant in the newer crop of languages that borrow from C's syntax yet don't support "naked" pointers, for example.'' ---- '''More strong reactions''' Pardon me, but why don't you use VisualBasic and keep quiet about C? From saying I'd rather prefer not to program in C, to saying ItsTimeToDumpCeeSyntax, is quite a difference. Sure those who write programs in CeeLanguage are not necessarily experts, the majority of CeeLanguage users are not gurus, but they are not novices either. Just leave them alone (or are you going to tell them they don't know what they do), if they need scripts be sure that they will use scripts, or even something as simple as editor macros. If you want to dump C syntax you rightfully have to dump CeeLanguage otherwise the syntax will still be there to haunt you. ''It is not so much a rally against C, but rather a rally against the continued proliferation of C-style stynax, such as we C....I mean we see with the likes of Java, C#, PHP, JavaScript, etc. '' {I don't think I'd consider VisualBasic the only or best viable alternative. However, that C# and VB.net are almost completely interchangeable is an interesting concept in that it gives one a style choice but still has the same libraries and behavior.} ----- ''I believe users can rightfully expect that programming can be made more accessable.'' Oh, really. How about a page Inexperienced Users Have Plenty Of Languages Other Than C ? As to why programming is rather ''not accessible'', you can read TheArtOfComputerProgramming.-CostinCozianu Not Dumping, Enhancing: : The road to more accessable programming and computing interfaces and equipment is what modern Personal Computing is all about. Change is in the winds, whether we like it or not. A lot of people who use to wear "Wing Tip Shoes and Business Wear" and computed on the Osborne Computer, they now are wearing sneakers and casual business wear and have at their disposal 1.+ Gigahertz machines with megamemory, gigantic hard drives and equipment to make it possible to do an almost infinite number of things - many things that old computer just wasn't cut out for. I'm not saying that what we need is a replacement for C, or replacement for Assembler, as much as I am saying we need an enhancement, and pluggable extensions that make it easier to program. Isn't it possible to increase the capabilities of the C++ Syntax and the substantial power already there by adding, enhancing, extending and creating interfaces that make the use of it easier? I'm not saying scrap what we already have, just plug in more stuff to it to make it better and more accessable. It's not time to '''Dump!''' -- it's time to '''Enhance!''' ** What exactly does 'enhance' imply to you? Syntax is something where cruft can trip up extensions, and the ability to non-monotonically '''dump''' syntax (in whole or in part) is absolutely essential to the ability to '''enhance''' it in most of the useful ways it might be enhanced. Now, if we enhanced the CeeSyntax to the point where we could enhance the CeeSyntax or dump the CeeSyntax from within the CeeSyntax, that would satisfy me. ''You know, with a few minor edits your above statement could have been from a cobol advocate, years ago. Sure, easy to use tools can be good (but also can be bad). However, there are things about programming that are fundamentally difficult; covering them up with syntatic sugar, wizards, code generators, etc. only make things *worse*, not better (see cobol reference). I am sure that for trivial tasks, very simple interfaces to scripting type tools will allow the average computer user to do some well defined 'programming' tasks, without much thought in the near future. We see the awkward seeds of some of these today. Pretending that this is a new wave to revolutionize programming and open it up to the unskilled is, I think, at best misguided.'' I don't know any Cobol advocates, we have moved way beyond that now. I think however that skilled accountants, engineers, lawyers, and doctors should be able to utilize the computer through powerful languages such as C. Very few unskilled Users even consider using computer languages to construct programs, they use Excel, Access, Word and Outlook Express to do the trivial things. I think some intelligence is required in all of the professions mentioned above, and the fact that each of them have utilized the personal computer to assist them in their professions is a good thing. I believe giving them easier to use interfaces to powerful methods is not to much to expect. None of them have the time to become programmers at a level approaching that of a computer professional, just as no computer professional can be expert in all of the fields in which he must construct solutions. I am not pretending a new wave, I think however I am expecting a new wave. Maybe my expectations are misguided and overly optimistic. Maybe I have more confidence in the capabilities of computer professionals than I should. But I can't help but hope! ''The problem doesn't have much to do with the capabilities of computer professionals. The nut you are trying to crack needs basic research, not engineering effort. Until there are some theoretical breakthroughs, a lot of the things you want are going to be restricted to the category: does a good job on trivial problems, falls on it's face for some real problems (and it is hard to predict and recover from). Also, 'falling on its face' can include messing things up badly enough that fixing it eats any productivity gains you have seen from using the approach, plus some.'' ----- I am curious, how would various wikizens implement closure syntax in a C-style language? ''You mean like this?'' typedef int Func''''''Ptr() Func''''''Ptr counter() { int acc = 0; int up() { acc += 1 return acc; } return up; } ----- C has its flaws, but although quite a few languages have been suggested as potential replacements for C (that is, for the critical roles that the C language still plays today), no replacement is at all widely accepted. Presumably this situation will eventually change, but it certainly has not, as yet, by 2008. ---- Operating systems have been written in Lisp, Forth, APL, and many other languages. That in no way means that the language in question is therefore a "C replacement". It may or may not be, but that argument doesn't work. * I quite disagree, because the single biggest "metric" by which C's popularity is measured by is, "Can I write an OS with it?" Overall, I ''do'' agree that other languages have been used to write at least one OS. However, there are two factors which affects whether or not folks "consider" this a fair comparison: '''first,''' what is the ratio of run-time environment (which needs to be written in assembly, usually) to OS proper, and '''second,''' can I do ''efficient'' bit-twiddling? For at least some Lisp, Forth, APL, et. al. implementations, the answers to these questions didn't compare well with C's. As a result, these languages, however good they may be ''now,'' are forever tarnished. Oberon, however, is quite comparable, right from day one. Heck, even Modula-2 was ''explicitly'' designed for systems programming as well as applications programming (like Oberon, Modula-2 was first used to write a "Modula-2 environment"). Oberon essentially ''is'' Modula-2, but greatly simplified (as in RISC versus CISC). The only thing lacking from Oberon, as compared to C, is the perception of brevity. In C, you rely much more on single-characters to provide structure to a program: if, while, and for loops need parentheses to enclose various expressions, you use curly braces to enclose blocks, you use asterisks to indicate pointers, etc. In Oberon, you typically use full words. Thus, many folks find C "easier to read" (though, this baffles me utterly). But, when it comes to ''replacing'' C, presumably with something that is largely comparable to C but with noticable improvements, Oberon is it. It supports ''real'' modules with gestapo type safety, ''real'' single-inheritance for records, Oberon-2 supports virtual methods thus earning it its "Object Oriented" cub-scout merit badge (allowing it to compete with C++, really), and it supports garbage collection. As a C programmer for decades, I can't see how C survived and Oberon didn't. * ''If one wishes to understand how C survived while Oberon didn't, perhaps one should stop thinking "as a C programmer for decades" and start thinking in terms of economy, market share, killer applications, and codebase inertia. 'Good-enough' is the enemy of 'it-could-be-better'.'' ** Tell that to the folks who jumped ship from C++ and moved to JavaLanguage or CeeSharpLanguage for their software, both of which inherit their semantics strongly from Modula-2 and Oberon, even if they do use a syntax as ugly as a rotting bovine corpse in a dumpster. Clearly, "good-enough" isn't always "enough." *** ''CeeLanguage is obviously not 'good enough' for Applet programming and sandboxed language support, and that (along with a truckload of marketing from Sun) is essentially what motivated the folks who abandon CeeLanguage for JavaLanguage back in its infancy. JavaLanguage has not (yet) proven to be an adequate replacement for CeeLanguage or CeePlusPlus in the area of systems programming. CeeSharp, similarly, attempts to establish itself in a niche (and is similarly advertised and pushed as '.NET') that makes no effort to displace C. By doing so, it may be capable of gaining the user-base and development effort (esp. JIT compiler support) to become good enough to displace C++ as a systems language. But note that Sun and Microsoft still haven't written a full OS in Java or .NET (respectively) - Codebase inertia, market share, existing killer apps, etc. all keep C and C++ alive. The existing solutions are, indeed, a case of 'good enough' stubbornly resisting 'it could be better'. And the folks who jumped ship should at least recognize the situation for what it is (''which we do, and we advocate you're still wrong about C '''not having a replacement'''''), even if only for the purpose to sound better educated when they rail at it.'' ***** ''I've never said that there aren't other languages '''capable''' of replacing CeeLanguage, you silly man. What I have said is that JavaLanguage and CeeSharpLanguage are not it (and your attempt to bring them into this argument was a weak, strawman argument at best, since they've never been utilized or marketed as C replacements in CeeLanguage's own niche), and, most importantly, that no proposed CeeLanguage replacement is ''enough'' better to justify conquering the problems imposed by economy, market share (including mindshare), and codebase inertia. If CeeLanguage wasn't already entrenched, there'd be little competition between it and, say, DeeLanguage or ErlangLanguage. If you wish to understand why C survives where 'better' languages falter, any purely technical viewpoint will fail you. 'It's good enough' is the enemy of 'it could be better' BECAUSE 'it's good enough' is entrenched and codebases, like everything else in this world, have inertia and resist change.'' **** Considering Java is written in C, laughingly Java is not ready for systems programming ;-) And yes I know someone could write Java in Java but I don't see it happening any time soon since all Java programmers love to have C available too.. Some java programmers even use languages like freepascal which can compile themselves - and start figuring out that C might not be for them. Java is partly a UCSD Pascal rip off, too. **** ''There are reasons Java isn't great for systems programming, but having an implementation written in C is not among them. As a general rule, you shouldn't ever consider the implementation language to be a property of the implemented language. SQL is SQL whether implemented in C or Java or Prolog or Assembly... and Java is Java no matter how you implement it, too. Java programmers could even still have their C FFI if Java was written in Java or any other language.'' *****As a general rule, you should not make general rules. If someone writes all the languages in Cee, then we are all going to be maintaining Cee and that is what keeps it alive. Cee is no longer needed for application development - but '''Cee runs all (most of) our systems'''. Our systems are Ruby, PHP, Java, Windows, Unix, GTK, KDE, BSD, etc. If the OS is written in Cee and if Cee is written in Cee.. then this does greatly affect whether or not the language is a systems programming language that is widely used. Java is Java even if you write it in Ruby.. but this isn't happening. There are good reasons. Because C is good enough for Java. They don't need to convert it to Java in Java or Java in Ruby. There is no purpose. They already have Java in C and will continue to maintain it. We aren't talking about academic theory - but infrastructure and practical theory. *****''I must disagree with you again. As a general rule, you '''should''' make general rules: gravity goes 'down', horses have four legs, spiders have eight, all men are mortal, the sun sets in the 'west' no matter what part of the world you are in, etc. You wouldn't comprehend shit (or anything but the minutiae of your experience) without general rules. One can even have general rules about the circumstances in which one shouldn't make general rules. The very basis of learning is 'general rules', and only someone who thinks themselves wise whilst failing to give the concept much thought would come up with an inconsistent platitude like "as a general rule, you should not make general rules".'' *****Yes I made a humorous ''(You have a much greater opinion of your humor than do I.)'' recursive general rule: as a general rule, you should not make general rules. Horses could lose (modify) 2 legs through adaptation, just as the Simpsons have 4 fingers instead of 5. Men are not mortal if we figure out how to replace body parts through stem cell growth. Teeth can be replaced now with fresh ones, as of before 2007 (through stem cell implantation). I agree that general rules exist and should be taken note of, but as a rebel one should not follow ''many'' of them. This is how new important inventions and discoveries are made. As a general rule, the moon was flat according to Catholics - and a man was arrested for saying otherwise. *****''And the ability to interface with other languages IS a feature of a language, but is not dependent upon the particular implementation of the language. Being written in C is not (not even a little bit) necessary to interface with C or the unix/windows system calls or even the hardware directly. The plain fact is that the properties of Java '''do not depend''' upon implementation in CeeLanguage; that which you attribute to the implementation language is not necessarily an attribute of the implemented language, and you cannot rationally declare that JavaLanguage being implemented in CeeLanguage is what prevents '''the language''' from being good for systems programming or direct hardware control. If you want to make a claim about the implementation of the language, that would be a different matter entirely... but if you want to talk about the infrastructure, then use words that identify the infrastructure - words like 'SunJDK' and 'Blackdown'.'' *****A good test case for a systems programming language is to compile itself. Without a test case, the systems programming language is just a pipe dream.. i.e. we have all these ''but'', ''if'', ''and''. Ruby could be a systems language ''if they just''. Java could be a systems language ''if we just''. *****''I've written a Java compiler in Java. Heck, there is a whole book on ModernCompilerImplementationInJava by Andrew W. Appel.'' ***** No, the existing infrastructure is already in place - the Java Language is heavily relying on C and it isn't going to change any time soon - just as PHP is written in C and it isn't going to change any time soon. PHP could be a systems programming language ''if they just but and if and but''. I speak of practicality - existing infrastructure is that they've already spent all that time writing it in C and there is no need for them to write it in another language since they ''love'' C anyway since they think ''hey C is for systems programming and PHP is not so the whole point is to keep writing these thingies in C''. Something like Oberon or Freepascal which is written in itself is generally rare.. even Delphi compiler is written in C++ because they believe ''we used the right tool for the job''. C has so much '''momentum''' as the ''right tool for implementing low level stuff'' even if it is a lie or even if it isn't the '''right''' tool. ***** ''I won't disagree with the notion that C has, for better or worse, a great deal of mindshare.'' **** The issue is whether or not C has a replacement, not whether Java is adequate for systems programming. I mentioned Java '''''only in the context of proving that C's "good enough" isn't good enough for a lot of people.''''' Please do not take my words out of context. Oberon and Modula-2 both are more than adequate to address every single application that has been written in C thus far. ''Other issues,'' such as maintaining a body of established, legacy code, are valid issues, but ''do not'' address ''new software.'' ***** '''''The issue of entrenched code does address 'new software'.''' It is plain to see how an existing codebase affects the languages programmers must learn in order to perform maintenance and extensions to this software, which in turn affects the tools they are most familiar with using, which in turn determines the languages with which they are most comfortable programming, which in turn ''further entrenches CeeLanguage''. It doesn't even take foresight to understand this... simply looking at history will teach you all you need to know about the subject. There is only so much mindshare in individual programmers, and CeeLanguage managed to win much of it away from its competitors. Unless Oberon or Modula-2 can attack a different niche, win mindshare there, and spread from that point, they will '''never''' penetrate the market, no matter how much 'better' you believe them to be. Heck, most programmers have never even ''heard'' of Oberon or Modula-2 - that's worse mindshare than even Fortran and COBOL have.'' ***** ''... Oh, and on the minor quibble: your mention of Java was misleading and already out of context; prolog isn't "good enough" for OperatingSystem programming, either, but that doesn't mean it isn't "good enough" for what it is intended; if you talked about people leaving CeeLanguage for Prolog, it wouldn't say '''anything''' about whether CeeLanguage was "good enough" for these people - not any more than using a hammer suddenly means that sandpaper isn't 'good enough' for a craftsman. And if you want to talk about whether CeeLanguage has a replacement, you need to talk about replacing CeeLanguage in its own niche.'' *** ''Even within a single language, 'good enough' is the enemy of 'it could be better' based on codebase inertia and the fact that updating the language becomes inconvenient if it requires touching code that has already been written for it. It becomes a simple matter of economy: is the benefit of fixing the language greater than the cost incurred by introduced incompatibilities? Unfortunately, the probability of that answer being 'no' increases with the size of the codebase, which is the reason languages (if they are imperfect) 'age' over time, becoming inflexible. As a language designer myself, one of my fears is creating something that is 'good enough' but lacking the foresight to add some critical piece that both would make it much better AND can't be added later. (My approach to conquering this fear has largely been to make it easy to extend the language's syntax and semantics from within the language... so that if I missed something, someone else could add it.)'' ***[It is very hard to have a language where you can extend the language '''in so many respects''' without it being flawed from a readability perspective, maintenance perspective, or time perspective (releasing the first version of it). A programming paradigm that intends to be extremely extensible in syntax, notation, semantics, etc is a '''pipe dream''' and a goal that cannot be completed. I say '''extremely''' because of course it is possible to complete a partial extensible language, but not an extremely extensible language (without everyone hating it that is). It is possible to have extensibility but in practicality we speak of '''non extreme extensibility'''. Some ''lines must be drawn''. In fact, '''extensibility requires odd weird syntax and notation''' usually. Take Lisp, where everyone rewrites their own languages for each application in their own mini lisps - and everyone hates lisp syntax except a few people who get used to it. Study Lisp and we realize that there is really '''nothing to lisp's syntax/notation at all''' and '''that is what makes it extensible''' (and horrible at the same time). It's notation/syntax is what makes Lisp Lisp.. otherwise it'd be called advanced XML. What about other more fixed extensions to a language: sure there are operator overloaders and more fixed ways of extending syntax look at C++. It can cause havoc, as do Macro Preprocessors, templates, overloading, etc cause. For systems programming at least (I know this page isn't just about that), it is better to have well defined language that is fixed ''in some senses''. Not all senses. The most important thing that C has is the separate .C files and Include files which make it partly modular.. just not properly modular. A systems language doesn't need to be proper, but it would be nice if it was.] **** ''As far as mechanism goes, a highly metamorphic language is actually a great deal simpler than you believe: extensible syntax forms have been studied and explored very thoroughly since the 70s and the better discoveries are fully ready to come out of the panoply of toy languages and into production. Additionally, the ability to extend semantics is easier than you might think: it 'only' requires the ability to declare (within the language) the addition of post-processing components over all or select parts of the AbstractSyntaxTree (a task that is aided greatly by use of a HomoiconicLanguage); the important thing is that a declaration in one part of the code can affect the meaning of some or all other parts, and AspectOrientedProgramming is an example of this. So I must disagree with your judgement on its feasibility. Also, extensibility doesn't require 'odd weird syntax and notation', though is benefited by shorthand styles. But one can make it look fairly natural - pattern-matching on characters, types, parse-trees, etc. EBNF-style would be a good start, but see ExtensibleProgrammingLanguage. Finally, on the readability and maintenance issue: programmers always have the power to write unreadable code, and some of them do it for fun (ObfuscatedCee, OokLanguage, WhitespaceLanguage) - I will in no way deny that the ability to extend the language will also make it easier to write horrendously unreadable code. But I believe most complaints of that form are of the BlubParadox nature. The ability to extend and transform the syntax also grants the ability to write very readable code - code not bogged down by 'trivial' details like the exact structure of a 'for' loop, or the exact mechanism for taking a graph-description and getting it into a structure, etc. Programmers who aren't obfuscating their code for fun will be able to make it extremely clear what they intend in their code - in some cases, even having code that often reads much like natural language pseudocode (something people have been accomplishing to lesser degrees even in Java and C). The only '''real''' problem is that following ''exactly'' what the code is doing can become difficult because it can be extremely meta-meta-meta - expanding into macros or templates that expand into macros or templates until the maintenance programmer can only trust/hope that what the code actually does is what is so clearly written. A good debugger, unit tests, and development environment that performs type-analysis and allows following expansions with progressive disclosure would solve most of these problems.'' **** But why not just use lisp... Because.... it is already too extensible and needs more fixed structure? i.e. let's examine existing languages and study why people are not using them. My opinion is that languages that are extremely extensible are not used widely because of ''that very reason'' (not directly, but indirectly.. i.e. people do not use lisp not because they know it is extensible, but because indirectly the extensibility of it makes it unappealing through other means.. such as its unstructured odd paradigm which doesn't follow fixed imperative style commands that humans are used to and tries to force on you the silly idea that everything is "returned" somewhere). By '''not used''', I mean as a general rule.. which.. humorously I don't usually make. i.e. not that people don't use Lisp, but I think one reason people don't use it is ironically because it is extensible (causing indirect side effects that people don't like). However, XML has caught on because it is extensible.. but it is very fixed in a sense that it is just DumbText and this is why it caught on possibly.. just as dumb INI files caught on since they were so extensible yet dumbly fixed at the same time. This is where I see "a line being drawn". If someone turns XML into a systems programming language, it becomes Lisp and it sucks - because it is too extensible and simple looking with funny greater than characters everywhere - instead of fixed structured code. C++ has also caught on because it is extensible, but I think it is extensible in a fixed manner.. rather than an extreme one. Also, '''not''' all my replies are '''pure''' arguments.. Just brainstorming -- DevilsAdvocate **** ''I decided against Lisp because it is not well designed for secure, distributed operation. It depends too much upon micro mutable 'cons cells', and lacks clear semantics for the creation of immutable structures, both of which are harmful for purposes of optimization, security, and efficiency in the distributed and highly concurrent environment. (Clojure would be a better choice for a Lisp-like language.) And while I don't mind Lisp's syntax (or lack thereof) for certain things, for other things I find it dreadfully annoying and it is NOT particularly extensible. I.e. you can use RealMacros in Lisp, but there isn't a very easy way to get rid of those L''''''otsaIrritatingSillyParentheses. Other people have decided against Lisp because it was (at the time the need existed) lacking a type-system and a tad inefficient for low-level bit-twiddling for hardware device drivers, and the flexibility of macros wasn't worth the loss of efficiency in the minds of those coding the Unix systems. Anyhow, I guess we'll see... the languages of the future will be duking it out between static/dynamic/soft typing and between rigid/extensible. I can tell you for certain that IBM's AspectJ and LanguageOrientedProgramming have both earned a LOT of interest. Perhaps the real battle will be between different ways of thinking: those who are rigid in their ways and hate deviation and want to '''force''' -everyone- to think and express their ideas in exactly the same way, and those who are flexible and adaptive and like the ability to express their ideas with freely even if the cost is others having the same ability. I can already tell which side you believe you're on, and I'm sure you can guess mine.'' ***[I know we are not talking purely about systems programming here, but the fact is if we already have so much sh*t writtem in C, like Unix (which is a system) and Java (which runs on a system, and is a system itself, a bit) - you can't just magically expect another language to take over the world if Cee is ''what our systems are all written in already'' and ''what all our language compilers are written in, most of them''. For pure "New Software ".. I addressed this once with "existing infrastructure" yapping. New software should be able to make use of ''Old Libraries'' at minimum, and "Old Api's". This is at least partly possible in Oberon using C Dll's and such things on MS Windows with ComponentPascal.. but.. on the OberonSystem it is much less practical as there isn't really any reuse of existing infrastructure. A migrating path is good - versus a revolution that completely abandons and starts from a fresh sheet. Eventually you can migrate people to the fresh sheet but it is harder to drastically do it magically in one shot like Wirth tries with Oberon. Wirth expects people to just move over to his OS for what reasons? Wirth is a MinimalismWeenie. The target market of operating systems are stupid people with too much money who are FeatureGaloreWeenies such as the Mac and Windows people who cheer out loud when a new skin or animated mouse icon is added to the OS in the next release. In addition, people need to like the language enough.. and BEGIN and END caps locks doesn't help.. although it is a minor factor.] **** ''In a sense, CeeLanguage already 'took over the world'. It took years and years, but it happened. I don't have much reason to believe that another language couldn't do the same - AJAX and PHP seem to be coming along well enough, albeit well outside C's niche. But I do know that the language that does can't just be a slightly better (more modular, more safely typed) clone of CeeLanguage (as per CeePlusPlus or JavaLanguage or your choice of Pascal languages). I do anticipate that, long term, the Systems programming language of the future will be one that supports DeclarativeDeviceDriver''''''s and DeclarativeMetaprogramming.'' -------- '''Before and After''' Re: "I always wondered whether they considered modifier words and types coming after instead of before variable names, and why [C inventors] made that choice." When they were small and simple, like "int", "char", "float", etc., it didn't make much difference whether they came before or after. Further, one needs a key-word of ''some'' kind to indicate a declaration follows. If the type name does that, then we don't need to have a declaration indicator such as "var" or "dim" (BASIC). "int" killed two syntactical birds with one stone. However, for longer type names and modifiers, the variable names eventually got lost in the clutter. The existence of syntax coloration in IDE's is probably the only thing that has kept the "before" style alive. -t ''C was invented in an era when parsers were typically created by hand without the benefit of parser generators, and ran on much slower machines. Syntax considerations were often as much about making writing the parser tractable and its performance acceptable (e.g., avoiding any lookahead) as they were about language design.'' * [PascalLanguage is of an age with CeeLanguage and chose the other way. From what I've heard, C's declarations were intended to mirror C's use, e.g] int * foo; /* declaration */ *foo; /* usage */ * If I am not mistaking, Pascal used longer type names, such as "Integer" instead of "int", and had "record types" back then that were precursors to user-defined types such that the type name could be anything you wanted. Thus, it was pushing the declaration size envelope. * ''You mean the size of the name? Or the size (in characters, I presume?) of the type declaration overall? At the time, such sizes were largely a non-issue in terms of implementing the parser, though there was considerable impetus to keep them short due to memory limitations and the fact that most programmers were using slow terminals and couldn't touch type, and a comfortable precedent had already been set for USNG SHRT NMS on IBM, ICL, etc. mainframe systems.'' * Personally, I still like short names for the commonly-used standard types, largely because short lines of code are generally easier to read than long lines (at least for my WetWare), and abbreviating common names/tokens helps there. Whether this consideration is a factor in C's design, I don't know. Even if they decided to put types and modifiers on the right side, the C makers may still have elected to use shorter names. Pascal was originally intended as a teaching language, and as such, may have selected newbie clarity over brevity. We may never know why C did it what it did. * ''Sadly, such knowledge probably died with DennisRitchie. Apparently, BrianKernighan had nothing to do with C's design. However, the practice of putting keywords before variable names may owe much to KenThompson's B. He's still active in the field; perhaps you could ask him. He's also partly responsible for Google's GoLanguage. You might be interested to note where keywords appear and how variables are declared in Go.'' * [Not entirely. We still have his writings. For example http://cm.bell-labs.com/cm/cs/who/dmr/chist.html For this particular issue, check out the embryonic C section.] * ''Nice find; indeed it answers the question. To wit, quoting the above, "[i]n all these cases the declaration of a variable resembles its usage in an expression whose type is the one named at the head of the declaration."'' Could indeed be a reason, but even if I didn't have to worry about compiler technology, I probably would have done the same thing in their situation when the types were short and simple. The known alternatives are more verbose or confusing in a "brief type" world. Consider: // Variation A int foo; float bar; char miff; // // Variation B var foo int; var bar float; var miff char; // // Variation C var { foo int; bar float; miff char; } // // Variation D foo: int; bar: float; miff: char; Variation D is the most competitive with A, but could be confusing for in-block declarations. Variation C could work okay for in-block declarations if the the the brackets are optional for one-variable declarations, but then creates two different "visual" styles. ---- CategorySyntax