C is a better language than any language you care to name.
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
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.
-
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! :-D
Remind Me This - Manage, Collaborate and Execute your Project in the Cloud
-
Roger Wright wrote:
Then came C, and the death spiral of useful language development began.
It's like just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it. I've never made a programming language, but when I think of something like Ruby, which has some nice features, and then I think it's slow as dirt so I'll never use it. Just because CPUs are faster doesn't mean we can waste cycles, otherwise it's always a game of catch up.
Jeremy Falcon
-
...and c# is pointedly better! Hmmm... that doesn't work, sharp ---> points... but there isn't much use of pointers directly so that may be a bad analogy and therefore an even worse pun! However, with puns, the worst is the best so, yeah! :-)
- I would love to change the world, but they won’t give me the source code.
C# is better because # is composed of four pluses, therefore 4 times better than C: ++ ++
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
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.
-
I agree that compilers do produce good code: but they can't interpret what the author is trying to get the hardware to do and that means what they generate can be spectacularly inefficient. I had this problem with the ARM development kit (which was stupid money) - I needed to generate a specific wave output with my data to match the hardware it was interfacing to - and the C / Embedded C++ code just wouldn't do it no matter what I tried. In assembler it was trivial (but I eventually fitted a second PIC processor just to handle the interface - and coded that in C :laugh: )
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
OriginalGriff wrote:
but they can't interpret what the author is trying to get the hardware to do and that means what they generate can be spectacularly inefficient.
I agree, I love programming in Assembly, but I'm not sure I would beat the compiler, I'm just an enthusiast, don't program in it professionally. I also love C/C++ and was wondering if the ARM compiler you used support mixing up C and Assembly, like:
__asm
{
INC [EAX]
MOV EBX, [EAX]
...
}To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
:) :thumbsup: VB Code is actually very easy to understand but you're right, the code written by some people in VB is atrocious.
There are only 10 types of people in the world, those who understand binary and those who don't.
you can write bad code in any language, and as a programmer of 35 years ive seen more of it than u can shake a stick at, and as far as the VB v c# argument goes, it all compiles to the same IL anyway, the skill is in the programmers interpretation and solution, not for c# snobs to blindly say that its somehow 'better' - its a subjective argument
-
It's a good language, but in the modern world it's a bit...outclassed. If you want small tight code for embedded work, then assembler is probably a good bet - though C is very useful there, it does tend to generate bloated code compared to that produced by a good assembler programmer. The C code will be produced faster, but it'll need more RAM, more processor, more...in embedded work you don't always have the luxury! If you want desktop work, then C# or C++ have so many massive advantages in terms of OOPs design that there really isn't any comparison. It'll take you a lot longer to write the same app in C, and it'll almost certainly be harder to maintain. If you want to write a website, then good luck doing it in C... It's a product of it's time: it was designed to be "better than COBOL and FORTRAN". But the world has moved on, and the "competition" is a lot more sophisticated now.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
OriginalGriff wrote:
If you want small tight code for embedded work, then assembler is probably a good bet - though C is very useful there, it does tend to generate bloated code compared to that produced by a good assembler programmer.
Agree if you're code is WOUF (Write Once, Use Forever). The choice depends on what the engineering constraints are. If I want to accommodate the hardware people having an upgrade path, going from an 8051 to an 80186 say (to use an archaic example), then portability and reusability are the constraints and C makes much more sense. I really don't want to do the SSDD shuffle for the rest of my egregiously unnatural life. :) ("bloated code" used in reference to "C", Gracie? Oh! I get it. It's a pesky relativity thing.)
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
-
C# is better because # is composed of four pluses, therefore 4 times better than C: ++ ++
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
you can write bad code in any language, and as a programmer of 35 years ive seen more of it than u can shake a stick at, and as far as the VB v c# argument goes, it all compiles to the same IL anyway, the skill is in the programmers interpretation and solution, not for c# snobs to blindly say that its somehow 'better' - its a subjective argument
_WinBase_ wrote:
he skill is in the programmers interpretation and solution, not for c# snobs to blindly say that its somehow 'better' - its a subjective argument
+5. I agree. :thumbsup:
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
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
-
OriginalGriff wrote:
but they can't interpret what the author is trying to get the hardware to do and that means what they generate can be spectacularly inefficient.
I agree, I love programming in Assembly, but I'm not sure I would beat the compiler, I'm just an enthusiast, don't program in it professionally. I also love C/C++ and was wondering if the ARM compiler you used support mixing up C and Assembly, like:
__asm
{
INC [EAX]
MOV EBX, [EAX]
...
}To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
Yes: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205j/Cihccdja.html[^]
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
Yes: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205j/Cihccdja.html[^]
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
Awesome, thanks
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
-
Roger Wright wrote:
Then came C, and the death spiral of useful language development began.
It's like just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it. I've never made a programming language, but when I think of something like Ruby, which has some nice features, and then I think it's slow as dirt so I'll never use it. Just because CPUs are faster doesn't mean we can waste cycles, otherwise it's always a game of catch up.
Jeremy Falcon
Jeremy Falcon wrote:
Just because CPUs are faster doesn't mean we can waste cycles, otherwise it's always a game of catch up.
True, only if you're doing something extremely CPU-bound. However, the vast majority of current application are highly user-interactive, where , by far, the really speed bottleneck is the user.
Truth, James
-
Discuss. I've just read The Unreasonable Effectiveness of C[^] and decided to outsource my ranting response to it
cheers Chris Maunder
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...
-
Roger Wright wrote:
Then came C, and the death spiral of useful language development began.
It's like just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it. I've never made a programming language, but when I think of something like Ruby, which has some nice features, and then I think it's slow as dirt so I'll never use it. Just because CPUs are faster doesn't mean we can waste cycles, otherwise it's always a game of catch up.
Jeremy Falcon
Jeremy Falcon wrote:
just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it
The assembly guys said the same thing of C. I'd be willing to bet the patch-cable guys said the same thing of assembly. Do you really want to program your current applications using patch cables? How about assembler? It isn't (or shouldn't) be about adding cool-sounding technical layers, each language evolution allows the computer to do more of the mechanical grunt work, freeing us to spend more time doing the creative part. I don't know about you, but I really appreciate that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Jeremy Falcon wrote:
just as soon as computers get faster, we want to make the languages more bloated. That way we never enjoy the new speed, we simply keep things the same and have a new cool shiny layer that sounds technical to toss on top of it
The assembly guys said the same thing of C. I'd be willing to bet the patch-cable guys said the same thing of assembly. Do you really want to program your current applications using patch cables? How about assembler? It isn't (or shouldn't) be about adding cool-sounding technical layers, each language evolution allows the computer to do more of the mechanical grunt work, freeing us to spend more time doing the creative part. I don't know about you, but I really appreciate that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
patbob wrote:
It isn't (or shouldn't) be about adding cool-sounding technical layers, each language evolution allows the computer to do more of the mechanical grunt work, freeing us to spend more time doing the creative part. I don't know about you, but I really appreciate that.
I totally agree with this, but only if the evolution gives us a real gain. Something like sugar coating at the price of performance I don't agree with. A legitimate paradigm shift I could understand.
Jeremy Falcon
-
patbob wrote:
It isn't (or shouldn't) be about adding cool-sounding technical layers, each language evolution allows the computer to do more of the mechanical grunt work, freeing us to spend more time doing the creative part. I don't know about you, but I really appreciate that.
I totally agree with this, but only if the evolution gives us a real gain. Something like sugar coating at the price of performance I don't agree with. A legitimate paradigm shift I could understand.
Jeremy Falcon
Jeremy Falcon wrote:
sugar coating at the price of performance I don't agree with
Often, what has appeared to me at first as a sugar coating, turns out to be a paradigm shift in thinking that I didn't grasp. Not always, but a lot of times.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
