|
OK, I'll "bite".
"C" is quite the most disastrous so-called "language"[1] ever to become popular.
Why? It's total lack of marshalling over record boundaries in memory have cost the globe at least several 100 trillion dollars in viruses, damages, fornicate-ups, interminable repairs/patches, Trojans, injuries, deaths, et cetera.
That alone is enough to relegate this incurable abortion of a syntactical nightmare to the bit-bucket, if not Spandau prison.
Have at it, you "C" devils.
___________________________
[1] Designed for punch-card use, brevity & conservation of card-space were essential.
It thereby became an impenetrably terse & line-break free mess. All calculated to save IBM punched cards.
And the syntax is dangerously ambiguous, all over the shop.
Don't get me started on the monumentally bone-headed notion that CASE statements should cascade through without a BREAK clause!
I mean. What total idiot "thought" that this would be a great idea?
|
|
|
|
|
Michael Kingsford Gray wrote: the monumentally bone-headed notion that CASE statements should cascade through without a BREAK
 Hear! Hear! That is (in my opinion) the very worst mistake in C.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Maybe, but at least it's consistent with the goto/label syntax.
|
|
|
|
|
Maybe, but break doesn't affect a goto. And I have never used a goto in C.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
My point was that a series of case statements resembles a series of goto jump labels, and therefore there is an expectation for the flow of execution to continue, even past the next 'label'. The break command isn't associated to the case statement, it is associated to the switch block.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: resembles a series goto
Not to me it doesn't.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Because you chose to ignore the part that I specifically underlined. I didn't say <big>goto</big>, I said <small>goto</small> jump labels - that is a world of a difference!
How is the following
switch(a) {
case 1:
...
case 2:
...
}
different from
on a goto label1, label2
label1:
...
label2:
...
?
The multilabel on ... goto variant is present in many BASIC variants.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: you chose to ignore
I didn't ignore it; the CP selection quoting doesn't like to select text with tags in it and I was too lazy to copy the other text into the quote.
Like this:
switch(a)
{
case 1:
{
...
}
case 2:
{
...
}
}
Stefan_Lang wrote: is present in many BASIC variants
C probably pre-dates them, so perhaps the designers of those variants got the idea from C  . When I learned BASIC we didn't have labels, only line numbers.
ON a GOTO 100 , 200
Also, the lines/labels could be anywhere, not grouped together as with CASE statements. Ergo, to me a switch doesn't resemble an ON/GOTO at all.
BASIC (1964) doesn't appear to have had ON/GOTO.
BASICplus (that which I first learned on a PDP-11, and for which I have a book first published in 1976) has no labels and therefore ON/GOTO with line numbers only.
Turbo BASIC (1987) has labels and therefore ON/GOTO with labels.
In the late '80s I was using VAX BASIC and I don't recall it using labels, though it probably did. HPBASIC, the current version of VAX BASIC, does of course.
You'll never get very far if all you do is follow instructions.
modified 4-Jun-14 10:09am.
|
|
|
|
|
Michael Kingsford Gray wrote: several 100 trillion dollars
everyone can make up numbers. Just to get an idea of how ridiculous a claim yours is, check this out: http://xkcd.com/980/huge/#x=-11116&y=-7100&z=4[^]
Even if the number you posted were accurate it means nothing at all without context, and you cannot provide that context either: You have to put it into relation to the amount of code written, and then compare to equivalent numbers for different languages.
Anyway, the vast majority of really severe and costly bugs are not related to any specific language feature at all, and could have happened in many different programming languages. For instance the Y2K bug was born at a time when C didn't even exist yet: it was a conceptual decision to save memory. Something that at the time made sense for any program, and was kept that way, until people started to realize that it would lead to a problem! That[^] was a costly bug!
Michael Kingsford Gray wrote: [1] Designed for punch-card use [...]
As all other languages at the time. And the punch card limits are no longer an issue in the modern C language (or other languages that survived: see Modern Fortran, Modern Cobol, etc.).
|
|
|
|
|
Always was and always will be. IMHO. 
|
|
|
|
|
I don't care so much about the language as everything else. When Java first came out, I finally had a system to write graphical desktop applications on different systems without a ton of BS. Sure people joked about AWT being "write once, debug everywhere", but compared to everything else it was light years ahead. I had libraries that actually worked - on average, I could not compile a C library, so who knows if it did what I wanted or not. I had really simple database access, network access, all the stuff I had wanted and couldn't seem to get. I was like a kid in a candy store.
This is the problem with C - not the language, but the lack of something akin to the JSR process, where standard libraries for all sorts of useful things are created. I'd be the first guy to say that Java programmers love to go overboard and make a Rube Goldberg library for everything with 59 layers of abstraction, whereas C programmers tend towards minimal libraries that do just what's needed and no more. But then those C programmers love macros and other things that make the code hard to understand, and they need systems like autoconf and ports trees to actually get their libraries to even compile on different platforms. Six of one, half dozen of the other.
So I still love Java for all it provides. The language is overly complicated, and generics are by far the singular worst - and completely unnecessary - feature. When I saw all these new script languages cropping up, I thought, well what about the library for database access, for generating spreadsheets, PDFs, reports, images, etc? I failed to see why I'd want to switch to something shiny and new that is clearly less capable just because the language was simpler.
Years later, I see people moving back to Java because they had scalability problems, or problems like this author described with something fundamentally wrong buried deep in the guts of the system. And I still don't see much in the way of database libraries and other things.
I have a chuckle when I read about such things. The more things change, the more they stay the same. I'm sure there are other languages that have a great set of libraries for useful stuff, I'm sure .Net can likely do a lot of the things I need. But would I be any better off with another language? I don't think so. And I can use other languages through the ScriptManager anyway, while retaining access to all the libraries Java offers.
|
|
|
|
|
I think my favorite quotation about C is, "C is memory with syntactic sugar."
AFAIK it is original to Dennis Kubes and first appears here: http://denniskubes.com/2013/04/23/how-to-think-about-variables-in-c/[^]
The nice thing about C is you can almost always do whatever it is you want to do in C. The downside is, you can almost always do whatever it is you want to do an order of magnitude more easily in something else, even if that "something else" is C++. Nevertheless, that "something else" is almost universally just an interface, in some form or fashion, to C or C++ code.
|
|
|
|
|
C is a weakly hyped language.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
|
|
|
|
|
https://mail.python.org/pipermail/python-list/2002-November/141486.html
|
|
|
|
|
Let's start with this.
Name any other language other than C.
But there's a catch: the language's primary implementation must not currently be in C. So Java, JavaScript, Python don't qualify since they're canonical implementation is written in C.
Also, self-hosting doesn't count; in that case, it must not have been bootstrapped with C.
I'll start -- Pascal -- first version of Pascal was written in Fortran.
Next...
ken@kasajian.com / www.kasajian.com
|
|
|
|
|
Kenneth Kasajian wrote: Pascal
Aaaannnd... how do you work with very long strings? Very large structures*?
* Maybe only a problem with Turbo Pascal with its 64K per structure limit.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
With visual basic, actually most languages deal with strings better then C...
|
|
|
|
|
Better than Pascal I think you meant.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
No I mean it's a waste of time.
When you look at home long at takes to get a result and maintain that result visual basic wins every time.
|
|
|
|
|
I think I may not have been clear in my point because I don't understand what you're asking me.
I'm not saying Pascal is better than C or the other way around.
I'm saying Pascal is a language that was not originally written in C. It was written in Fortran, after which it was bootstrapped to be written in itself.
ken@kasajian.com / www.kasajian.com
|
|
|
|
|
It sure looks like you are proposing that Pascal is a better language than C, based on certain criteria. Pascal is indeed a very good language and I really liked it when I was using it in college, but I haven't used it since, and I can't even read/understand the code I have from that period.
Kenneth Kasajian wrote: Pascal is a language that was not originally written in C
Nor was C.
Kenneth Kasajian wrote: after which it was bootstrapped to be written in itself
As was C.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
No, you have completely missed the point of my message. Go back and re-read it.
What I am saying is that, a lot of people bash C but those same people don't realize that whatever language they prefer is probably written in C. So I challenged the readers to name a language that was not written in C.. because it's hard to do. Most new languages, VB, JavaScript, Python, Ruby all written in C.
However, there are languages not originally written in C, although they are old. Pascal is one, which is the one I mentioned to get the ball rolling.
You're being unnecessarily antagonistic without understanding, or taking the time to read, what I'm saying. I suggest you drop it.
ken@kasajian.com / www.kasajian.com
|
|
|
|
|
Sooo... your post is totally unrelated to Chris' prompt for discussion of languages that are or are not better than C. OK.
Kenneth Kasajian wrote: Go back and re-read it
I have read it many times, always in the context of the thread.
Kenneth Kasajian wrote: a lot of people bash C but those same people don't realize that whatever language they prefer is probably written in C
So what?
Kenneth Kasajian wrote: I challenged the readers to name a language that was not written in C
You could have made that clearer.
Kenneth Kasajian wrote: not originally written in C ... Pascal is one
Pascal pre-dates C slightly, it certainly pre-dates C's popularity. COBOL, Fortran, and BASIC also pre-date C.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Also to answer the more specific question, I don't think the language has anything to do with 64K limits, for strings, or otherwise. Those are all implementation details of specific compilers.
ken@kasajian.com / www.kasajian.com
|
|
|
|
|
Kenneth Kasajian wrote: implementation details of specific compilers
That may well be, but is it not part of the Pascal language spec that a string is limited to 255 characters because the length is stored in the first byte of the string?
I suppose not every implementation uses 8-bit characters, but it still imposes a definite limitation other than "available system resources".
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
