Live data from Hacker News

A Boggling Return to C

thraxil.org

31–40 of 88 posts

Re: A Boggling Return to C

#31

maybe the biggest improvement in c programming over the last decade is valgrind, making purify-like debugging available to everyone. it's completely removed a whole class of annoyingly hard to fix bugs from my code.

This is why Zed pushed it so hard in Learn C the Hard Way. Some people actually had the gall to complain about him ensuring the noobies learned to use valgrind before proceeding to write any real code. Ingrateful dipshits don't remember what the pre-valgrind/dtrace days were like.

Is Learn C the Hard Way a useful re-introduction? Like the article, I need to re-learn C.

Last time I wrote anything in C was on Netware NLMs, and it has been long enough that I have mostly forgotten what I knew.

Re: A Boggling Return to C

#32
post #25

"By way of comparison, the Python program takes 1.5 seconds to run, so that's about a 10X speedup." Only tenfold? Interesting. While Python is surely not the slowest interpreted language around, a result like that borders on the performance of Java. That seems unlikely, especially given the fact that Python version uses worse algorithm. I would think about how big is the portion of time eaten by I/O - that is, actual…

>>a result like that borders on the performance of Java. That seems unlikely...What Java program and timings are you looking at?

Re: A Boggling Return to C

#33
post #4

I started with assembly language and I thought C was heaven. Of course, there are easier languages, there are more powerful languages, there are fancier languages and whatnot. I like Python and I adore Lisp. But I still love C most. C is the sweet spot where I can extend my programs to do high-level stuff while still keep my hands down on the actual hardware I'm programming. I like that a lot, probably because I grew…

Reading DJB's code can be both awesome in that his code is written clearly and neatly, yet at the same time it can be an excercise in frustration because he has foregone most of the standard library and written his own (especially string management, which is superior, in my humble opinion), so it can look foreign or weird to people looking at it.

The source to qmail/daemontools is a pleasure to read though and having read it I feel like I have learned a lot from what it has to offer.

Re: A Boggling Return to C

#34
post #6

I absolutely love writing C. Up until late 2011, it was by far the language I used the most. I am now learning Lisp (not exactly, I'm using Lisp in SICP), and use Python more than before. One thing I realized, is that reading C is more tedious than code in other languages. Sure that's a gross generalization and is not true for every piece of code out there. However, I find I have less troubles picking up a Python pro…

The one thing that I have trouble with in Python projects is that it can be very difficult to figure out where the actual object is from that is being imported.

  from somedir.somefile import objectX
Then when you go to somedir.somefile you find out objectX is nowhere to be found only to figure out later that it is dynamically created and added to that namespace and it can be imported in the file you've been reading because some init function was already called by the module "foo".

There are quite a few codebases where I have been hunting for the superclass for example so that I could see if it offered functionality I wanted or how it was structured so I could find out where some function was defined and what EXACTLY it did due to no documentation and it took me a while.

I love Python, don't get me wrong. It is by far one of my favourite programming languages, but sometimes it can be very non-obvious where something is coming from and how it is getting there. This may be more of an issue on a project to project basis, but it is an extra complexity that I have found can be rather annoying.

Re: A Boggling Return to C

#36

I'd love to have time to play around with C again. I picked up C back in the late 80s when I became convinced that no matter what other programming languages I knew, I wasn't going to be a "true" professional unless I could sling code in C and C++. Fun times. I also love the idea of using a trie here. That's something else I've been wanting to play around with for a while. Although now I'd do it in a functional langu…

I also think it really depends on how you are taught or where you start...

I started programming in C/C++ (my first book, I'll admit at age 9 was a C++ for Dummies book, it came with a compiler :P).

I have learned and use a lot of higher level languages, but I still think about data structures, I still think about what the best way would be for handling the data most efficiently, mainly because I don't want to rely on the language doing the right thing.

I've seen Java programmers though that then start programming in C++ or even C and never pick up the art of thinking about their data structures. I work with one co-worker now that went through the extreme trouble of implementing Java like enum's which have caused all kinds of "warts" and all kinds of issues because they are not enums and they aren't "real" classes.

Watching Java developers turn C++/C developers is really interesting, they bring all kinds of "bad" practices back with them and the code is worse off because of it!

Re: A Boggling Return to C

#37
post #13

Earlier quoted context omitted.

One can always write proper C programs without Valgrind: it is "just" a ( really useful) debugging tool. The utility of it is that instead of spending days trying to track down any mallocs missing frees, one can just run Valgrind to find them and their locations straight away.

I guess what my grandparent said, albeit in a slightly dismissing tone, is that relying on tools like Valgrind or Purify to produce good code makes for weak programmers. The days spent trying to track down missing frees can be reduced to hours with practice, and the programmer skilled in this hunt is less likely to forget the free in the first place. (As opposed to the programmer relying on Valgrind and not caring mu…

You should not be worried about this: even with valgrind a few bugs will take days of debugging to get fixed...

Re: A Boggling Return to C

#38
post #11

I wrote the same program in Clojure somewhat recently. Boggle seems to be a popular problem. https://github.com/dmansen/boggle

Nice. Implementing the same problem in Clojure has been on my todo list. Now I've seen yours though so I guess I'll have to think up another problem :)

Re: A Boggling Return to C

#39
post #22

I'm a student who learns C#, Java, Php, javascript... at school. I bought "C: A Refence Manual" to learn this summer... Hope it will make me a better programmer.

If you want to learn C, K&R is the right way to do it. C: A Reference Manual is excellent and is probably the only other C book you need, but only if you are already a C programmer, and only for what the title implies: reference.

In addition to K&R I always recommend "C Interfaces and Implementations: Techniques for Creating Reusable Software" to anyone who is picking up a long-term hobby or career in C.

Someone on this forum recommended it to me. It's been invaluable assisting me in refactoring major portions of a legacy code base. In a way, it's helped me bring the DRY principle to our C application. I write in C every single day though and it may not be applicable for a hobbyist/generalist.

Re: A Boggling Return to C

#40
post #31

Earlier quoted context omitted.

This is why Zed pushed it so hard in Learn C the Hard Way. Some people actually had the gall to complain about him ensuring the noobies learned to use valgrind before proceeding to write any real code. Ingrateful dipshits don't remember what the pre-valgrind/dtrace days were like.

Is Learn C the Hard Way a useful re-introduction? Like the article, I need to re-learn C. Last time I wrote anything in C was on Netware NLMs, and it has been long enough that I have mostly forgotten what I knew.

Yes.
Post reply on HN