Hacker News Reader

Comment by babarock | Hacker News Reader

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 project, understanding how it's written and start contributing than I have with C.

A few weeks ago, I was looking at the code of Qemu. The code relies heavily on preprocessor macros and some weird gcc-only syntax that made my head hurt. It was difficult.

I guess what I'm trying to say, my only problem with C is that it doesn't force the programmer to write in a clear understandable way. Or maybe that's just me.

View on HN

> The code relies heavily on preprocessor macros and some weird gcc-only syntax that made my head hurt.

The preprocessor is generally recognized as one of C's biggest flaws, is not for nothing that Ken Thompson, the first C programmer and the greatest influence on the language other than DMR himself, cut down most of the preprocessor when he wrote his own set of C compilers for Plan 9: http://doc.cat-v.org/plan_9/4th_edition/papers/comp

And of course Go has no preprocessor.

As for your second complaint, one can't blame C for gcc's extensions ;)

You should try Go, many people would consider it C's spiritual successor (or as somebody put it: the language the people who created C would come up if they had 40 years to think about how to polish and improve it), it keeps all the simplicity of C, while being probably the most readable language I have used, it is concise but keeps everything explicit, and figuring what code does is very easy, because code does what it says and says what it does, no dark magic needed.

I second your thoughts about Go. Much like the author of the post, I was really tired of Java and all the bloat that went with doing most things. I was going to get back into C and I had even blown the dust off my K&R. By random coincidence I saw a post about Go on HN and I've been using it ever since. It's a really great language. It does everything I wanted to get back into C for without any of the things I was dreading.

It keeps all the simplicity of C, without actually being able to write a kernel or device driver!

You can write kernels in Go, it even used to ship with a bare metal runtime and several people wrote kernels using it.

You cannot easily write device drivers for existing operating systems in Go because the existing operating systems provide a particular environment unsuited for Go and expect certain constraints from the device drivers themselves, constraints which Go breaks. In principle, it could be made to work.

The problem with the C preprocessor is that it's sat in a "sour spot" where it's often possible to use it for a task but only by bending it so far that the result is pretty ugly and not very comprehensible. If the preprocessor were less powerful it would be obvious you needed to use a different tool; if it were more powerful it wouldn't result in ugly messes; but it's sat in the sour spot in the middle.

(Make is another tool which suffers from 'sour spot' syndrome IMHO.)

Yep, but remember that both of these tools are wonderful if you don't abuse them.

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.

I have come to the exact same conclusion about Ruby. Finding the source of given behavior is where I tend to get the most annoyed. This is doubly so for any library which uses method_missing? or other bits of Ruby-dynamism. Yes, it can (and does) lead to terser, elegant code. But it also makes it challenging to analyze root causes, and I have become less enamored of this style as I have had to deal with it over the past few years.

In this respect method_missing? is analogous to (over)using C's preprocessors. It seemed like a good idea at the time, but...

This isn't directly related to your complaint, but the source_location method in Ruby 1.9 is very useful:

    > method(:gem).source_location
     => ["/Users/wycats/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems.rb", 1228]

if an object has not been excessively tampered with, the objects's __module__ attribute will give you where it was created.

The inspect module doc page is of great help: http://docs.python.org/library/inspect.html

Reply on news.ycombinator.com