3 ms·
Apparently because Jeff Atwood complains about it occasionally. Also, because it's the only popular language that doesn't consider "magic" a good thing.
by etal 18y ago
Apparently because Jeff Atwood complains about it occasionally. Also, because it's the only popular language that doesn't consider "magic" a good thing.
- stcredzero 18y agoYou've never been in a self congratulatory C shop where "macro wizardry" is considered a good thing. (Wasn't there some early widget toolkit for X windows that tried to implement Objects using C macros?) On the other end of the spectrum, I have also worked on a large client-server app at a company whose workforce was taken from the local community college with courses in programming taught in C. Every time these programmers wanted a new collection, they rewrote Linked List. No exaggeration. There were many hundreds of independent implementation of Linked List. I was looking over a shoulder of a programmer, who was showing me that this was what I should do, and watched her showing me how to reimplement linked list. One client even got fed up and tried to introduce a library called "Super Link." Programmers in this shop ignored it and went on reimplementing Linked List. Management at the company determined that "Super Link" would just be particular to that client. (No one understood passing function pointers.) These programmers thought the C compiler was some kind of "magic." Every time I tried to talk about the call stack, they would give me blank stares.
- etal 18y agoPretty good. C is unmagical, but that doesn't keep developers from adding their own special magic... Reading Guy Steele's late-1990s defenses of Java, and observing how C and C++ actually are used in industry -- yeah, I actually am happy that Sun managed to bring Joe Application Programmer about halfway to Lisp. In general, magic features like built-in garbage collection and all the basic collections in the standard library are a Good Thing. The main problem I see is that C is designed for systems programming, where everything really should be explicit, while most of the code that actually gets written belongs at a much higher abstraction level. Still, even in higher-level languages there are edge cases that make much more sense if you understand how the situation looks from the level of C -- for example, performance profiles. (At the self-deprecating C shop where I worked last, I was the one deleting macros, wrapping lower-level code with Swig, and pushing Python and shell scripts for new code. We used glib, too -- which removes 10% of the pain while demonstrating ever more clearly that C should not be the primary language for big userland applications.)