C is a better language than any language you care to name.
-
Your signature has a line about GOTO The goto fail example is a major fail in general for the C language. The goto is the first thing every programmer should avoid, but in this example the GOTO's are used correctly, but its a limitation of the C language (one of the dumbest things in history I might add) Visual basic .net is C with English words and no bracket issue, the GOTO fail would never had been an issue in VB.
You've completely missed my point. My sig should have made it obvious I abhor the use of goto. I merely pointed out a possible reason why
casemay have been specified the way it is. Not that I wouldn't like to bangotofrom the language entirely. And not that I would miss theswitchstatement for that matter (not much anyway). It was just a statement about the consistency of the language as a whole. As for your love of Basic - to each their own. It certainly has it's use for certain kind of applications. Me, I've been working on processing-intensive applications for decades, and no Basic dialect whatsoever, not even the compiled ones, would ever have served the purpose. That said, I'll remove the link from my sig: as you've pointed out, the main reason for the problem isn't so much the use of goto - it is the fact that braces (or other block markers) are only optional after control statements, combined with an unlucky duplicate line of code - that this line contains agotocommand is just happenstance, many other commands would have caused havoc as well. On a sidenote:Colborne_Greg wrote:
Visual basic .net is C with English words and no bracket issue, the GOTO fail would never had been an issue in VB.
Which part of
go toisn't english? Just wondering...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) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
Maybe, but
breakdoesn't affect agoto. And I have never used agotoin C.You'll never get very far if all you do is follow instructions.
My point was that a series of
casestatements resembles a series ofgotojump labels, and therefore there is an expectation for the flow of execution to continue, even past the next 'label'. Thebreakcommand isn't associated to thecasestatement, it is associated to theswitchblock.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)
-
My point was that a series of
casestatements resembles a series ofgotojump labels, and therefore there is an expectation for the flow of execution to continue, even past the next 'label'. Thebreakcommand isn't associated to thecasestatement, it is associated to theswitchblock.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.
-
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.
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.
-
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.
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.
-
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.
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.
-
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.
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.
-
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.
-
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.
Okay, although it's true that one can implement Pascal differently, you're right that it's limited to 64K (or 32K) in length for strings. But I really don't think that's a good example of Pascal's inferiority over C. There's advantages to counted-strings, and I've worked in environments where actually simulated Pascal strings in C for efficiency (i.e. you can easily get to the length). COM BSTRs use a similar structure, but store 32-bit lengths. And the reason I don't think it's a limitation is because if you needed a string that long, C's null-terminated string is hardly preferable. You likely need a different data-structure (rope, array of strings) to do whatever you're doing anyway. Or, more likely, it's that big, it's probably a memory buffer that you'd manage using address and count. As a reminder, my initial post was not stating Pascal is better than C. It was to point out that many of today's languages are written in C.
-
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.
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.
-
Okay, although it's true that one can implement Pascal differently, you're right that it's limited to 64K (or 32K) in length for strings. But I really don't think that's a good example of Pascal's inferiority over C. There's advantages to counted-strings, and I've worked in environments where actually simulated Pascal strings in C for efficiency (i.e. you can easily get to the length). COM BSTRs use a similar structure, but store 32-bit lengths. And the reason I don't think it's a limitation is because if you needed a string that long, C's null-terminated string is hardly preferable. You likely need a different data-structure (rope, array of strings) to do whatever you're doing anyway. Or, more likely, it's that big, it's probably a memory buffer that you'd manage using address and count. As a reminder, my initial post was not stating Pascal is better than C. It was to point out that many of today's languages are written in C.
Kenneth Kasajian wrote:
I don't think it's a limitation
Perhaps you just don't find the limit to be a hindrance. I never had any trouble with it either, but I never had to use Pascal to do real-world development. Just as .net strings are limited to 2GB -- it's a limit, but it hasn't yet been a hindrance.
Kenneth Kasajian wrote:
C's null-terminated string is hardly preferable
They certainly have some disadvantages, but at least they're easy to work around.
You'll never get very far if all you do is follow instructions.
-
You've completely missed my point. My sig should have made it obvious I abhor the use of goto. I merely pointed out a possible reason why
casemay have been specified the way it is. Not that I wouldn't like to bangotofrom the language entirely. And not that I would miss theswitchstatement for that matter (not much anyway). It was just a statement about the consistency of the language as a whole. As for your love of Basic - to each their own. It certainly has it's use for certain kind of applications. Me, I've been working on processing-intensive applications for decades, and no Basic dialect whatsoever, not even the compiled ones, would ever have served the purpose. That said, I'll remove the link from my sig: as you've pointed out, the main reason for the problem isn't so much the use of goto - it is the fact that braces (or other block markers) are only optional after control statements, combined with an unlucky duplicate line of code - that this line contains agotocommand is just happenstance, many other commands would have caused havoc as well. On a sidenote:Colborne_Greg wrote:
Visual basic .net is C with English words and no bracket issue, the GOTO fail would never had been an issue in VB.
Which part of
go toisn't english? Just wondering...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) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
I programmed Unidex in visual basic, there isn't a conditional statement involved in retrieving a value from a serialized file (no sql) it can handle creating 8 million records an hour, and can read 2.3 billion records an hour.
-
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
goto, I saidgotojump labels - that is a world of a difference! How is the followingswitch(a) {
case 1:
...
case 2:
...
}different from
on a goto label1, label2
label1:
...
label2:
...? The multilabel
on ... gotovariant 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)
-
I programmed Unidex in visual basic, there isn't a conditional statement involved in retrieving a value from a serialized file (no sql) it can handle creating 8 million records an hour, and can read 2.3 billion records an hour.
:zzz: You didn't get the point of anything I said. But nevermind. I've got it that you prefer VB from your first posting. That's fine. Have a nice day.
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)
-
Because you chose to ignore the part that I specifically underlined. I didn't say
goto, I saidgotojump labels - that is a world of a difference! How is the followingswitch(a) {
case 1:
...
case 2:
...
}different from
on a goto label1, label2
label1:
...
label2:
...? The multilabel
on ... gotovariant 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 :-D . When I learned BASIC we didn't have labels, only line numbers.
ON a GOTO 100 , 200Also, the lines/labels could be anywhere, not grouped together as with CASE statements. Ergo, to me aswitchdoesn't resemble anON/GOTOat 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.
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
After programming for 20+ years (on and off) I have recently come to the disappointing conclusion that I don't have a favorite language. Starting on the C64 and BBC Micro, I liked the way everything was self-contained: it was easy to make sounds or move graphics without importing alien libraries, but it was awkward having to resort periodically to assembly or machine code! Moving on to a bit of C, then C++ and some JS I got to like C++, but all the memory leaks and lack of strict object-orientation led me to C# with all its shiny promises. Trouble is, ASP.NET has changed too fast for me to keep up (I don't have the time) and often it feels like using an intercontinental warhead to crack a nut. As for desktop apps written in C# - who wants to install .NET just to run one small app? By this point I was growing fond of Java - it smoothly implemented interfaces without abstract things like delegates - the syntax of which is so bad they have become increasingly abstract to compensate (i.e. anonymous methods). Java had none of these issues, but then came LINK which made these awkward constructs somehow vital. Anyway, Java isn't as easy to run online as it was originally intended to be (rather like C#) - all that OOP made it a bit clumsy for browsers, so I went back to JS when HTML 5 came along. I still haven't found a satisfactory way of generating simple sounds and playing them back smoothly (double-buffering in C# just didn't work on my machine for some reason) and now I find myself longing for my C64 again! I seem to be back where I started, only slightly disillusioned (and quite a bit older).