|
'C' was its grade as a a programming language.
C++ got a grade of C--
|
|
|
|
|
I agree. Granted that may be because I don't care to name any others.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Chris, I am afraid you have the wrong information.
C is not a language, it's an alphabet.
|
|
|
|
|
Rutvik Dave wrote: C is not a language, it's an alphabet.
Actually, it is just one element in a set called an "alphabet." We also have a 'D' and 24 other members in the set.
Will Rogers never met me.
|
|
|
|
|
... and the English language has killed my joke, again!
|
|
|
|
|
The vast majority of the software out there is written in C. The vast majority of software out there has crippling flaws, are out of budget and abandoned after tried to use. QED
|
|
|
|
|
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.
|
|
|
|
|