What is it with blank lines?

[Nigel Goodwin]

I'm not sure how C is "susceptible to interpretation", anyway. The code does what it says it does. Whether that's what the programmer intended is another question.

C isn't strongly structured, which makes it hard to read, and perfectly working code can be written so it's extremely difficult to read, even by the author.

 

[Torben]

C isn't strongly structured, which makes it hard to read, and perfectly working code can be written so it's extremely difficult to read, even by the author.

Yep. But there is no reason beyond laziness or inexperience to write bad code just because the compiler won't stop you*. Hard-to-read code is often the result of taking unnecessary shortcuts, and if a given problem requires a hairy solution, that's the time to comment and structure the hell out of it so you can remember what on Earth it's supposed to be doing when you come back to it in three months.

Bad code can be written in any computer language, just like bad prose can be written in any human language. Sure some languages help protect the rookies from common mistakes, but they're not always the best tool for the job at hand. I'm not going to apologize for C's shortcomings, but I'm not going to try to program a PIC in PHP, and I'm not going to try programming a web-based shopping cart in asm (or C, for that matter).


Torben

* I hit post and then remembered my favourite reason to write unreadable code: obfuscated code contests! They are fun. Very fun. And usually very educational to boot.

 

[aussiepoof]

Bad code really is due to laziness, lack of experience, or lack of education and sometimes an unfortunate combination of all three.

I find no compelling reason for C being singled out as worse than other languages other than the COBOL Cabal's(tm) campaign of fear and intimidation ;-)

Here's my favourite C++ put-down:

What's the difference between an extremely clever and sophisticated use of C++ versus a very badly written piece of code? Nothing... they're both entirely unreadable!

You may feel that's unfair... but in C++ one can abstract oneself up one's own arsehole! Besides, I met the guy who headed up the first ANSI C++ committee and his stories were just plain scary.

When it comes to the PIC... I needed to learn yet another set of assembler mnemonics like a I needed a hole in my head! I began using the 18F series as it is trivially more expensive than the 16 series and C18 gave me a productivity edge that was hard to ignore.

Just my $.02AU ;-)

P.

 

[Nigel Goodwin]

When it comes to the PIC... I needed to learn yet another set of assembler mnemonics like a I needed a hole in my head! I began using the 18F series as it is trivially more expensive than the 16 series and C18 gave me a productivity edge that was hard to ignore.

I've no problem whatsoever with C on the 18F series, because that's what the application notes use, and they provide a free compiler. But on the 16F series the application notes are written in assembler, so C programmers tend to not have a clue about the hardware they are trying to use.

 

[Torben]

I've no problem whatsoever with C on the 18F series, because that's what the application notes use, and they provide a free compiler. But on the 16F series the application notes are written in assembler, so C programmers tend to not have a clue about the hardware they are trying to use.

. . .unless they also speak assembler, which I think they should. I learned more about the hardware from a book on Intel 8086 assembler than just about anything else (well, we did have to learn MIPS assembly in uni). Helped me code up some damn fast Turbo Pascal stuff with inline asm.


Torben

 

[aussiepoof]

But on the 16F series the application notes are written in assembler, so C programmers tend to not have a clue about the hardware they are trying to use.

That's a ridiculously broad generalisation! Combined with a previous post in this thread one could draw the conclusion that you hate both C and C programmers... in any language, even PIC assembler, one can code very badly indeed!

I learned C well after I'd learned several assembly languages starting at the age of 13... and given I'm now 44 that's a long time ago I even learned one assembly language (LSI-11/PDP-11) while at University! So I agree with Torben that everyone needs to learn at least on assembly language though I wouldn't choose PIC as my first choice.

I'm NOT saying you shouldn't learn PIC assembler. Obviously if you're forced to use the 16 series then you have little option unless you're prepared to spend $$s on a compiler, and even then it's a questionable decision due to the poor performance that might ensue. You might also need to tune a routine or three on the 18F series comet to that.

I'm open to learning as many languages as I must though I now choose carefully which I need to add to the 10+ I already know. As Torben says, even PHP has advantages... though I doubt those extend to using it on a PIC

P.

 

[Nigel Goodwin]

That's a ridiculously broad generalisation! Combined with a previous post in this thread one could draw the conclusion that you hate both C and C programmers... in any language, even PIC assembler, one can code very badly indeed!

It's quite simple, to program a PIC you need to have a reasonable understanding of the hardware - assembler forces this on you - with C you've got to get the understanding of the hardware elsewhere.

As the 18F series provides application notes in C, it makes sense to use C for the 18F series - because what you need to know is available in C.

I've got nothing against C programmers, but you are correct that I don't like C itself.

There have been many posts on these forums about using C on various micro-controllers, and a great many of them are simply because the poster doesn't understand the hardware at all - you don't get the same questions from assembler users, because they are working at a lower level. The same problems occur with any high level language of course, it's just that most who post are using C - or perhaps the C compilers are lacking in documentation and sample programs?.

 

[Pommie]

I'm NOT saying you shouldn't learn PIC assembler. Obviously if you're forced to use the 16 series then you have little option unless you're prepared to spend $$s on a compiler, and even then it's a questionable decision due to the poor performance that might ensue. You might also need to tune a routine or three on the 18F series comet to that.

There is in fact a free compiler for the 16 series. The HiTech (an Aussie company) PicC-Lite. It is limited but for short projects is perfectly adequate.

It's funny, when I started this thread, it's only by chance that I used some C code as an example. White space in asm is even worse.

Another really annoying thing about pics and asm is that the (latest) template files seem to use a tab setting of 5 Before I can use them I have to run them through my code tidier program.

Mike.

 

[Torben]

It's quite simple, to program a PIC you need to have a reasonable understanding of the hardware - assembler forces this on you - with C you've got to get the understanding of the hardware elsewhere.

As the 18F series provides application notes in C, it makes sense to use C for the 18F series - because what you need to know is available in C.

I've got nothing against C programmers, but you are correct that I don't like C itself.

There have been many posts on these forums about using C on various micro-controllers, and a great many of them are simply because the poster doesn't understand the hardware at all - you don't get the same questions from assembler users, because they are working at a lower level. The same problems occur with any high level language of course, it's just that most who post are using C - or perhaps the C compilers are lacking in documentation and sample programs?.

Absolutely. Of course, C was never intended for microcontrollers, while assembler is a perfect fit for them.


Torben

 

[aussiepoof]

As for C programmers you meet in here not being hardware-aware... many are in fact computing students without compiler or architecture background, or merely hoping those here will write the projects for them Such people don't deserve to pass and I wouldn't employ them in a pink fit.

It is unfortunately possible to do a "computing" degree without learning either hardware architecture or compiler theory both of which would help them understand just how close to the hardware C and make the leap to using it on a PIC.

P.

 

[colin mac]

The subject of computer science doesn't have much to do with computer hardware, according to Wiki, people were thinking about changing its name to something else. Computer engineering on the other hand is all to do with the hardware.

 

[3v0]

You might ask why C is still with us after 35 years when other languages from that time period have either faded into obscurity or morphed to the point where they are unrecognizable.

In part it is because C is a mid level language.

To criticize C for being hard to read is misplaced. C is very much like any other procedural language.

The one exception is the use of pointers. C pointers are not an overly complex topic but can be challenging to the ADD crowd. Pointers are there because they are a fast, efficient, way of handling data. No apologies required.

Unreadability complaints should be directed at the guy who wrote the code. Regardless of the language readability is ultimately up to the programmer.

Based in two lesser known languages of B (see 1971) and BCPL (see 1967), C signified the next major step in programming languages as it also seemed to improve on the already popular Pascal. Although there is no direct link between C and Pascal, all of the features that made Pascal so popular were there, including CASE statements and pointers. Because of the extensive use of pointers, C was made fast and powerfull at the expense of being hard to read. None the less, the improvements it had over Pascal started a major wave of change from former Pascal users...
C is a powerful language for writing tight, fast, highly tuned code in a language far more portable than assembly. C is low-level enough to write device drivers, and high-level enough to write GUI libraries.

 

[Pommie]

The one exception is the use of pointers. C pointers are not an overly complex topic but can be challenging to the ADD crowd. Pointers are there because they are a fast, efficient, way of handling data. No apologies required.

Pointers are fantastic. Pointers on Pics are horrid. Four different types of pointers that aren't interchangable. That takes some time to get your head around.

I know this isn't pic specific but I just had to mention that quirk.

Mike.
P.S. What is the "ADD" crowd?

 

[3v0]

Pointers are fantastic. Pointers on Pics are horrid. Four different types of pointers that aren't interchangable. That takes some time to get your head around.

I know this isn't pic specific but I just had to mention that quirk.

Mike.
P.S. What is the "ADD" crowd?

Attention Deficit Disorder (ADD)

Mostly a bunch of hooey IMHO.

 

[futz]

https://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html

 

[Torben]

https://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html

Yow. That guy needs to apply his coding philosophy (which I only partly agree with) to his prose. Tipping point indeed.


Torben

 

[donniedj]

No need to take note to the billions of C related back and forth arguments on the web. All one has to do is take note of a single thread, like this one, to see how a language ought not to be the main discussion as opposed to what the language is attemping to accomplish. And I quote my first reply:

...and the written text becomes more effort consuming than the original reason for the code. It should solve problems and not add to it.

Thank goodness the F84 evolved else there would be billions of F84 is the only way and needs no review and change discussions littering the web. Thank goodness the rise and fall times of ICs evolved else the stack of propogation delay tolerances between devices would hinder all end products to max 10MHz speed. Thank goodness the power dissipation of components evolved else we all would be carrying big bulky end products where the bulk size and mass would be attributed the the needed heat sinks and fans. Than goodness the constant evolution of science results in more powerful machines to probe and expose the inner workings of biology and chemistry that makes medicines to keep the populous from dropping dead over a common cold. Thank goodness automobiles have advanced... oh wait no such a thing since the Model T barely grow pass 25 MPG since 1900s. Thank goodness the standard computer language has advanced... oh wait no such a thing since the '70s.

 

[aussiepoof]

No need to take note to the billions of C related back and forth arguments on the web. All one has to do is take note of a single thread, like this one, to see how a language ought not to be the main discussion as opposed to what the language is attemping to accomplish.

You know you're in trouble when you selectively quote your own post ;-)

Your first (elided) line reads:

This is partly why I dislike C, difficult to read, susceptible to too much interpretation...

Which is certainly makes the language the main focus of the discussion and not "what the language is attempting to accomplish" n'est ce pas?

The limited power of microcontrollers leaves them stuck back in the realm of 1970's languages as surely as any CPU running at less than the several gigahertz necessary to run post-1970's languages.

I am more productive in C than I would be in assembler and accept the *potential* performance hit. C is for me far less difficult to read than the PIC assembler's obscure mnemonics (the z80 mnemonics were easier and it *was* from the 70's!!!)

That said I grudgingly accept that many of the F84 die hards on here would prefer to program in assembler and may actually believe themselves to be more productive in it <sarcasm off>

P.

 

[Nigel Goodwin]

I am more productive in C than I would be in assembler and accept the *potential* performance hit. C is for me far less difficult to read than the PIC assembler's obscure mnemonics (the z80 mnemonics were easier and it *was* from the 70's!!!)

The mnemonics are only obscure to you, because you're used to Z80 - it really depends on what you're used to - also the RISC instruction set probably confuses you when you are used to the overly complicated Z80 instruction set. I came from a 6502 background, and had no trouble moving to PIC - but find Z80 as obscure as you find PIC!

I would suggest (and often do) if you come from a Z80 background, the AVR is probably a better choice than a PIC - but if you're using C, then it doesn't really matter.

 

[3v0]

...
The limited power of microcontrollers leaves them stuck back in the realm of 1970's languages as surely as any CPU running at less than the several gigahertz necessary to run post-1970's languages....

Well put.

The fact that we still use this 1970's language speaks to its robustness.