The practice of programming, 18 years later | Hacker News Reader

The practice of programming, 18 years later

blog.kjamistan.com

165 pointsf2f20 comments

People like Pike and Kernighan is the reason I've invested so much of my time in learning Go lately. To some this may seem completely irrational, because you should pick a language based on its merits (e.g. does it support generics, etc), but for me, the books they authored and the software they wrote (e.g. Ken Thompson's contribution to what we now know as unix) says a lot more than a seemingly objective review based on language features. I guess time will show whether I'm right.

As someone who is writing Go (and Python) for a living: I don't regret the choice.

The lack of generics is annoying when you come across it, but it's relatively rare to come across. The seemingly foot-shooting flexibility of interface{} and Value are frightening from afar, but seem to "just work" when you use them in practice. Using them introduces just enough natural friction that you don't actually use them unless you need to. GC pauses have yet to cause a problem for me.

Error handling is still a bit of a pain, but I do appreciate being forced to think about error handling, instead of just relying on a global try/catch and runtime tracebacks. Yes, I know I should not be relying on a catch of last resort, but it never seems like the right place to handle errors ever naturally appears.

Good luck!

> The lack of generics is annoying when you come across it, but it's relatively rare to come across. The seemingly foot-shooting flexibility of interface{} and Value are frightening from afar, but seem to "just work" when you use them in practice.

...Unless you write code that treats types as things, and not as inconveniencies that the compiler foists upon you. At which point the problems of generics appear immediately.

Like, I'm glad it works for you (well, sort of--the more Go in the world, the more likelihood that I'm going to have to deal with it), but what you're describing really only works from one very particular mindset of software development that isn't super well-shared.

> Error handling is still a bit of a pain, but I do appreciate being forced to think about error handling, instead of just relying on a global try/catch and runtime tracebacks.

Go's method of "making you think about error handling" is not just "a bit of a pain" but really, really weak, though, and it ties back to the language itself not being particularly expressive. In a language with expressive generics, you just fold() across anything that can return an error because it returns Result<V, E> and you must handle both cases inline.

I am with you. There is a clarity of purpose and thought in their writing and work that causes me to trust them. Also a key reason I started playing with Go.

Programming has not changed much since the 1960's and 1970's when Unix and C were developed. Modern computer programming languages simply mix and match different features from the "Cambrian explosion" of experimental and production programming languages in the 1960's. Hence it is not surprising that books on general programming concepts and principles are still relevant years later.

C is still in widespread use in operating system internals, embedded software development (think wearables and Internet of Things), complex algorithms like video compression, and miscellaneous other fields.

Version control dates back at least to SCCS in the 1970's and has been in widespread use at least since RCS in the 1980's. I mention this because I occasionally encounter people who seem to think version control either was invented with Git (not true) or rarely used before Git (not true).

Testing software is not new. Testing fanaticism is new.

Things that have improved in programming are:

Optimizing compilers have improved and all but eliminated low level loop optimizations by hand and similar "micro" optimizations by hand. This has also largely eliminated assembly programming.

Computers are much faster than in the 1960's, not much faster than the late 1990's, which means many things can be done with scripting languages that were once too slow. Compiled languages like C and C++ still dominate at the very high end of performance.

Scripting languages play fast and loose with variable types which makes it easier to write code quickly, but makes it harder to achieve the speed of a compiled executable from a relatively strongly typed language (compared to a scripting language -- how strongly typed is C really with its casts, pointers, and other unsafe but useful features?).

Compiler error and warning messages are much clearer than years ago.

There have been some incremental improvements in programming languages like using the plus sign (+) to concatenate strings that have made many new languages a bit easier to read and write. Compare strcat(blatz, " and now") to blatz + " and now"

None of these, or other improvements in the last fifty years, are revolutionary advances that would obsolete an older book on general programming principles.

Computer programming remains labor intensive and often highly compensated because many of the problems and issues remain largely unchanged since the early days (1960's/1970's).

> Version control dates back at least to SCCS in the 1970's and has been in widespread use at least since RCS in the 1980's. I mention this because I occasionally encounter people who seem to think version control either was invented with Git (not true) or rarely used before Git (not true).

As someone who works in an svn shop - this annoys the snot out of me - yes, the distributed nature of git brings some decided advantages, but if all of your tooling, and all of your workflow is tied to subversion, the costs to change over perhaps exceed the benefits gained.

The debugging session has always been priceless. And its something that new programmers are especially challenged in because they are taught how to create programs not to fix them. I've helped people on IRC who just write a new program rather than try to figure out what is wrong with their existing code and that is so sad. Understanding why a program is broken is the key to understanding programming.

> If you think that you have found a bug in someone else's program, the first step is to make absolutely sure it is a genuine bug, so you don't waste the author's time and lose your own credibility.

I am thinking we need to create an open-source "10 commandments" website and this should be on it.

Kernighan and Pike (and other books of each author) is IMO almost as relevant today as then. It is short, clean, and even if examples seem obsolete they often contain useful nuggets of wisdom.

The blog post cites a few paragraphs, as examples. Read the book itself, it is a good one.

This site is blocked by my ISP's porn filter!

SafeGuard You tried to view kjamistan.com

The account holder has activated SafeGuard and this page is blocked by the category pn_pornography.

The account holder is me - I have children hence the filter

is this SafeGuard from safeguardtek.com? is this provided by your ISP directly? do you mind sharing which ISP provides this service to you?

I don't know where the ISP gets the service from, they don't say on their product pages. It is plus.net in the UK and they provide the service directly to their subscribers.

I had similar experiences with Programming Pearls (1986) by Jon Bentley last year. Most of the principles are still there, although the scales have changed somewhat.

Reply on news.ycombinator.com