Respect C Programmers
kontsevoy.blogspot.com
Recently I just got fed up with unfair criticism of C...
kontsevoy.blogspot.com
Otherwise, I largely agree with the article (although I don't actually think C particularly needs defending right now). The only point I disagree with in this article is the exclusion of server-side web applications when he says "show me the code." Server side web apps aren't the dull, stateless things they used to be - trememdous innovation is taking place here.
Right after I graduated, AP Computer Science switched to Java and my school started teaching C++ as the first programming language, then Java, then Java again for AP CS.
Interesting how pascal kind of quietly disappeared. It has the closest resemblence to the algol heritage that it came from.
the only thing I find confusing is forgetting that there may be a global function to do what I want. eg len(array) as opposed to list.length (ruby). But that probably doesn't hurt in reality at all.
The few books I have read on python are also excellent and approachable.
Also you can do fun stuff with python (build GUIs etc) and do tangible stuff that makes teaching it more fun.
'void' means an empty parameter list, a function that returns no result, or a pointer to anything.
There is an array type, which you declare with brackets[10]. It's a real type on par with all the other real types in the language. Yet, accessing the values in an array is done exclusively via pointer arithmetic.
int foo(); declares a function with unspecified parameters, unless it is C++ where it means no parameters.
char x[5] = "Hello"; //Is an array of 5 chars, and has no string-terminator
char x[] = "Hello"; //Is an array of 6 chars, with string terminator.
In other words, I think that you should learn first how to teach the computer to do stuff and only after having done that for a while should you try to understand how the computer interprets the instructions you give it. Of course, you could take the very first steps in any language (except maybe Intercal), but once you get to strings and the like, C is more likely to make it more difficult instead of easier.
although hilarious, it's an ideal that shouldn't be laughed at
The reality is, programmers who don't understand how computers work can write ridiculously bad code. I saw it a lot. Efficiency does become an issue when a program is so bad and slow and unreliable that a computer can't execute it in a reasonably useful way.
I'd never hire a Python programmer who doesn't know what dynamic array is all about or what CPUs are dealing with when they run a program -- essentially addresses and numbers.
A recent YCnews post comes to mind: if you want to find a good PHP programmer you have to announce a C++ vacancy with no single word about PHP.
I'm not saying C is the best language to learn how to program, but it's definately better than Java, C++, Ruby or JavaScript. I can't tell how Lisp would work as a first language because I haven't seen anyone try to learn or teach it.
Now, understanding pointer would help a lot, but that's a different argument.
However, if I was designing a practical college curriculum, I would require a course early-on that involved detailed instruction on how C actually works, as well as extensive practice using it and exploring its tricky areas. It might correspond with an introduction to assemblers, computer architecture, or operating systems. The catch is having an instructor that actually knows C well enough to teach it.
If I'm typing away in Java, you KNOW I have an end-goal. No one plays around, because...it's not a toy.
It's like saying, French is a more beautiful language than English (it is, you know). But compare the import/export ratio of the film and popular music industries. I can't recall the last French pop song I heard...
Wait, I do: http://www.youtube.com/watch?v=2-sUzR71wpQ
As for C, I suspect there's more information about C "tricks" online than all other languages put together. For example: http://www.ioccc.org/
What I meant is that knowing how you would have to implement each of your high-level data structures in C helps you understand some of the problems you encounter when working with them. For example, now I know the difference between these two Python lists: l = [[1,2] for i in range(6)] and l = [1,2] * 6
"Linked list" is not an abstraction (at least, not in Python), it's an implementation detail. And IIRC, Python lists are not actually implemented as linked cells, so they have different performance characteristics.
Other "high level" languages are however, becoming increasingly dominant on server-side or hosted products, since the developers can control the execution environment closely.
Here's a page on how to do it with clisp:
Similar tools exist for other languages which require the language itself to be present while the program is running.
I suspect there aren't that many of them, there are fewer people programming C these days as compared to Java or C#. But they produce spectacular number of open source products we all use.
Respect them for that. That's all.
char*____="RDCO$Utho{kfah||0R}wq5\x7fy8Z;";int main(int _,
char**______){return _>!0xBADC0DE?main(!0[______],&____):!
(-_)[*______]?!putchar(10):putchar((*______)[-_]^-_)?main(
--_,______):0xDEADBEEF^!!"Valid C89 but not C++ nor C99";}
I especially like the part about "You see, most of you Haskell/Lisp/Erlang gurus are true intellectuals and are very capable. You write very well: many great 'functional-style programmers' like you have nicely written blogs filled with sacks of good thoughts and ideas.
However, when I look around I rarely see any results of your work."
It seems his argument is that there is some evolution at work in the marketplace. Instead of arguing the "bestness" of language X or Y, simply look around and see what is thriving and what isn't. That would be a great discussion to have here. I'd add more, but I think I'd sound like a troll. Good article.
Why not view programmers as customers, and languages as products? Are the customers buying the products that provide them the most value? I believe your argument is that they are not. Then why? Are they dumb? Misled? Controlled by people who don't know any better?
It just seems like there is some missed communication going on here. I know I'd like to see somebody who is an expert in both functional programming and some ornery imperative/OO language, like C++, make some observations. By expert, I mean several non-trivial deployed production systems in each language, not somebody who played with language A in college is now infatuated with language B.
As for me, I'll pick whatever language makes my startup get to market and adapt to customer's needs the fastest. I hear PG says that's probably one of the functional languages. I'm game. I can prototype and change a web site very quickly in several other languages (with the right tools), I'm always willing to see if something else will work better. But I can certainly also make the observation that there must be a lot more functional programmers who moved to imperative programming than the other way around. Surely they all can't have done so for the reasons I've outlined above.
http://www.welton.it/articles/programming_language_economics...
A lot of the 'value' in a language is its network of users. For every X users, depending on how much your average user is likely to contribute back (some constant C), there will be Y contributions in terms of libraries, help on lists, user groups, articles, things like that.
I wish Common Lisp programmers would realize that. Many are outwardly hostile to the very idea of their language becoming popular with the barbaric hordes of uncivilized Java and C# and PHP programmers.
Well, those that post on comp.lang.lisp that is. I suspect the Common Lisp "community" is one of the reasons pg is developing Arc.
Perhaps there is a difference between "language as a solution" and "language as a development platform". If you are looking for the best solution to problem X, choose the language best suited to solve the problem. If you are looking for the best development platform for problems X1..X1000, then the calculus comes out differently. Dunno.
More here: http://journal.dedasys.com/articles/2007/10/09/languages-wor...
I think if you strip aside the emotional reasoning that's going on, some languages naturally fit with some people more than others. Thinking in terms of functional decomp and association is just different than thinking in terms of objects. Some people build their own "language within a language" each time they solve something. Some people just want a language that is easy to find help for on the internet. Perhaps the trick is to identify which of those paradigms best fits your long-term goals for your both you and your problem.
I once interviewed a guy with a bunch of different languages on his resume. "So which do you like best?" I asked. He responded, "Java". I said, "Why's that?" He said "Because when I hit the compile button most of the time it just runs."
I thought that was a good answer.
Precisely! Because, in the end, languages are for people, and people are fickle and weird, and often irrational.
I think there are some things that make some languages more or less objectively better for some tasks, but like anything that revolves around people, it's often not so clear cut.
By the way, I like C.
However, I think the author's most most salient argument could be summed up as: "before claiming to be David slaying Goliath, make certain you're not really a dwarf standing on the giant's shoulders."