Its Not Time To Dump Cee Syntax

Counter-arguments against ItsTimeToDumpCeeSyntax

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 FuncPtr()


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

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. 

    int * foo; /* declaration */
    *foo; /* usage */
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

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