C is a better language than any language you care to name.
-
Chris Maunder wrote:
Discuss.
Arrays decay into pointers.[^] X| Or, for more details: C's Biggest Mistake[^]
Bushwa! That is one of its greatest strengths! There were only three mistakes in C, and one was fixed in C89 (if I recall correctly). The other two continue to plague us.
You'll never get very far if all you do is follow instructions.
-
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...
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.
-
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
:thumbsup: 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.
-
D language[^] is better. It combines the simplicity of C and avoids all the kludginess of C++ for the same elegance you see in C#. Plus...no *.H files or #defines !!!! :) Plus garbage collection!
DaveX86 wrote:
Plus...no *.H files or #defines
The can have my
# defines when they pry them from my cold, dead hands.You'll never get very far if all you do is follow instructions.
-
Joe Woodbury wrote:
The declaration does and thus the precompiler) and sizeof(), but not the array itself.
Rather certain that the precompiler is in fact part of the language since it is in fact part of the specification for the language. If you wish to another definition for "language" than the specification then you would need to provide one. And if one wants to be specific then at least in my edition of "C Programming Language 2nd Edition" the preprocessor is part of the main language definition (not an appendix) and the section specifically starts off with "C provides certain language facilities by mean of a processor". So if K&R thinks it is part of the language I am going to take their word for it. Or perhaps to put in in another perspective, limiting oneself to just the "language" then C is in fact useless, since one cannot in any practical way do anything useful with the "language". Thus it can't, again in a practical, real world way, be "better" than anything else.
jschell wrote:
Rather certain that the precompiler is in fact part of the language
Yes, and as he said in his response, he didn't say otherwise. Some points I'd like to make are: A language is defined by its compiler (not the other way around). DMR probably could have made C without a pre-processor; I see no reason that C has to have a pre-processor other than that it does have a pre-processor. The existence of D and C# may support this view. I have seen (I don't remember where) at least one argument that the C pre-processor acts on a different language than the C compiler does; and I am in about 90% agreement with that point of view. I like the C pre-processor; it's really just a text processing utility -- it can be used for purposes other than its primary usage. (I even use it with C# -- Implanting Common Code in Unrelated Classes[^]) Unfortunately, it also has some functions (e.g. sizeof) that are tightly bound to C. :sigh:
jschell wrote:
limiting oneself to just the "language" then C is in fact useless, since one cannot in any practical way do anything useful with the "language"
You may be arguing that the language is pretty limited without libraries, and that is quite true, very little can be accomplished without at least printf -- I have written a simple program that calculates a value and returns it from main, simply to demonstrate that something, no matter how pointless, can be done without linking in any libraries. However, I think the article was also pointing out the ease with which a developer can leverage a multitude of libraries with C. Just the other week I was playing with ODBC, and linking in only the ODBC libraries and not the "standard C libraries". Of course, doing so still requires the pre-processor, as the Creator intended.
jschell wrote:
I am going to take their word for it
Soooo... if Microsoft says that VB is the World's Greatest Language.... ? :suss:
-
DaveX86 wrote:
Plus...no *.H files or #defines
The can have my
# defines when they pry them from my cold, dead hands.You'll never get very far if all you do is follow instructions.
-
Colborne_Greg wrote:
the "with" operator
...is useless filth. X|
You'll never get very far if all you do is follow instructions.
Which is more readable to everyone, and which uses less lines?
Public Shared Function RotateStream(stream As IsolatedStorageFileStream, angle As Int16) As WriteableBitmap stream.Position = 0 Dim bitmap = New BitmapImage() bitmap.SetSource(stream) Dim WriteableBitmapSource = New WriteableBitmap(bitmap) Dim WriteableBitmapTarget As WriteableBitmap Dim Target As Int64 With WriteableBitmapSource Select Case angle Case 360 : Return WriteableBitmapSource Case 180 : WriteableBitmapTarget = New WriteableBitmap(.PixelWidth, .PixelHeight) Case Else : WriteableBitmapTarget = New WriteableBitmap(.PixelHeight, .PixelWidth) End Select For xAxis = 0 To .PixelWidth For yAxis = 0 To .PixelHeight Select Case angle Case 90 Target = (.PixelWidth - yAxis - 1) + (xAxis \* WriteableBitmapTarget.PixelHeight) WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth) Case 180 Target = (.PixelWidth - xAxis - 1) + (.PixelHeight - yAxis - 1) \* .PixelWidth WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth) Case 270 Target = yAxis + (.PixelWidth - xAxis - 1) \* WriteableBitmapTarget.PixelWidth WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth) End Select Next Next End With Return WriteableBitmapTarget End Functionversus without
public static WriteableBitmap RotateStream(IsolatedStorageFileStream stream, int angle)
{
stream.Position = 0;
if (angle % 90 != 0 || angle < 0) throw new ArgumentException();int target; BitmapImage bitmap = new BitmapImage(); bitmap.SetSource(stream); WriteableBitmap wbSource = new WriteableBitmap(bitmap); if (angle % 360 == 0) return wbSource; WriteableBitmap wbTarget = null; if (angle % 180 == 0) { wbTarget = new WriteableBitmap(wbSource.PixelWidth, wbSource.PixelHeight); } else { -
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...
-
Which is more readable to everyone, and which uses less lines?
Public Shared Function RotateStream(stream As IsolatedStorageFileStream, angle As Int16) As WriteableBitmap stream.Position = 0 Dim bitmap = New BitmapImage() bitmap.SetSource(stream) Dim WriteableBitmapSource = New WriteableBitmap(bitmap) Dim WriteableBitmapTarget As WriteableBitmap Dim Target As Int64 With WriteableBitmapSource Select Case angle Case 360 : Return WriteableBitmapSource Case 180 : WriteableBitmapTarget = New WriteableBitmap(.PixelWidth, .PixelHeight) Case Else : WriteableBitmapTarget = New WriteableBitmap(.PixelHeight, .PixelWidth) End Select For xAxis = 0 To .PixelWidth For yAxis = 0 To .PixelHeight Select Case angle Case 90 Target = (.PixelWidth - yAxis - 1) + (xAxis \* WriteableBitmapTarget.PixelHeight) WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth) Case 180 Target = (.PixelWidth - xAxis - 1) + (.PixelHeight - yAxis - 1) \* .PixelWidth WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth) Case 270 Target = yAxis + (.PixelWidth - xAxis - 1) \* WriteableBitmapTarget.PixelWidth WriteableBitmapTarget.Pixels(Target) = .Pixels(xAxis + yAxis \* .PixelWidth) End Select Next Next End With Return WriteableBitmapTarget End Functionversus without
public static WriteableBitmap RotateStream(IsolatedStorageFileStream stream, int angle)
{
stream.Position = 0;
if (angle % 90 != 0 || angle < 0) throw new ArgumentException();int target; BitmapImage bitmap = new BitmapImage(); bitmap.SetSource(stream); WriteableBitmap wbSource = new WriteableBitmap(bitmap); if (angle % 360 == 0) return wbSource; WriteableBitmap wbTarget = null; if (angle % 180 == 0) { wbTarget = new WriteableBitmap(wbSource.PixelWidth, wbSource.PixelHeight); } else {OK, now use with to copy values between two instances.
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.
-
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.
-
OK, now use with to copy values between two instances.
You'll never get very far if all you do is follow instructions.
You can't think outside the box can you. Usually I would do something like this to copy a class Public function copy(byval ojbectName as objectType) as objectType Return objectName end function There are many ways of getting values from one structure to another, not just with the use of methods. Lastly this points out that you should be utilizing different methods of programming to get a result instead of manually coding each line out.
-
You can't think outside the box can you. Usually I would do something like this to copy a class Public function copy(byval ojbectName as objectType) as objectType Return objectName end function There are many ways of getting values from one structure to another, not just with the use of methods. Lastly this points out that you should be utilizing different methods of programming to get a result instead of manually coding each line out.
Colborne_Greg wrote:
to copy a class
Not copying everything; just some values.
You'll never get very far if all you do is follow instructions.
-
Colborne_Greg wrote:
to copy a class
Not copying everything; just some values.
You'll never get very far if all you do is follow instructions.
If you only want a few of the values use visual basic reflection.
-
printf("Why is that then?");
// No comment!
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[^]
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
Funny, I thought the language to-go was Fortran?[^] :doh: Now I'm waiting on a corresponding article about COBOL ;P
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[^]
-
Visual basic 2013. It can utilize every C, C++, and C# library. Plus it looks pretty. For example the "with" operator is in Visual basic but is not in C.
Have you read the article?
Colborne_Greg wrote:
It can utilize every C, C++, and C# library.
C can be plugged into any application in any language. The author is aware that C itself lacks libraries and he does mention it. So what was your point again?
Colborne_Greg wrote:
Plus it looks pretty.
Ah that. :doh: Ok, seriously. If you meant it has a better readability, that was mentioned by the author, too. So, again the question, what was your point?
Colborne_Greg wrote:
For example the "with" operator is in Visual basic but is not in C.
And it's in Pascal. So what? Again, the author made a point that other languages offer more (and often more complex) language elements - but that doesn't deterr him from listing a number of advantages of the language C that you failed to address entirely. Disclaimer: I don't actually agree with the article. I just wanted to point out that the article already pointed out or implied everything you said, and you did nothing to argue against it. (if that was your purpose)
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[^]
-
If you only want a few of the values use visual basic reflection.
reflection ???!!! :confused: :omg:
You'll never get very far if all you do is follow instructions.
-
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:
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.).
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[^]
-
Michael Kingsford Gray wrote:
the monumentally bone-headed notion that CASE statements should cascade through without a BREAK
:thumbsup: 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.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[^]