You should remove the deprecating remarks from your readme/code/headline.

Someone will tweet them for you.

Providing a few macros to add some syntactic sugar could make this much better . On a separate note , theres no need for any self deprecation . I being a beginner found this post quite thoughtful and interesting .Keep going.

yes, we need macros, more macros. Then it will be good.

In all seriousness though, it's basically supposed to teach about function pointers.

I would never, ever recommend programming like this.

In response to the macros, i think that would make the program particularly hard to reason about because part of the program would be rewritten at compile time.

I would discourage the use of macros. I believe that Brian Kernighan would agree with me.

As a rule of thumb, it is better to use enums over #defines and avoid macros like death. Stick to the most standard, simple parts of the language and your programs will be most readable and likely elegant.

>> "Avoid macros like death"

Macros are arguably one of the most standard and simplest parts of C. They are much more dependable than, say, gcc inline functions (in my experience). Just don't try to do bizarre things with them. Study how the best C programmers use them, and imitate.

I just said it because sooner or later someone is going to barge in and say "Hey whats the big deal here ? I did this way back in data structures 101 ! "

You wanted to say "do not abuse macros" (like "do not go extreme with anything" actually).

And BTW, you should know that death is unavoidable! :)

Carmack mentioned moving to functional C++ programming recently. http://www.altdevblogaday.com/2012/04/26/functional-programm...

Perhaps you are onto something here.

Yes, finally a way for me to have more unreadable C code.

You have had a way to write unreadable C for more than 20 year ... its called C++.

That's presumably why he/she is glad this adds a new way in C. Making c++ unreadble is child's play -- anyone can do it.

No, I never wanted to write C that way. That looks too much like C++, with its std::for_each and things that look potentially useful, until you actually try finding a use for them.

What I have wanted is closures that you can stick data inside. But they can't be done in a reasonable way in a language like C. The C++ version falls short of usefulness.

I should have shared this link instead...

http://en.wikipedia.org/wiki/Blocks_(C_language_extension)

Is that a challenge?

Closures? It would most likely be a frustrating and unrewarding one, but sure.

One thing I would like in C is a more programmable preprocessor. C++ templates are on to something useful -- metaprogramming removes some of the drudgery from writing fast native code. Templates are fatally flawed, though. I think it may be possible to get some of the benefits from a smarter preprocessor -- if it was done conservatively in the C style.

The Blocks extension for C provides you with anonymous closures, if you wish.

Can you make this into a ruby gem?

This is beautiful.

eye of the beholder.