Learn C

https://medium.com/tech-talk/afcfa2920c17

by wx196 • 13 years ago

286 179 13 years ago

A little off topic, but I think people need to realize that when someone says they're a programmer, all they mean is that they write code.

I know a lot of my friends (especially the ones in tech heavy cultures like Google, Facebook, Palantir, Dropbox) easily forget that when someone says "I'm a software engineer," they mean they write code. It doesn't mean they've gone through the same coursework, can reduce 3-SAT to everyday problems, form intricate algorithms, or have written their own memory allocator.

Keeping this in mind might make conversations go smoother.

kunai2• 13 years ago

http://xkcd.com/378/

doktrin5• 13 years ago

> when someone says they're a programmer, all they mean is that they write code.

How is this an inaccurate or misleading statement? If they write code for a living, they're programmers.

> A little off topic

IMO that's an understatement.

cthackers2• 13 years ago

There is a difference. The difference between someone who works as a programmer, who takes it just as a job but of course can be extremely good at it - just like anything else you practice a lot; and someone who is a programmer. They are lexically the same but they mean different things. The last one, beside working (or not) as a programmer, does it for the art of it. Who not necessarily learns or does something (ships) because it's needed or it provides anything else beside the joy and fulfilment of learning and understanding it. For example, at work, when you want to stop programming you open your own personal open source project and relax for an hour with it. Then you go home after 8 hours of programming and start up your IDE and carry on with your art that may or may not ever see the light of day and it makes no difference.

jcrites• 13 years ago

There is a lot more to software engineering than writing code. As I see it, proficiency in software engineering includes topics such as:

1. cost efficacy

2. availability, reliability, and scalability

3. administration (system administration); operations and support; troubleshooting & crisis management (this and #2 are their own sub-field: site reliability engineering / devops)

4. security: risk analysis, threat modeling, cryptography, access control, vulnerability management, incident response (another sub-field)

5. computing science: algorithms, data structures

6. networks, distributed systems, load balancing

7. programming: languages, compilers, VMs, frameworks

8. quality assurance, testing

9. application architecture

10. data storage: databases, relational and non-relational, caching, transactions, replication, locality

11. facilities, data centers (power distribution, cooling - though that's getting more into system engineering)

12. product design, customer experience, accessibility, human factors

13. project management

I think of programming as the art of writing code. Engineering is the act of creating reliable, controllable systems -- systems that achieve their technical goals and business goals in a steady, reproducible way. Engineering is the act of balancing tradeoffs scientifically and ensuring that quality goals are effectively met.

You might call any autodidact coder a programmer. College students can be adept programmers. However, writing code is just one part of being a software engineer. I would expect senior and above level software engineers to have experience in most or all of the topics above, and I'm sure there are more that deserve to be on the list.

Engineering in the software field isn't /always/ about building super-reliable things. That is one factor that I think differentiates it from other engineering fields. Engineering in the real, physical space has safety implications that typically require a high level of rigor at minimum. If a bridge fails or a building collapses, that's catastrophic. Physical products are only useful if engineered to a high level of quality. However, software is useful across a wider spectrum of reliability: if a back-office web app used by the recruiting team has to come down for maintenance for 2 hours on Sunday, that may not be a showstopper.

Consequently, part of software engineering is understanding what level of robustness is needed to meet business goals, and building to it appropriately, with appropriate costs, and understanding the properties of the built system. Controlling the level of reliability is what makes it engineering.

To be fair, I cannot account for what someone else means when they say they're a software engineer. But this is what I mean, and I consider the field to cover a number of topics and subjects beyond programming.

effbott• 13 years ago

http://en.wikipedia.org/wiki/No_true_Scotsman

kunai2• 13 years ago

  You'll learn to feel every line of code you write

This is exactly how I felt when I started writing C.

I started out with .NET and Java. Both had quite high abstraction levels, and not much deep integration with hardware. I took my control statements, conditionals, and high-level object-based programming for granted -- I never WANTED to learn C. I took one look at K&R and was turned off by the insane amount of low-level work you had to do compared to Java or Python, even to write a simple character counter.

I came back to it. I was slow at first, I was confused, but I learned how to write in C. I learned how to control memory myself. I learned how to do my own text handling. I learned how to avoid buffer overflows and segfaults.

In many ways, it's like going from a Mercedes-Benz to a Miata. There's a lot less comfort, and you have to do a lot more of the shifting and oversteer yourself when the Benz used to do it for you, but you really feel yourself driving, and when you step back into the Mercedes, you feel numbed.

It's the same with C.

sigkill3• 13 years ago

A small part of C was beaten into us for 2 years at the 11th and 12th grade. Today (I'm not a CS guy by the way), even when I write programs in python or any high level language I have this nagging feeling of 'loss of control' and that the code is not efficient enough. I know this is wrong but I can't help this feeling when now things are handed to you as compared to flipping every figurative bit in C.

pointyhats2• 13 years ago

It is right not wrong. Being decoupled from the machine by several layers of abstraction means you're just rearranging the furniture rather than whittling it out of wood.

I hate rearranging the furniture; it gives no satisfaction.

Satisfaction is a big part of quality in your life.

andrewvc• 13 years ago

This is a fair point, but it brings to mind another point I didn't really understand till the last couple of years. Learning about how compilers work is just as important. Building a small lisp compiler was a life-changing experience for me in terms of going one level deeper, as much as understanding C was. For those who've never written lisp before, the reason I recommend a lisp compiler is that lisp compilers are the simplest to write, and the most expressive in terms of runtime strategy since lisp syntax mirrors a compiler's IR (intermediate representation). I think this is just as important in todays world because languages like Ruby and Javascript are both directly inspired by lisp. We also live in a world where Clojure is seeing a steady rise, for once a Lisp with large potential for significant commercial adoption.

I can highly recommend the book Lisp in Small Pieces, $93 on amazon, and worth every penny. Walking through the building blocks and design decisions of a language changes the way you code. Every language you look at winds up being internally translated into your own IR whether you've written a compiler or not. Understanding the inner workings of a compiler however adds depth.

mbel• 13 years ago

I totally agree; actually a small, incomplete Scheme interpreter (which may be used to develop a lisp compiler later on) can be easily created in few hours (depending on used language) [0], without any prior experience. It's surely not as deep learning experience as building a compiler, but I think it's still worthwhile.

[0] http://norvig.com/lispy.html

irahul2• 13 years ago

A more complete interpreter:

http://norvig.com/lispy2.html

z3phyr• 13 years ago

http://en.m.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48...

Write yourself scheme in 48 hours (with haskell). Great learning experiance!!

fdr_cs2• 13 years ago

I do recomend SICP .

dmix• 13 years ago

The SICP Stanford videos by Sussman from the 80s and reading the book was an experience that sounds almost exactly like the author had learning C. It was one of the moments where I realized I enjoyed programming as much (or more) than design.

betterunix9• 13 years ago

"lisp compilers are the simplest to write"

I think Forth may have that honor, and people have done some pretty amazing things with simple Forth implementations. I do agree, though, that writing a simple Lisp compiler is a worthwhile exercise, and the Lisp In Small Pieces is a book everyone should have on their shelf.

dysoco• 13 years ago

I would say Brainfuck is even easier.

tptacek2• 13 years ago

Write an emulator! If you write an emulator, you can probably skip "learning C".

dpritchett• 13 years ago

What might I read to begin to learn which platform to emulate and how to get started?

webreac2• 13 years ago

I do not understand the hype around clojure. I think functional programming languages have mainly evolved to introduce stronger typing and to remove the parenthesis. I wish a great future to scala (and haskell). For me, clojure is outdated.

siddboots• 13 years ago

I suppose it's because functional programming isn't a one-trick shop. There is a paradigm that comes out of lisp macros that can't be accomplished within a language like Scala or Haskell, even though those languages are superior in many other respects.

zedshaw4• 13 years ago

Hell yeah, learning how to make compilers should be what a BS in CS is all about. Pretty much everything in computer science can be turned into a language and compilers have almost all of the major topics in CS as one easily explainable thing. It's also one of the few parts of CS that stands on a solid logical proof filled footing and is still insanely practical.

I basically teach baby compiler theory at the end of my Python book without people even noticing because I think parsing at a minimum is so important.

conradev• 13 years ago

I started programming for iOS via the same route, playing around with Objective-C in Xcode, but have since learned C. I have found that an understanding of C proves to be essential if I try to do anything reasonably complex (e.g. https://github.com/conradev/BlockTypeDescription).

I have also found that another area in which newer developers fall short is understanding how Xcode works. Those familiar with interpreted languages do not have to compile their code. While they may understand the concept of 'modules', they don't know the difference between static and dynamic libraries, what 'linking' is, and how the compiler finds header files. Someone not knowledgeable of how this works will come upon innumerable headaches down the road, especially trying to integrate third party libraries.

I would suggest a supplementary post entitled "Learn How Xcode Works, You Cheater"

hbridges2• 13 years ago

Might could do that! Actually one of the biggest mysteries to me for a while was how header files worked, how the compiler finds symbols, build dependencies, linking libs, etc. Having to mess around with Makefiles helps you digest those things, but then Xcode treats them in an entirely different way. #include is a complex beast

tjdetwiler• 13 years ago

#include is actually a very simple beast, once you realize that it's much easier to digest.

mimog2• 13 years ago

How does a musician without any formal CS education and a admitted lack of understanding of some very fundamental software things, such as pointers and memory, land a San Francisco dev job? I thought those jobs were in very high demand

binarycrusader• 13 years ago

You'd be surprised at how far "not an asshole, actively learns, and is good at programming" can get someone.

ryalfalpha• 13 years ago

I'd replace 'good at programming' with 'proven ability to ship'. Most of the time it's values way over a decent codebase from what I can see. Which is often fair enough!

zedshaw4• 13 years ago

Not as far as "total asshole, does coke, and actively kisses ass" does at the same companies. <rimshot>

stefantalpalaru• 13 years ago

Sometimes social skills are more important than technical prowess.

ksikka• 13 years ago

not more important

zeeshanl2• 13 years ago

As a person with a masters in music, a bachelor in film, and now programming for a living, I def. believe that having a persistant interest in learning about those "fundamental software concepts" is what makes such a gig achievable, especially if you keep doing the extra work in your spare time (like taking Dan Grossman's unbelievable Programming Languages class or going through Zed's LCTHW).

mimog2• 13 years ago

Given that you have a masters degree in music I would wager it would take me a very long time to get to your level in playing, writing and understanding music. It's doable of course, but I would have a lot of learning and work ahead of me. I think the same would apply to you catching up to someone having a masters degree in computer science or related fields.

mc-lovin2• 13 years ago

I was in a similar situation to the author: largely self-taught, very little formal training or knowledge of the "big picture" ideas.

It's a bit like learning a language. You can learn a foreign language without formally studying grammar, and most of the time you will instinctively get things right, and have an intuitive idea of how grammar works.

But formally studying the grammar of a new language makes learning much faster, and you have a deeper understanding.

betterunix9• 13 years ago

We need less code written in C, not more. We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code that is hard to escape; writing more software in C makes that problem worse.

Most software is written to solve high-level problems. Using a high-level language is sensible, time-saving, budget-saving, improves portability, and saves on headaches later. The same rule that applies to COBOL should apply to C: only use it when you have to deal with an existing legacy codebase (and only if rewriting that codebase with a better language is not possible).

hbridges2• 13 years ago

My point is there are fundamental computing concepts that you can pick up by learning C. In a world of high-level, low-LOC languages you can get by without learning those concepts, but it serves your and the ecosystem's best interest to learn them.

betterunix9• 13 years ago

I think the disagreement we have may stem from our notions of what constitutes "fundamental computing concepts." I rank the lambda calculus much higher than C or assembly language when it comes to that. I would say that knowing your data structures and how to analyze algorithms asymptotically is vastly more important than knowing how code is being executed at a low level.

Even for the cases where low-level code must be written, I would say we need people who know assembly language and compiler theory more than we need people who know C. There is no particularly good reason for C to be anywhere in the software stack; you can bootstrap Lisp, ML, etc. without writing any C code. We need people who know how to write optimizing compilers; those people do not need to know C, nor should they waste their time with C.

Really, the most important computing concept people need to learn is abstraction. Understanding that a program can be executed as machine code, or an interpreted IR, or just interpreting an AST, and that code can itself be used to construct higher level abstractions is more important than learning any particular language.

fdr_cs2• 13 years ago

its not about writing new code in C. Its about learning how you prefered language is implemented. Learn your tools , its really important.

nemo1618• 13 years ago

I wouldn't say this article is recommending that you go out and program in C full-time. Many people have learned Lisp (and are better programmers for it), but few actually use it at their day job.

kmm7• 13 years ago

Was there any study done to the (un)reliability of C? I know for a fact practically every piece software I use is programmed in either C or C++.

The sole exceptions are Anki and Gentoo's portage system, both Python. And I'm pretty sure the reason portage is so extremely slow is because it is in Python (I've checked, it's not I/O-bound). And Anki is some very unreliable software.

In fact, give me a single big desktop software project made with a language that is not C or C++.

betterunix9• 13 years ago

"I know for a fact practically every piece software I use is programmed in either C or C++."

How confident are you that that software will work as expected? How much are you willing to bet?

The fact that a language is popular does not prove that the language is good, nor that it should be used, nor that it is not causing us problems. Just the other day on HN, there was an article about a massive number of vulnerabilities in X11 applications -- all resulting from problems that you have in C and C++ but not in higher-level languages. Entire classes of bugs that are common problems in C are just not an issue in other languages.

Sure, it is possible to write unreliable code in high-level languages. It is just a lot easier to write unreliable C code, and C programmers are much more likely to do so (even those with years of experience).

doktrin5• 13 years ago

> And I'm pretty sure the reason portage is so extremely slow is because it is in Python (I've checked, it's not I/O-bound)

I was under the impression portage was "slow" (relative to other package management tools) due to the fact that it built everything from source (for which it uses make). Where is the Python bottleneck?

> In fact, give me a single big desktop software project made with a language that is not C or C++.

What constitutes "big"? There are a few large desktop projects that run on the JVM, for instance.

pjmlp12• 13 years ago

Just three, ask for more if you wish:

The original version of Skype was done in Delphi.

The first versions of Mac OS were done in Apple Pascal.

Photoshop was originally done in Apple Pascal.

philwelch• 13 years ago

Eclipse is made with Java.

Teckla• 13 years ago

In fact, give me a single big desktop software project made with a language that is not C or C++.

I find your requirements odd and vague (why big? why desktop?), but speaking just for myself: Eclipse, jEdit, CyberDuck -- all written in Java.

I use plenty of applications written in C and C++ too, of course; but I think that's largely due to (1) inertia in the application development industry, and (2) it took a while for runtime environments like the JVM to perform well, so they got a bad reputation early on that's no longer really deserved -- but the reputation persists in the minds of many developers.

simonster2• 13 years ago

A major part of Firefox (hundreds of KLOC) is written in JavaScript. While the layout and network code is all C++, most parts that aren't performance-critical and don't need to interact directly with the OS are JS. This includes all of the high-level UI code.

trimbo2• 13 years ago

> We already have a problem with a massive, unreliable, insecure ecosystem of legacy C code

A ton of the world's software with the highest reliability requirements is written in C and C++.

Nuclear power plants? Yes. [1]

Joint Strike Fighter? Yes. [2]

Mars rover? Yes. [3]

Your Tesla? Yes [4]

US telephone systems. Stock exchanges. Bloomberg. Your cell phone OS (incl. many years before smartphones). The list goes on and on.

C and C++ are the most general and well-supported languages we have. They can solve problems on any architecture with a good tradeoff between efficiency and generality (over assembly) and predictable performance. Reliability and security requirements are up to the developer to impose on any language (see: the github PHP SQL injection search). C is not, in itself, a problem towards these goals and those who build upon C are always improving it [5].

[1] http://www.nrc.gov/reading-rm/doc-collections/nuregs/contrac...

[2] http://www.jsf.mil/downloads/down_documentation.htm

[3] http://compass.informatik.rwth-aachen.de/ws-slides/havelund....

[4] http://www.pcworld.com/article/260883/tesla_cto_talks_model_...

[5] http://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx

betterunix9• 13 years ago

"Reliability and security requirements are up to the developer to impose on any language"

This is a common fallback in these discussions, but it is misguided. Yes, you have to work to make software secure in any language; no, this does not mean C is equivalent. In C, you still need to worry about high-level problems like SQL injection, while simultaneously having to worry about low-level problems like integer overflows, dangling pointers, etc.

That critical systems have been written in C or C++ is not relevant -- it does not mean that it was a good idea to do so.

11235813212• 13 years ago

The use of C and C-likes by the JPL rather than Lisp is a sad story; it means robotics has not advanced as fast as it could have. http://www.flownet.com/gat/jpl-lisp.html

oinksoft• 13 years ago

Several of your examples are hard real-time systems. Garbage collectors, schedulers, etc. are a no-go in such environments, so you won't see much Python or JavaScript there, but that doesn't discount the value of those languages. Note that Ada, a high level language, is used in similar systems, and that Lisp has been used in NASA satellites. High-level languages like Erlang are used in telecom systems and other critical network applications.

The fact is, languages created in the early history of computer programming have had the opportunity to be used in high profile projects like the ones you brought up. In time, you will undoubtedly see Python and others used in such contexts.

ssw1n• 13 years ago

Let me add in one:

[6] Fire Safety and Building Security Systems? Yes

pjmlp12• 13 years ago

As a Turbo Pascal refugee, I agree 100%

zedshaw4• 13 years ago

Not really. What we need is people not learning C (or any language) without also learning how writing it wrong causes defects. In my book (mentioned in the post) I have students using Valgrind and attempting to break their code starting at the 4th lesson. I also show them how and why to avoid defects in C.

Instead of saying "no new C", we should probably be approaching it with a two-pronged attack. First, tracking down bad educational material and making sure new C coders learn how to make safer C. Second, fixing the older code so that it is safe by default, rather than only in the context of the code it's written in.

But, yeah pipe dreams and all, so I just work on improving the educational material.

Intermernet• 13 years ago

Thanks Zed, I really can't upvote you enough! I absolutely love the style of your writing, and the "hard-way" approach to teaching. Keep up the great work :-)

pointyhats2• 13 years ago

C is easy to get right. Its also easy to get wrong.

To be honest, most holes I've seen over the years are above the level of the language and are down to the implementation or design being flawed. For example SQL injection, silly business processes, elevation flaws, bad maths etc.

koffiezet• 13 years ago

When I read "C code" in this thread - I assume people mean C and C++ together, since they're both capable of the same low-level stuff.

The thing is, the new compilers, static analysis, JIT'ing, ... available these days for C++ makes it the best time ever to write C++ in a reliable way, and being technology that is being used in the real world, this will only improve.

There's a reason the C++ language is undergoing a lot of changes nowadays, for the better. After years of no movement at all, C++11 finally arrived, supporting features improving general reliability and memory-management (single pointers, smart pointers, auto type, ...), and C++14 is on it's way. While old programs will still work, the core language evolves and so do the generally accepted standard/best practices, that when generally accepted provide very reliable code.

I work on quite a large C++ code-base, and both our test-team and static analysis tools rarely find "programming errors". Functional bugs - sure, you still have those like you have in any program, but real end-of-the-world memory corruptions or leaks are rare to completely absent. The only tricky part I guess is threading, although analysis tools have massively improved here - and this is an issue in pretty much every language that understands threads.

The nice thing about learning C is that you get to understand what exactly is happening, and while a functional language like Haskell is very cool and can in certain situations offer massive optimizations due to it's language and runtime design, it presents you with a non-existing world. C is an "easy" way to understand low-level for as far as it's useful. I fooled around with a lot of languages, including Haskell - and knowing C gives you a much better insight in what the runtime is actually doing, because you KNOW a CPU doesn't work like that, and you're able to quickly understand it's limitations and advantages.

Another way to understand what happens +- on CPU level is implementing a simple bytecode compiler and interpreter - in any language of your choosing, but for some reason, most "real world" interpreters are implemented in C/C++.

wmt• 13 years ago

I always felt shame that I knew C but didn't understand how the code works inside the CPU. Finally I got a grip of myself and got the book with the dragon on the cover, I managed to make my stupid C compiler. Turns out, it's not that hard, and doing that finally helped me understad stack and heap much better!

It also gave me the confidence to look at how bytecode based languages work -- turns out they're also not magic, and can be understood my mere mortals.

TLDR, assembly and compilers can be understood, and it'd fun too!

danso• 13 years ago

For anyone who hasn't browsed through Peter Seibel's "Coders at Work," one of his subjects is Fran Allen...it's kind of funny because I do agree that learning C has been valuable to the high-level programming I do today (but only because I was forced to learn it in school). But there's always another level below you that can be valuable...Allen says C killed her interest in programming...not because it was hard, but because of, in her opinion, it led engineers to abandon work in compiler optimization (her focus was in high-performance computing):

(Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Location 6269). Kindle Edition: http://www.amazon.com/Coders-Work-Reflections-Craft-Programm... )

Seibel: When do you think was the last time that you programmed?

Allen: Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue....

Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels?

Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities.

habitue2• 13 years ago

I think she might have given up on programming a bit prematurely. The pendulum has obviously swung completely the other way with high level languages like Haskell pushing forward compiler optimization, and JIT VMs pushing forward in other directions. It's actually an exciting time for "smart compilers".

irahul2• 13 years ago

> I think she might have given up on programming a bit prematurely. The pendulum has obviously swung completely the other way with high level languages like Haskell pushing forward compiler optimization

C compilers were optimizing long before Haskell. From her interview, I don't understand why she couldn't work on optimizers even if someone else advocated optimization being programmer's repsonsibility?

anuraj• 13 years ago

There is no pendulum swing - Haskell remains a niche - C and its off springs are still mainstream. Have you ever checked statistics?

http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

http://www.langpop.com/

C still remains the only accessible low level language to do systems programming. C compilers have been optimizing for long.

mc-lovin2• 13 years ago

While I'm very sympathetic to Allen's viewpoint, it seems that there was, and still is, a large class of problems where C-like languages (where the programmer does the optimizations) are better than high level languages with optimized compilers.

The best example for her case would be Fortran, where the language is both higher level, and faster, because the compiler can make much more assumptions (my understanding is the restrict keyword somewhat evens the playing field with C, but that is kind of a hack).

However, plenty of numerical work is also done in C, in spite of Fortran's availability.

foobarbazqux• 13 years ago

Actual song from PLDI'07 where she received the Turing Award, which we all sang to the tune of Take Me Out to the Ball Game:

  Let’s all sing to Fran Allen
  For the great things she’s done.
  PTRAN and Blue Gene and E C S
  Fran, we’ve gathered to toast your success.
  As we ponder all you’ve accomplished,
  Our colleague extraordinaire,
  Here’s to you, Fran Allen, you’re truly beyond compare

  Optimizing compilers
  Parallel transforms too
  Intervals, call graphs, and data flow
  Keep our programs from running too slow
  So we root, root, root for Fran Allen
  Her heart, and spirit, and voice
  For she’s won the Turing Award and we all rejoice!

She said that she believes functional languages and programs are key for scalable parallelism on massively multicore processors, because of the unavoidable performance problems associated with synchronization on shared data dependences in imperative languages.

The back story you quoted about C motivates her position a little, so thanks. It seemed like few of the hardcore compiler people that I spoke to at the conference seriously believed functional languages were going to be the future because of performance reasons, although personally it doesn't seem like an entirely unreasonable proposition.

tracker13• 13 years ago

Using functional paradigm with immutable types does take care of a lot of the complexities of parallel computing... It allows you to make a lot of assumptions (from the underlying platform's perspective) and can break up work in very interesting ways, not just across cpu cores, but even in distributed computing environments. If you combine this with a scriptable language, you can even carry the workload with the code to operate on the load.. which takes things a bit farther. You could create a literal farm of workers that grab a bit of data, process it against the defined load, and then return the result with the next step to run against the data...

I've wanted to create such a system for a while.. right now the closest I could come up with would be to use nodejs with json and a message queue to handle requests/loads. Unfortunately, there's a pretty serious cost to the json serialization, and other issues... but it's an interesting idea that has merit. I think in the end such a system will have a quickly serializable binary expression of both the data and the work to be done.

The catch is that most developers I know aren't used to breaking work up in such a way that it could be very parallelized.

munin• 13 years ago

writing optimizers in C is much harder than in Fortran because of reduced abstractions and reasoning about memory and pointers. in Fortran they were working on making automatic multi-threaded optimizations where you would write Fortran and it would auto-parallelize into multiple threads ... before C was invented.

C did kill a lot of work on making computers easier to program and safer. it was a devils bargain for speed and we paid for it with decades of crappy code with buffer overflows and shared state race conditions. it's tricky to know if it was worth it.

vbv• 13 years ago

Get the C t-shirt for the C hacker in you: http://teespring.com/c-faster

obviouslygreen• 13 years ago

While I certainly agree that understanding the "how" will give you a better appreciation of the "what" and a more thorough understanding of the "why" behind many languages (I was one of the obnoxiously vocal detractors when American universities overwhelmingly moved from C/C++ to Java), I think this goes a little far:

When you internalize these lessons, your approach to programming will completely change.

You can know which parts of a language are heavier without knowing how they're implemented. Granted, this is certainly not the same, but in a practical sense it is certainly close. Your approach to programming will only "completely change" if you've been doing things with absolutely no understanding of the performance impact of the choices you make.

There are certainly people in that situation, but anyone who has had to do any profiling to find bottlenecks in code (which I would guess means most people who have been involved in professional development for more than a year or two) likely has at least an idea of which data and control structures are going to cause issues in languages they've used at length.

So yes, I agree that understanding what's going on is good... but not everyone has the time or inclination to delve into the depths of C, and there are other ways to come about a useful understanding of language internals (e.g. actually reading about a language's specific features rather than simply guessing at their implementation based on the assumption that they're written using standard C idioms).

stiff• 13 years ago

What you really want to say is not "learn C", but "learn computer architecture, algorithms and programming language semantics", C just happened to be the most convenient medium for this for a long time, but today there are perhaps better choices, like Go and I really hope C will finally go away one day, while people will still have to understand things like indirect addressing, hashing, pass-by-value vs. pass-by-reference an so on and so forth.

asveikau5• 13 years ago

> You’ll realize that Object Orientation is not the only way to architect software.

Actually, pretty much all the "good" C code I've seen is using some form of object orientation, for example using structs with function pointers, or information hiding through incomplete types and void pointers. I think the better observation is that you don't need much language support to do mostly-OOP.

That and a lot of people in those "other" languages are using language support for OOP as a bit of a mental crutch. (For example, many people working in Java or C# especially tend to write lots of indecipherable OO spaghetti.)

btilly3• 13 years ago

People who use the preprocessor heavily tend to use a fairly non-OO design.

See http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html for an interesting example of a design technique enabled by that. I also note that said technique is problematic in practice not because it isn't good - it is - but because it causes people to suffer a brain freeze.

asveikau5• 13 years ago

I tend to see these as orthogonal. What does a macro do but generate more code? So shouldn't the use of macros be reducible to ordinary code? That, and you can still employ this stuff at the micro level and your chatter between compilation units or library boundaries can still be OO.

jussij• 13 years ago

> For example, many people working in Java or C# especially tend to write lots of indecipherable OO spaghetti.

I would contend that there is nothing OO about the spaghetti they right and you can write spaghetti in any language.

But I tend to agree it probably is easier to create spaghetti using OO languages.

My take why this is comes down to the fact, to do OO correctly needs a hell of a lot of up front OOD (i.e. don't start coding until you've done you OOD).

Most OO places I've worked do next to no upfront OOD before starting to hack out the code. It's feels more like an OOD on the run development model.

pjmlp12• 13 years ago

Please don't.

Learn Delphi, Free Pascal, Modula-2, Ada, Oberon(-2),... and see how it is possible to have down to the metal strong typed languages with native compilers.

Then understand that C and C++ ubiquity is an historical accident due to the way UNIX spread across the industry.

sliverstorm3• 13 years ago

Accident? C did exactly what it was designed to do; allow UNIX to spread to other architectures.

pjmlp12• 13 years ago

Any high level language would do it in a time and age where most OS were still 100% coded in Assembly.

Lets say UNIX used PL/I or Algol 68, the article would be called "Learn PL/I" or "Learn Algol 68".

peterkelly• 13 years ago

Film at 11.

uggedal• 13 years ago

I "learned" C by writing a smal runit/daemontools replacement. Most of the work was learning the features I needed from libc: http://uggedal.github.io/going/going.c.html

bmoresbest55• 13 years ago

I have to totally agree with this. I have almost completed Learn Python The Hard Way and it has been very good to me. I have been programming in many different languages while in school (I just graduated this May, lucky me...). I must say that this might be the most complete way that I have seen to learn a new language. I am definitely doing Learn C The Hard Way and I am definitely going to donate/pay for these materials. They are extremely beneficial to any programmer even if you know all of the information.

zedshaw4• 13 years ago

Thanks! Glad you liked my book.

Any criticisms for improvements?

rmrfrmrf• 13 years ago

Please please PUH-LEASE read "The C Programming Language" if you're going to learn C. It is THE most important programming book I've ever read. No other book comes close to concisely and elegantly describing a language.

gnuvince2• 13 years ago

If K&R is the most important programming you've read, you have many more books to read methinks :)

amasad• 13 years ago

While I agree that all programmers should learn how computers and compilers work. Learning C would just be a mean to that end. You could easily replace "Learn C" with "Learn Assembly" in this post.

I think these type of posts reinforces the over-emphasis on languages, frameworks, and tools in general we have in this industry. People restrict themselves into camps of certain tools and then use that specific tool as a general purpose tool for all problems they face in a sort of nationalistic way. And then go on the internet and start arguing over which over-used hammer is better, so to speak. Now, what is worse is that newcomers to programming quickly adopt this attitude which makes it even harder for them to learn the right things.

The other day I made a trip to the Academy for Software engineering NYC[1] and it was a great experience watching kids learn how to program. They were using Python to learn. However, I was really disappointed when a few kids expressed interest in learning Foo language because someone told them that Foo was the best language ever! I told them that after learning how to compute, they can go on and learn all the languages they want to learn and even create their own.

[1] http://www.afsenyc.org/

kuchaguangjie• 13 years ago

There is no doubt that learning c & assembly language, help programmer to understand higher level languages better, even though they will not use c or assembly in their real work.

sengstrom• 13 years ago

Crap - is C a low-level language now? My view on the world is going to have to adjust.

smegel• 13 years ago

> You’ll realize that Object Orientation is not the only way to architect software.

I don't think C is really the way to learn this lesson - try a functional programming language to really get a feel for an entirely different programming paradigm.

shmerl• 13 years ago

Somehow I thought that C is usually in the curriculum of any CS oriented university / college program, so most have at at least rudimentary knowledge of C.

NTDF• 13 years ago

Very interesting thread. I moved to SV a year ago and my perspective on how modern programmers think has changed enormously.

As a background, I am a software engineer on route to being a cpu architect. My job is to understand how hardware works and what changes need to go into the instruction set to allow modern software work better. I have some thoughts to share.

I also think that a lot of folks in HN are true software engineers with little hardware background. So, most arguments simply gloss over why (or why not) use C.

Let us all be very clear. C is not a great language for app development. This comes from a person who has worked his entire life with C. I have no qualms in saying this.

C is primarily just an abstraction over assembly (not the same as machine). With this in mind, you can safely assume C to be a "stateful" language. By "stateful" I mean, each statement gets "executed" and the state of the CPU and memory changes. The fact that multiple assembly instructions can get produced per-line of C is what makes it better than lower languages.

That is all that is there in C. Everything else is an add-on. The standard library functions (strlen(), printf() etc.) are all essentially a few assembly instructions clubbed together.

Now, as it turns out, oop and other paradigms were created for the sole purpose of making it easy to program. In other words, we want to lower the barrier of entry into programming and have more programmers do things that they would normally never be able to do. We were ready to take a performance penalty with higher level languages so that more people can make useful stuff with a computer.

For example, oop was made to create the illusion that a program really is objects interacting with each other or functional execution. However, folks well versed with the computer know that oop is eventually executed sequentially.

The whole eco-system of web and app developers is able to thrive because they do not have to deal with 'nasty' (I personally find them amazing) issues of why things work the way they do. Let's just say that programming is becoming commoditized and the barrier to programming is made lower by them not having to deal with these issues. If we were still programming in C, most programmers would have dropped out of their CS classes when they were freshmen.

An analogy would be you don't need to understand the internals of a combustion engine to drive a car.

So, should everyone learn C? As someone who cares about expanding the powers of a computer, I do not think wasting resources on it is worthwhile. There are enough people maintaining C and using it for great purposes. Commodity programming (application level) should not involve C as far as possible. Cpus are fast enough to handle bloatware languages. I would personally prefer people thinking of newer languages/paradigms that would expand on what people can do with a computer.

As a programmer, you do not need to learn it. It is certainly helpful and I would definitely encourage folks to try to understand it, if you are curious. But no point wasting your time on it if all you are going to do is application level development.

Now, if you are working on something really deep and involved, the story changes completely. For example, folks working on router/switch programs, fast search engines, OS, devices, simulations (basically everything cool in my biased mind) need to understand it.

An analogy is that an you do not need to understand nitty-gritty details about engines unless you are building something in the range of a Ferrari.

Just my thoughts.

kyllo2• 13 years ago

Thanks for this, I'm going to work my way through Learn C the Hard Way. I started on Java, but now I use a lot of Ruby and Python, and both of those languages' original/main implementations are both written in C, so I want to learn how C works.

ergest• 13 years ago

I agree with the original poster. Learning C definitely allowed me to understand (and feel) the code from the inside. If you just use a Hashmap or Array without knowing how you'd do it in C, you're just playing with Lego pieces. (I also agree with his view on C++ but I won't poke that hornet nest)

peripetylabs• 13 years ago

There exist proof and verification tools for C, like ACSL and Frama-C, [1] or LCL and Splint. [2,3] Not to mention the myriad of static and dynamic analysis tools. You can prove that a piece of C code does or doesn't contain certain bugs -- this is not the case for higher-level languages (except perhaps Haskell and ML). That is why C is used for highly sensitive projects like avionics.

I would say: learn C and high-level languages.

[1] http://frama-c.com/acsl.html

[2] www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-74.pdf

[3] http://splint.org/

Learn C

Related Stories