Hacker News Reader

Comment by ubernostrum | Hacker News Reader

There are two extreme approaches to "Real programmers do X".

One approach is rooted in electrical engineering, and declares that real programmers are the ones who get as close as possible to the hardware.

The other approach is rooted in mathematics, and declares that real programmers are the ones who get as close as possible to formal models of computation.

Both are narrow-minded and flat-out wrong. Real programmers understand that context is king, and that everything they will do is a trade-off decided by some factor of the project they're working on.

View on HN

I agree with this. However, I would like to mention a somewhat implicit point in this. REAL programmers (TM) are usually ready to change their works context if it is necessary.

This observation struck me quite hard, especially now with the software project where I need to interact with lots of other students on a programming level. Usually, when there is a technical problem with the build scripts, library dependencies or other hard problems, the group divides into two groups (one small group and one large group).

The large group just stops doing anything and goes "well, someone will fix it. I don't know anything of this, I never touched this, I will just stop until someone fixes it."

The smaller group on the other hand grows highly active in such a situation. They ask around if someone is working on this, and if no one does so, they just go "Bleh, I hate this, I know nothing of this, where is the ant documentation, git's hard reset and coffee?".

More abstract, the better programmers (let's call them developers :) ) accept that their work context extends from the simple code cutting into fixing the build script, getting dependencies to work and handling other technichal things while the coders just don't accept this and go 'not my context. Stop work'

The funny thing is, very often, the larger group starts to complain about the smaller group, because the smaller group just knows such a lot of things already and they just assume that everyone knows these things (hey, a master's degree programmer who does not know the decorator pattern, despite having java as a primary langaige...), but no one from the smaller group actually starts learning things out of their context... meh.

I'm a mathematician, yet I'm still part of the do-most-things-in-C camp. I don't think this contradicts your point, though -- I find that C provides a far more well-defined model of computation than scripting languages like perl.

I use C more because I want to know what my code is going to do than because I want to know how it is going to do it.

As a query, have you looked into lisp at all? I've seen (through HN) examples of stuff like derivatives expressed quite elegantly using Lisp.

Using C for maths programming sounds fun and all, but I'm sure there's got to be a better way of doing things.

lisp is also nice for testing arguments, like 0 < a0 < a1 < ... < an < 999, ai ∈ integer

(and (< 0 a0 a1 ... an 999) (apply and (map integer? (list a0 a1 ... an))) (foo bar))

I've tried lisp; but for one-time hacks where I'm not aiming for performance or robustness I usually go to the extreme and use Maple.

IMHO there's one more thing that's often missing from the articles about "embedded systems". What kind of embedded systems are they talking about?

Your microwave controller is an embedded system. So is your mobile phone. And so is a crazy, industrial, programmable controller with hundreds of I/O ports controller for an assembly line. It takes about the same time to write the microwave program in C and in asm, but you'd be insane to program something like iphone only in assembler.

Also, it's a bit suspicious that there's no verilog and similar languages on those graphs...

I agree somewhat - always use the best tool for the job. But, if you CAN'T use C, then you are not a "real programmer".

I usually use the distinction of "programmers" and "engineers" between people who know how to use a programming language and people who know how to build a computer system.

Long long ago I worked for a bank, we had essentially two classes of programmers, Application level programmers and Systems level programmers, the barrier between them was pretty formidable.

These days the lines are much more blurred, and that's why this argument is even possible. The 'real men' of old were the systems programmers, they used to use assembly.

I remember reading something similar in dr dobbs years ago that had exactly the same argument going, 'real men' write assembly, everybody else uses C (which was still considered to be a high level language at the time).

Our definition of 'high level' is shifting, and apparently so is what we consider to be 'real programming'.

C is more like (old style) lego, the bricks are small and simple but you can build very complex stuff out of it once you master the principle. It will do very little 'out of the box' but once you get it your limits are your fantasy, there are no 'domain specific' bricks.

I wonder how much of the reasons for these preferences can be traced back to what you were playing with as a kid!

Reply on news.ycombinator.com