Why I hate c

[Alan Anderson]

void User_Autonomous_Code(void)
{
while (autonomous_mode) /* DO NOT CHANGE! */
{
if (statusflag.NEW_SPI_DATA) /* 26.2ms loop area */
{
Getdata(&rxdata); /* DO NOT DELETE, or you will be stuck here forever! */
/* Add your own autonomous code here. */
// [state machine implementation]
Putdata(&txdata); /* DO NOT DELETE, or you will get no PWM outputs! */
}
Process_Data_From_Local_IO;
}
}

It took me four hours last night to figure out why Process_Data_From_Local_IO never gets called.

[roknjohn]

I totally agree. I'm a professional software engineer with 20 years experience. C is such an unforgiving language. It is difficult to read, easy to make simple errors in syntax, and most compilers won't warn you about things like:

Process_Data_From_Local_IO;

Or, the one that gets me all the time:

if (myvar=0)
{
dosomething();
}

[Dave Flowerday]

if (myvar=0)
{
dosomething();
}

If you get yourself in the habit of specifying the constant first then the variable, you'll produce a compiler error if you only have 1 = sign. Our coding standard at work specifies this as a requirement to catch at least some of these types of errors. The above code would then become:

if(0 = myvar)
{
dosomething();
}

which will give an error. Doesn't solve all the problems but it at least allows you to catch a few simple mistakes...

[deltacoder1020]

also the reason


Process_Data_From_Local_IO;


does not give an error is because it is a valid statement. it evaluates to the memory address of the Process_Data_From_Local_IO function. Now you might ask, "well, why doesn't if give a warning at least, because the line doesn't do anything"? Well, then you wouldn't be able to use the following code without a warning either:


x++;


because technically, that line just as much of "nothing". it evaluates to the value of x, and then increments it.

[Ryan M.]

Using a utility like Lint can help with those sorts of errors. Just run it and it will warn you of anything that you probably didn't mean to do.

[Astronouth7303]

Code is only as readable as you make it. Make names self-explainatory (or close to it). I tought myself VB, and my naming conventions are based on that.

[gnormhurst]

Using a utility like Lint can help with those sorts of errors. Just run it and it will warn you of anything that you probably didn't mean to do.

Does the Microchip compiler have an option like Gnu's gcc "-Wall" (warnings: All)? I really miss -Wall. It catches when printf has the wrong number or type of arguments, warns about "if ( x = 0 )", and points out unused variables, for example.

I'm going to a talk by Brian Kernighan next week -- I'll give him your regards! ;)

[Mark McLeod]

Does the Microchip compiler have an option like Gnu's gcc "-Wall" (warnings: All)? I really miss -Wall. It catches when printf has the wrong number or type of arguments, warns about "if ( x = 0 )", and points out unused variables, for example.

I'm going to a talk by Brian Kernighan next week -- I'll give him your regards! ;)In MPLAB look under Project->Build Options...->Project
under the MPLAB C18 tab "Diagnostics level" you can chose "errors, warnings and messages" and get more dianostic info, but it won't catch it all.

[Alan Anderson]

I'm going to a talk by Brian Kernighan next week -- I'll give him your regards! ;)
If I recall correctly, K&R page 101 gives the derivation for the "canonical" string copy statement.

while(*t++ = *s++);

That's part of why I find c such an uncomfortable language to use. It wants me to think like a compiler. It encourages the use of simple shortcuts that a moderately well-designed compiler should be doing for me. My code is full of explicit tests for zero/nonzero. Although I know I could replace

if ( my_timer == 0 )

with

if ( !my_timer )

and get the same job done, I'm a programmer, and I want to be free to focus on the algorithms and let the compiler care about the details of the bits and bytes. Coding can be, and should be, done by machines.

And don't get me started on how numeric operations are performed using the smallest size that the operands will fit in, leaving me to worry about overflows even if I know the end result of an expression will always fit in the variable I'm putting it in. Oops, too late...

I apologize. It was a late night last night. And I must admit that the tool does get the job done, with little to no fuss, as long as I remember to use it correctly.

[gnormhurst]

while(*t++ = *s++);


Yeah, that's just obscene. There are still programmers who seem to have the anti-social impulse to create clever, opaque code, so they can feel smug as the rest of the world struggles to understand what the heck it does.

[Ryan M.]

In MPLAB look under Project->Build Options...->Project
under the MPLAB C18 tab "Diagnostics level" you can chose "errors, warnings and messages" and get more dianostic info, but it won't catch it all.Personally, I find the messages more annoying then helpful. Some people might like it, though.

[Ryan M.]

If I recall correctly, K&R page 101 gives the derivation for the "canonical" string copy statement.

while(*t++ = *s++);

That's part of why I find c such an uncomfortable language to use. It wants me to think like a compiler. It encourages the use of simple shortcuts that a moderately well-designed compiler should be doing for me. My code is full of explicit tests for zero/nonzero. Although I know I could replace

if ( my_timer == 0 )

with

if ( !my_timer )

and get the same job done, I'm a programmer, and I want to be free to focus on the algorithms and let the compiler care about the details of the bits and bytes. Coding can be, and should be, done by machines.

And don't get me started on how numeric operations are performed using the smallest size that the operands will fit in, leaving me to worry about overflows even if I know the end result of an expression will always fit in the variable I'm putting it in. Oops, too late...

I apologize. It was a late night last night. And I must admit that the tool does get the job done, with little to no fuss, as long as I remember to use it correctly.As C/C++ is the language I know best, I don't find a statement like that very confusing. But I agree with you that it should be clear, not "clever." Even though I could read that perfectly, if anyone else looks at my code they might not be able to. It is better to write clear, obvious code, than to have a single line that does the exact same thing.

--EDIT--
P.S. Sorry for double posting there. :)

[deltacoder1020]

If I recall correctly, K&R page 101 gives the derivation for the "canonical" string copy statement.

while(*t++ = *s++);

That's part of why I find c such an uncomfortable language to use. It wants me to think like a compiler. It encourages the use of simple shortcuts that a moderately well-designed compiler should be doing for me.


hence the reason for the string.h functions in any standards-compliant C distro. MPLAB is far from standards, as it is basically on the bare minimum needed to program a robot (which isn't going to be doing much with strings).


My code is full of explicit tests for zero/nonzero. Although I know I could replace

if ( my_timer == 0 )

with

if ( !my_timer )

and get the same job done, I'm a programmer, and I want to be free to focus on the algorithms and let the compiler care about the details of the bits and bytes. Coding can be, and should be, done by machines.


i'll agree with you on that - MCC18 is a fairly sucky compiler. there are, however, quite a few C compilers that do perform optimizations such as this. don't blame the language, blame the compiler.


And don't get me started on how numeric operations are performed using the smallest size that the operands will fit in, leaving me to worry about overflows even if I know the end result of an expression will always fit in the variable I'm putting it in. Oops, too late...


again, a fault of MCC18, not C itself.

all in all, most of the faults you described are with this specific implementation of C. Chances are you would find programming for a regular computer with C much nicer.

[velocipenguin]

C is one of my favorite languages. While it can be VERY unforgiving at first, it's not too difficult once you get used to the language. I used to make lots of simple errors (forgetting parentheses, failing to end statements with semicolons, etc.), but the frequency of that sort of error decreases significantly once correct C syntax becomes habitual. C is tremendously powerful without being nearly as arcane as assembler; it allows one to easily combine useful low-level operations with high-level procedural and algorithmic code in a syntax that's clear and human-readable. It took me a long time to get used to C, but I now find that it's my language of choice for many programming tasks. Don't blame the language because you made an error. Certain errors may look like obvious mistakes once you find them, but those errors are often similar or identical to operations that one might perform in order to obtain useful results.

For example:

if(file_handle = fopen("foo.bar","r"))
{
herr_doktor_function();
}


That's a valid use of the single equality sign in a conditional. It checks to make sure the fopen was successful before executing herr_doktor_function. This could be written in a slightly clearer way, but it's a good example of why C has such lenient error-checking.

[Alan Anderson]

Don't blame the language because you made an error. Certain errors may look like obvious mistakes once you find them, but those errors are often similar or identical to operations that one might perform in order to obtain useful results.
Actually, that's exactly why I dislike c as much as I do. A small error in typing results in something which is both valid code and completely different from what I intended. A common and easily made error should be noticed as an error by the compiler.

Yes, c is very capable. It is also very terse. In sufficiently skilled hands, that's a powerful combination. In just slightly less skilled hands, it's a recipe for subtle errors. As for me, I prefer to use a language which is a bit less terse, with syntax that doesn't make it quite so easy to shoot yourself in the foot.

[Astronouth7303]

What do you mean by "single equality sign in a conditional"? Isn't = an assignment symbol?

[telkanuru]

Your inability to detect problems is in all likelyhood related to the self rather than the language. Personally, if I can't solve a C/C++ bug within 5-10 minutes, I ask someone who also knows it to look over the language, because they find things I miss. And good compilers do make a good deal of difference. Personally, I like C++ because I like object-oriented language, but C is better than visual whatever they were using before. You can do so much more with so much less. Plus, knowing it has broader practical applications.

[Astronouth7303]

There's a way around that (sort of): Something I call "psuedo-objects". Basically, For each instance of the object, Copy the code and declarations and rename. And replace dots with underscores. Object_Procedure

[velocipenguin]

What do you mean by "single equality sign in a conditional"? Isn't = an assignment symbol?

By "equality sign", I meant "equals sign".

[Astronouth7303]

I know that, but generally isn't "If (foo=42)" what one tries to avoid?

[velocipenguin]

I know that, but generally isn't "If (foo=42)" what one tries to avoid?

I think you missed the point.

The reason C compilers don't typically give warnings or errors for using the single equals sign inside a conditional is because it CAN be valid. In the code I posted, the single equals sign sets the address of a file handle, whose value needs to be inequal to zero in order to work. Yes, it's one of those annoying tricks used by programmers who like being clever (i.e. me), but my point is that it's valid and there's no reason the compiler should label it as a syntax error.

[Ryan Cumings]

Some compilers will give you a warning if a condition will always be true or always be false.

[Andy Baker]

Off topic... but I gotta say...

Alan, you made a great program. While you were at work yesterday, we started making automodes. Your software system enabled us to create 5 workable automodes within about 6 hours. These are 5 modes that work, at least on our field.

The code was so clear that even I could tweak the numbers.

To the rest of you, get this: Alan was just an interested parent who attended meetings a few months ago. We needed some more talent in the software area and he rode in on his white horse and saved the day.

Thanks Alan!! Welcome to the craziness of FIRST!

Andy B.

[Greg McCoy]

I'm proud of Andy for working on the auto modes :)

[JVN]

The code was so clear that even I could tweak the numbers.

Andy--
That is... of the dark side of the force... forever will it dominate your destiny.
Baker is now tainted goods....


Remember kids:
Do not fall to the Spark Side. ;)

Gearboxes are more fun.

John

[Steve Shade]

Andy--
That is... of the dark side of the force... forever will it dominate your destiny.
Baker is now tainted goods....


Remember kids:
Do not fall to the Spark Side. ;)

Gearboxes are more fun.

John

John:

Sooner or later you will learn that you can't resist the natrual urge to become one of us. We have Baker now, and you're next! *evil laugh*

Seriously, isn't C much nicer because now you Gearheads no longer have an excuse about not understanding the basic operations of the language?


Steve

[jeremy562]

John:

Sooner or later you will learn that you can't resist the natrual urge to become one of us. We have Baker now, and you're next! *evil laugh*

Seriously, isn't C much nicer because now you Gearheads no longer have an excuse about not understanding the basic operations of the language?


Steve

I am very glad to be using C this year instead of P-BASIC. Of course, I use C++ all the time so going into C mode is a lot easier for me than BASIC...

[jacob_dilles]

I am very glad to be using C this year instead of P-BASIC. Of course, I use C++ all the time so going into C mode is a lot easier for me than BASIC...

and more inportantly, C is real world. basic is fine for playing around with little tabletop robots, but to do anything with anything in the real world of embeded prossesers, C is the standerd.

[Astronouth7303]

Not to mention PCs, which may have a bigger market than embedded systems; C++ is the standard there, too (Though VB is good for a quick dev, I made a program in 10 minutes in VB).

[jhnphm]

There's a way around that (sort of): Something I call "psuedo-objects". Basically, For each instance of the object, Copy the code and declarations and rename. And replace dots with underscores. Object_Procedure
Why? What's wrong with type_procedure(structure,parameters)?

[Astronouth7303]

PIC C isn't object oriented like MSC++, which means that you don't have classes and the code Object.Method(Args); is invalid.

[Chris Hibner]

I think you missed the point.

The reason C compilers don't typically give warnings or errors for using the single equals sign inside a conditional is because it CAN be valid. In the code I posted, the single equals sign sets the address of a file handle, whose value needs to be inequal to zero in order to work. Yes, it's one of those annoying tricks used by programmers who like being clever (i.e. me), but my point is that it's valid and there's no reason the compiler should label it as a syntax error.

You're right in that no compilers will list this as a syntax error. However, every C compiler that I have used (up until the compiler for the IFI RC) will give a warning for the type of statement that you describe using the default warning settings.

If you are using a new compiler, one of the first things you should do is see how the warning levels are set, and then set them to how you like them.

As people have been finding out, C allows a lot of "strange" things as valid syntax, which is done to increase flexibility and the speed of the language. However, this can lead to some confusing run-time errors. This is why C compilers have warning messages in addition to error messages. If you use the warnings properly, you shouldn't have much issue.

Another point: C is like anything else in life: you're not going to be good at it until you practice with it. You'll make errors, you'll find the errors, and then you'll start learning where to look for future errors. In the future, you'll begin to recognize certain behaviors that will help you pinpoint the errors. You know, "hey, I've seen this type of thing before".

Just because you've all hit a few stumbling blocks on your first attempt at C doesn't mean it's a bad language. It just means you're not used to it. Give it a little time and you'll soon be wondering how we ever survived with pBASIC.


Also: Has everyone been taking advantage of signed math? I sure hope so. It is probably the biggest advantage of the new C compiler vs. the old pBASIC controller.

[Astronouth7303]

My first roadblock in learning C(++) was the complexity and the amount of "Valids" vs. "Invalids".

Haven't needed signed math. Well, I did write an abs() function for variance stuff.

[Joe Johnson]

My first roadblock in learning C(++) was the complexity and the amount of "Valids" vs. "Invalids".

Haven't needed signed math. Well, I did write an abs() function for variance stuff.
Signed Math is the one thing that I get down on my knees and give thanks for every time I open our code.

If you are doing any serious control loops (a PID feedback control on a robot arm for example), signed math is a real time saver.

But... ...C is a language for consenting adults. You can get into a lot of trouble if you are a casual user.

Joe J.

[Jay Lundy]

Also: Has everyone been taking advantage of signed math? I sure hope so. It is probably the biggest advantage of the new C compiler vs. the old pBASIC controller.
Yeah, signed math is such an incredible improvement. Not to mention the increased data memory! I used to never use 2 byte variables in PBASIC, now I use ints all the time (well, when necessary... which is quite often).

I like C because it let's you do so much, though I agree the single = sign in if statements should probably throw a warning. But I've used it so much now I can usually trace errors like that fairly quickly (or avoid them altogether).

[Jim Zondag]

All the above discussion is exactly why here in my world, we don't write software by hand any more. It is easy to produce bug free C code that does exactly what you want every time if you have the right software tools. We use an Autocode generator called Rhapsody by I-Logix to generate all of the code we use for the interior systems of all DaimlerChysler vehicles. We write code in a graphical state-machine format and the code generators translate these models into embedded C. In the near future, most software will be developed this way. Now that we have moved from Pbasic, we can apply these methods to robots. I autogenerated the software module for my shift scheduler on BUZZ9 and it dropped right in.

[Chris Hibner]

All the above discussion is exactly why here in my world, we don't write software by hand any more. It is easy to produce bug free C code that does exactly what you want every time if you have the right software tools. We use an Autocode generator called Rhapsody by I-Logix to generate all of the code we use for the interior systems of all DaimlerChysler vehicles. We write code in a graphical state-machine format and the code generators translate these models into embedded C. In the near future, most software will be developed this way. Now that we have moved from Pbasic, we can apply these methods to robots. I autogenerated the software module for my shift scheduler on BUZZ9 and it dropped right in.

We handcoded our IFI RC. However, we autocoded most of our autonomous code running in our off-board processor (we did this last year as well). We use TargetLink by dSPACE. This software takes block diagrams and state-machines made with Simulink and Stateflow (part of Matlab by the Mathworks) and auto-codes them. We've had great success doing it this way. (As a side note, we use this software to auto-code some algorithms for production at TRW.).

[Joe Johnson]

We handcoded our IFI RC. However, we autocoded most of our autonomous code running in our off-board processor (we did this last year as well). We use TargetLink by dSPACE. This software takes block diagrams and state-machines made with Simulink and Stateflow (part of Matlab by the Mathworks) and auto-codes them. We've had great success doing it this way. (As a side note, we use this software to auto-code some algorithms for production at TRW.).
Mathworks (makers of Matlab & Simulink & Stateflow - perhaps the world's largest/most popular simulation software company) is right outside of Boston in Natick. The founders seem like Dean & Woodie kind of guys -- visionary folks.

Does anyone within the sound of my voice have an "in" with Mathworks?

I know this would be a huge huge huge step forward in terms of programming robots. Think of how easy it would be to program if you actually had models of arms, motors, Victors, Spikes, valves, cylinders, etc. all ready and waiting for you to drag and drop? You could code your robot before you actually had a robot in stead of what we have now which is the mechanical system gets done in 5.9 weeks, the wiring gets done in .09 weeks and the programmers have .01 weeks to make it all behave.

There are a lot of things that are unfair about the FIRST competition, but the stress that we tend to put on the coders is among the unfairest burdens we put on people in this FIRST game.

If anyone can get Mathworks to fall in love with FIRST, we would be a long way to making it up to our poor coders.

Joe J.

[Kevin Sevcik]

Heh, this is possibly off-topic since the thread has wandered slightly from hating C, but here's a beautiful piece of C code and explaination that I snatched from the hacker's dictionary.


Duff's device: n.

The most dramatic use yet seen of fall through (http://jargon.watson-net.com/jargon.asp?w=fall%20through) in C, invented by Tom Duff when he was at Lucasfilm. Trying to optimize all the instructions he could out of an inner loop that copied data serially onto an output port, he decided to unroll it. He then realized that the unrolled version could be implemented by interlacing the structures of a switch and a loop:

register n = (count + 7) / 8; /* count > 0 assumed */
switch (count % 8)
{
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}


Shocking though it appears to all who encounter it for the first time, the device is actually perfectly valid, legal C. C's default fall through in case statements has long been its most controversial single feature; Duff observed that “This code forms some sort of argument in that debate, but I'm not sure whether it's for or against.” Duff has discussed the device in detail at http://www.lysator.liu.se/c/duffs-device.html. Note that the omission of postfix ++ from *to was intentional (though confusing). Duff's device can be used to implement memory copy, but the original aim was to copy values serially into a magic IO register.

[For maximal obscurity, the outermost pair of braces above could actually be removed — GLS]


Heh. Took me a minute to wrap my head around it, but I think it's nifty.

[Alan Anderson]

...a beautiful piece of C code...Duff's device:...
Beauty is in the eye of the beholder. So, apparently, is ugly. :eek: Duff's Device is clever, but it goes back to my old comment about c wanting the programmer to "think like a compiler". Optimizations like this should be done in the compiled code, not the source code.

I guess my discomfort with c boils down to the fact that it's a low-level language in high-level language clothing. It's not far removed from assembly language. I do understand the reason for its being that way. That doesn't mean I have to like it. :rolleyes:

[deltacoder1020]

Beauty is in the eye of the beholder. So, apparently, is ugly. :eek: Duff's Device is clever, but it goes back to my old comment about c wanting the programmer to "think like a compiler". Optimizations like this should be done in the compiled code, not the source code.

I guess my discomfort with c boils down to the fact that it's a low-level language in high-level language clothing. It's not far removed from assembly language. I do understand the reason for its being that way. That doesn't mean I have to like it. :rolleyes:

it's really a mid-level language. things like Visual Basic are high-level languages, assembly is the ultimate low-level language... C is a mixture of the two. functions, for instance, are above a low level language, as is order of operations, complex conditionals, et cetera. Instead of "having the compiler do all the optimization", however, C takes the route that the ultimate optimizer is the human mind - a compiler can only do so much optimization, but a human can always invent new innovative ways to optimize something.

[Ryan M.]

...a compiler can only do so much optimization, but a human can always invent new innovative ways to optimize something.Good point. And most compilers to try to optimize some stuff, but there is always situations where the compiler doesn't have the optimization built in, but the human sees that it can be better and does the optimizations on his/her own.

[The Lucas]

Mathworks (makers of Matlab & Simulink & Stateflow - perhaps the world's largest/most popular simulation software company) is right outside of Boston in Natick. The founders seem like Dean & Woodie kind of guys -- visionary folks.


A Mathworks partnership would be an amazing asset to all programmers around the FIRST World. Imagine testing all your Autonomous programs without a finished robot or a practice field, which most coders don't get till Thursday of their first regional.

It is my understanding that Mathworks is still privately owned (ie no stockholders) so it may not be that difficult to get the owners, who are programmers themselves, to agree to help FIRST. They already heavily support academics since MATLAB really got its start in universities.

Great Idea Joe! Hope some one can follow through on it.

[velocipenguin]

Optimizations like this should be done in the compiled code, not the source code.I guess my discomfort with c boils down to the fact that it's a low-level language in high-level language clothing. It's not far removed from assembly language.

Tweaking code for maximum efficiency is a useful skill to have. Coding for small microcontrollers, regardless of the language used, requires a fair amount of manual adjustment to make everything fit. Although I suspect this is rather uncommon, I actually enjoy this; it's a tremendously entertaining challenge to try to cram complex routines into the tiny program ROM on low-end PICs. If you want a language that hides all the scary details from you, code in PBASIC. C is a little harder to deal with, but it offers far more control over the hardware than anything else (except assembler, of course).

[Chris Hibner]

Tweaking code for maximum efficiency is a useful skill to have. Coding for small microcontrollers, regardless of the language used, requires a fair amount of manual adjustment to make everything fit. Although I suspect this is rather uncommon, I actually enjoy this; it's a tremendously entertaining challenge to try to cram complex routines into the tiny program ROM on low-end PICs. If you want a language that hides all the scary details from you, code in PBASIC. C is a little harder to deal with, but it offers far more control over the hardware than anything else (except assembler, of course).

This is a great point. C's strength is in making highly efficient code for embedded control systems. That is one reason that I like having C for the controller this year: it gives people a good feeling for what it's like to program a real embedded controller.

As I've mentioned before, things are starting to move more toward auto-coding, but this is made possible due to faster, cheaper microcontrollers that can make up for the more inefficient code. However, there is still a high likelihood that we'll be using C for quite a while since there will always be an ultra-cheap product that needs to have too much code crammed into a tiny micro.

One last thing about auto-coding: Auto C code generation is just another step up the auto-coding ladder. It's not that revolutionary. Think about it: what is a C compiler other than an auto-coder for assembly language? People used to program with only an assembler. Now the standard is to let the C compiler auto-generate the assembly code and THEN let the assembler go ahead and make the machine code. The next level up is to let TargetLink create the C code, then the compiler creates the assembly code, and so forth.

[Astronouth7303]

Plus, if you go into PC programming, there's a lot of C++ around. Plus, lets face it, pretty much only assembler is harder than C/C++.

[Mike Soukup]

You could code your robot before you actually had a robot in stead of what we have now which is the mechanical system gets done in 5.9 weeks, the wiring gets done in .09 weeks and the programmers have .01 weeks to make it all behave.

There are a lot of things that are unfair about the FIRST competition, but the stress that we tend to put on the coders is among the unfairest burdens we put on people in this FIRST game.
Thanks for the quote Joe, I'm certainly going to send this to Raul :)

[mtrawls]

the mechanical system gets done in 5.9 weeks, the wiring gets done in .09 weeks and the programmers have .01 weeks to make it all behave.


Wow! So it's not just me ... sounds like it would be cool to learn about, but I'm a little weary about letting some computer output a program for me!

Beauty is in the eye of the beholder. So, apparently, is ugly.

Program something in Perl, then come back to me about "ugly"! Seriously, if you do it right, C can be pretty elegant ... and thinking like a compiler is a good way to reduce the bugs in your code, anyway (so it's not necessarily a bad thing). Anyway, make a page long perl regexp and *then* start talking about C (you might change your mind ;))

[deltacoder1020]

Wow! So it's not just me ... sounds like it would be cool to learn about, but I'm a little weary about letting some computer output a program for me!



Program something in Perl, then come back to me about "ugly"! Seriously, if you do it right, C can be pretty elegant ... and thinking like a compiler is a good way to reduce the bugs in your code, anyway (so it's not necessarily a bad thing). Anyway, make a page long perl regexp and *then* start talking about C (you might change your mind ;))

Quite simply, if you're going to program a machine, you should be prepared to program for it, not at it. There will always be a tradeoff between ease-of-use and power, and C does a fairly good job of balancing the two.

[gnormhurst]

I had to toss this in. It's my favorite bit of obfuscated C -- a program written to be incomprehensible. (I didn't write it -- I don't know who did.) I guess what's "bad" about C is that it lets you write code like this. But this code is masterfully written by someone who knows the language very well -- maybe a little too well.

This will compile and run on a command line, printing a message. It looks scary, but it's harmless. The output will astound you. Here's a hint: Merry Christmas!

/Norm
#include <stdio.h>
main(t,_,a)
char
*
a;
{
return!
0<t?
t<3?
main(-79,-13,a+
main(-87,1-_,
main(-86, 0, a+1 )
+a)):
1,
t<_?
main(t+1, _, a )
:3,
main ( -94, -27+t, a )
&&t == 2 ?_
<13 ?
main ( 2, _+1, "%s %d %d\n" )
:9:16:
t<0?
t<-72?
main( _, t,
"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+,/+#n+,/#;\
#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/+k#;\
q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){nl]!/n{n#'; \
r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#\
\
n'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c ;;\
{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;\
#'rdq#w! nr'/ ') }+}{rl#'{n' ')# }'+}##(!!/")
:
t<-50?
_==*a ?
putchar(31[a]):
main(-65,_,a+1)
:
main((*a == '/') + t, _, a + 1 )
:
0<t?
main ( 2, 2 , "%s")
:*a=='/'||
main(0,
main(-61,*a, "!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry")
,a+1);}

[meatmanek]

Cryptic code can be acceptable if:

1. You are the only person who will ever look at the code, and you are used to seeing this kind of cryptic code.
2. You know the people looking at your code (teammates, coworkers, etc) can understand it.
3. You need process and memory-optimized code, because you are working on a system with a relatively slow processor and relatively small memory (The RC, for example).

Remember, though, you should _ALWAYS_ comment your code, especially if it is cryptic. What if your grandmother (who I'm assuming doesn't know C) wanted to read and understand your code?

[meatmanek]

If you really want to see some obfuscated C code, there's actually a contest for it. http://www.ioccc.org/ - The International Obfuscated C Code Contest.

Winning entries can be found at http://www1.us.ioccc.org/years.html

If you want a language that is very easy to program in and makes sense, check out Ruby at http://www.ruby-lang.org
For example, to run a command 3 times in C, you would do this:

for (int i=3; i<=0; i--) {
command();
}

In Ruby, it would look something like this:

3.times { command }

Ruby is also loosely-typed, meaning you don't have to worry about the size of the variable that's holding your data, the interpreter will determine that for you.

Note that you can't use Ruby on the robot, this is just for hobbyist programmers.

[gnormhurst]

Thanks for that pointer to IOCCC -- I think that's where that bit of code came from, many years ago.

And now I'm reminded of another language, "whitespace (http://compsoc.dur.ac.uk/whitespace/),", wherein all code is composed entirely of three characters: space, newline, and tab.

Here's a example bit of code:

This is a comment.














































































End of code example.

Maybe next year FIRST will specify whitespace as the language we use.

[Astronouth7303]

Thanks for that pointer to IOCCC -- I think that's where that bit of code came from, many years ago.

And now I'm reminded of another language, "whitespace (http://compsoc.dur.ac.uk/whitespace/),", wherein all code is composed entirely of three characters: space, newline, and tab.

Here's a example bit of code:

...

Maybe next year FIRST will specify whitespace as the language we use.

**** the guy who makes that decission.

By the way, what does your program do?

[deltacoder1020]

Thanks for that pointer to IOCCC -- I think that's where that bit of code came from, many years ago.

best bit of IOCCC code ever... only runs on certain machines, though:


short main[] = {
277, 04735, -4129, 25, 0, 477, 1019, 0xbef, 0, 12800,
-113, 21119, 0x52d7, -1006, -7151, 0, 0x4bc, 020004,
14880, 10541, 2056, 04010, 4548, 3044, -6716, 0x9,
4407, 6, 5568, 1, -30460, 0, 0x9, 5570, 512, -30419,
0x7e82, 0760, 6, 0, 4, 02400, 15, 0, 4, 1280, 4, 0,
4, 0, 0, 0, 0x8, 0, 4, 0, ',', 0, 12, 0, 4, 0, '#',
0, 020, 0, 4, 0, 30, 0, 026, 0, 0x6176, 120, 25712,
'p', 072163, 'r', 29303, 29801, 'e'
};


see the hint file here (http://www1.us.ioccc.org/1984/mullender.hint)
this is from the first IOCCC competition in 1984

[Ryan M.]

I had to toss this in. It's my favorite bit of obfuscated C -- a program written to be incomprehensible. (I didn't write it -- I don't know who did.) I guess what's "bad" about C is that it lets you write code like this. But this code is masterfully written by someone who knows the language very well -- maybe a little too well.

This will compile and run on a command line, printing a message. It looks scary, but it's harmless. The output will astound you. Here's a hint: Merry Christmas!

/Norm
...There is absolutly no way that should compile. :) Wow, that's the crazy. And whoever created that Whitespace language has too much spare time. :):)

[Astronouth7303]

Ditto on both of those and Deltacoder's

[meatmanek]

If you really want to see a pointless language, check out Befunge(http://kotisivu.mtv3.fi/quux/befunge.html); they call it a '2 dimensional, lower than assembly' language. Scary thought. Here's a bit of code:

>1+>:~::"0"-:v>$:v>>21p :0#v_1-::::6g:" "-!88+*+v
p +v_:#`0 #<_|_ " |-+77:+1g12_!v!-"!":+0-"0"+gg12\<
6v 3>#$"9"-:v#<|_/ >$11g3+:6g4v->88+*+:"9"`:"0"+85*v
\| p#_!:`"#0_ ^"|" vp3p04+1:g0<^+2g11p+1g12\-*+55p1<
^< ^6+1p11:\_!-6#<^>1+:6g:84*#^-#4 _$$40g:"+"\:"|"v
v59:+1p3+1\g6p12:<1:p2p3\<
>*\2p:21g1+:11g-#^_$$31p70p11gv
2x v06:g22p124 p42 -\p22+1:g04p00::-3-<
3x >p80p >22g::3g:" "-!88#v+#*<
4x v g42_^#!:-1p22+1pg12\+<>+90p650p11v
5x >:23p 3g60g:1+60p21ggv ^77p08p06:<g
6x ^+1g32_v#!:- _v#-" ":<vg12\+*+88!<-2
7x # >0`!#v_22g:1+22p :3g:" "-^++ >v
8x ! >$$>#_ > 22g00g1^: 0g
9x v_v#`0_v#:-gg12g06 gg05 : < 51
vp*469"$"`-1g13:$_v#! -* 48 :g <_v>60g1+60p1+:70g- #^_^+
v_>$>:#,_@> #\ $^$ >50g1 +50p50g90g-1- !#v_^ 5
">v>50p:!#^_50g:vv6 8-6g05< # < !p0<
0:2^+1\-1\p1\"0"<>* +22g1-1p!#v_ :50g1-g> 80g:1+80p21g1+pv
"+1^g22:: < v_ #` #g13g2$#2!#<^ # ^_v#-" ":g-1g05: +1<
\1g >64*-#^_$| >$ 60g21g2+p v >$$80p22g>1-::60p:21v
p2 ^p12:+2g12p 08p06:\-<v06gg09 :<$# ># #< ^vg+1g12\gg<
+>+g"0"-!#v_:22g\- 00g\^>g21gg-:!#^_0`90g\-90p^ >:" "-!#v_v
^2g12\" ":<$!_^#!-+88-gg12-1g06 :+"0"< p080_v#<`0+1:-g08- <
>:#-1g #2\ #< >1-:31g-"."\#|_\:< ^++55p081< ^10 :$$<JJ

... Yep, that's code. I swear. Don't ask me how it works, I'm as clueless as you are. Apparently that divides two numbers.

Also, Assembly is by far not the lowest language. Many programmers (decades ago) have programmed by punching holes in punch cards, using direct binary values, and even wiring vaccuum tubes together to perform a specific task.

[Astronouth7303]

...
Also, Assembly is by far not the lowest language. Many programmers (decades ago) have programmed by punching holes in punch cards, using direct binary values, and even wiring vaccuum tubes together to perform a specific task.
The latter isn't programming. In order to program, it has to be programmable.

[Ryan M.]

The latter isn't programming. In order to program, it has to be programmable.I agree to some extent. That really isn't programming any more than revising an electrial circuit is. When you see someone substitute one circuit board for another, you don't think, "Wow, that's great programming." :):)

[dddriveman]

MPLAB need i say more

[Kevin Karan]

"d"v >v
v "# "w"<
" l o
" "
" >"r" ^
>"o"#v"l"<
v,,,<>"e"v
>,,v^,"h"<
@,,>#,,<

if I can figure out the language, anyone can!

[Kevin Karan]

Its like an artform

"d"v >v>"e",v
v "# "w"< v<"
">#l"v"#o,^ ,"
^ "#,,," "< "K"
" >"r" ^ >^ e",
>"o"#v"l"<" "^<
v,,,<>"e"vlv,<
>,,v^,"h"<">"v",v
v,,>#,,<> ^v,"i"<
>",","o"^ >"n",@

[Ryan M.]

All I can say is "Weird..." :)

[Mercutio]

I'm another one of those intellectual masochists who love C. The biggest perk for me is how much control C gives you over both the internal workings of your program and the shape of your code itself. It has strong typing, so you can specify how big and fast you want your variables to be. It has pointers and references, so you can pass actual variables to functions rather than just the values of variables. It has structures, so you can organize data into big, meaningful chunks and create data types with sizes that exactly suit your needs. It has bitwise operators. It has functions with return values. In a desktop environment, C gives you even more control, with register variables, dynamic arrays, and in-line assember code (if you really want to beat yourself up ;)). C may be a little more unforgiving than some other languages, but I find that most of my stupid mistakes come from program structure, not syntax -- whether I'm coding in C, Java, Javascript, Perl, or PBASIC, I make the exact same amount.

[Mercutio]

That [wiring vacuum tubes together] really isn't programming any more than revising an electrial circuit is. When you see someone substitute one circuit board for another, you don't think, "Wow, that's great programming." :):)
I'm reminded of ENIAC, where programming consisted of moving plugs around on a board designed specifically for that purpose (it looked kinda like an old-time telephone switchboard). To us, programming consists of moving characters around in a text file designed specifically for that purpose. In both cases, there is a box full of vaccuum tubes or a wafer full of transistors sitting behind the program to interpret it. In both cases, programming makes an actual mechanical change to the machine -- with ENIAC, to the plugboard, and with us, to the patterns of charge or magnetism in the hard disk, flash memory, whatever. I don't think it's fair to call one programming and the other not.

p.s. sorry bout the double-post :(

[Ryan M.]

I'm reminded of ENIAC, where programming consisted of moving plugs around on a board designed specifically for that purpose (it looked kinda like an old-time telephone switchboard). To us, programming consists of moving characters around in a text file designed specifically for that purpose. In both cases, there is a box full of vaccuum tubes or a wafer full of transistors sitting behind the program to interpret it. In both cases, programming makes an actual mechanical change to the machine -- with ENIAC, to the plugboard, and with us, to the patterns of charge or magnetism in the hard disk, flash memory, whatever. I don't think it's fair to call one programming and the other not.

p.s. sorry bout the double-post :(That's why I had the "to an extent" part in. :)

[K0r34nB0y]

I love C, but I'm kinda sick in the way that assembly is my favorite language (despite the fact that I don't know too much of it). I like languages that make logical sense. I hate VB, it's absolutly awful. For instance:
"if cheese = 0 then"
compared to
"if (cheese == 0)"
the second just makes sense to me. The first, it's like "Wait, so am i setting cheese equal to zero, or am I just comparing it?". Once you study C, you see the merits to how it behaves and why. It's much more logical than VB once you understand it. In order to gain a true appreciation for C though, you need to study C with assembly. Only then is the true beauty of C revealed.

[Astronouth7303]

I have an advantage: I learned VB first. But it's really nice for making small/micro apps. Like one that finds the factors and prime factorization of a number.

[CrashZero]

Don't put down VB I admit that C may make more sence but VB still has the advantage of simplicity. It is point and click. I mean sure the code is not exactly the best but it is still easy once you know how it works, just like anything. It is easy, but only after you know how it works.