View previous topic :: View next topic |
Author |
Message |
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Wed Jul 04, 2012 2:39 pm |
|
|
Wow! No comments?? Hahahah...
Ok. I figured it would be interesting to see people's reactions and how it might relate to embedded C compilers like CCS.
But that's ok -- read away!
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Wed Jul 04, 2012 3:07 pm |
|
|
Thanks for the link. I read the article a few days ago, it is good but I didn't feel like it needed more comments.
To me the C language is a tool and I try to use the best tool for the job at hand. Sometimes that is C, other jobs require different tools (languages).
To sum up the article: C is an old language but still has it strong points. |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Wed Jul 04, 2012 5:56 pm |
|
|
ckielstra wrote: | C is an old language but still has it strong points. |
Just like wrenches. New and "better" wrenches are invented and sold every day. But the old basic forged steel open end wrench still sells very well and is found in most every mechanics toolbox. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Wed Jul 04, 2012 7:12 pm |
|
|
Heh. Yea... I'm a big fan of the "right tool for the job"...
And yes.. probably not much more needed to add...
Ok - I'll be quiet.. hah
Cheers,
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Thu Jul 05, 2012 1:30 am |
|
|
Right tool for the right job...
That rather depends on what jobs you're trying to do. Would I write a Windows application in C today? No. I wouldn't have even ten years ago, but did 15 years ago. So many "better" languages are available for that job today. Would I write a platform independant portable app in C? Not a chance. Would I take part in a team writing large scale enterprise C apps? No. For all these, and the like, I'd use something else, something "better", i.e. more suited to the task. Something object orientated for certain.
Would I write a PIC app using C#? Not a hope? C++ No. Maybe I'd just about contemplate C++ for a small to mid size app for ARM... maybe, but for a very limited processor like the PIC? No, totally inappoproriate. For small to medium scale embedded apps, it's C all the way because it provides the low-level control that's required to be able to easily leverage the platform. I don't care about portability, even between different processors of the same family: they all need something different. I'm happy to have to use processor/C implementation specific extensions to deal with this stuff, something "better" more modern languages seek to totally avoid in a general move towards standardisation, portability and platform independance. Great when there's tons of processing power and memory to use (and waste generally...) but when every cycle and byte matters then C still is the right and best tool for the job.
In none of my embedded projects for ARMs as well as PICs have I ever used dynamic memory. In a previous job I even outlawed it in the C style guide I wrote for the company. Most object orientated languages rely on dynamic memory for literally everything, its the core on which the concept is based. The trouble is mainly the lack of control of that dynamic allocation. Fine when there's plenty of memory to use, not fine when there's little more, than a 1970's era smaller minicomputer. Therefore the older, statically allocated C scores big time in such situations. Then there's the overheads associated with object creation. For garbage collection the situation is even worse: just where are all those reference counts and type details stored? How much time is used but the collector? It can take tens of bytes to store a single byte. On a PC with GHz clock rates and Gbyte memories who really cares? But on a PIC, as on many embedded processors, its dreaming to think that could be appropriate.
I think the article was written by and addressed to PC programmers, who frankly often appear to think that PCs are the only computing platforms. The article only just mentioned embedded programming in which C remains, and is likely to for the foreseeable future, THE language of choice. Nothing has come along that looks even possibly able to replace it; certainly nothing better has.
RF Developer |
|
|
gpsmikey
Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA
|
|
Posted: Thu Jul 05, 2012 8:48 am |
|
|
Right tool, right job as others have said, but I still think my favorite comment was from Steve Ciarcia (orig Byte Mag, now founder of Circuit Cellar) when he said "my favorite programming language is solder" :-)
mikey _________________ mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
RE: |
Posted: Thu Jul 05, 2012 11:56 pm |
|
|
C is the best high level language for PIC processors, as the code is highly readable and can be easily ported.
But for PCs there are better languages than C or even Basic.. |
|
|
|