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.
> 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.
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.
Can you explain to me how "elaborate on your problem in such a way as you would explaining it to a colleague, because explaining it often leads you to a solution" is either "devaluing the seriousness" or a "gimmick"?
You can talk to the wall, too, if you want. What's wrong with the duck prop? Is there merit in such Grave Seriousness?
Right, the particular prop is irrelevant to the practice. If my cat happens to be in the room, I might talk to them, or I might just talk to myself (appearances be damned!).
If it helps you, I find myself performing the role of the yellow rubber duck at work with reasonable regularity.
Person or inanimate bath-time toy, neither devalues the seriousness of a technical problem that needs solving - the other person explaining their problem helps _them_ build a better mental model of it. Normally I don't even need to talk. I just quack afterwards (for completeness).
It undervalues our profession in the eyes of other that are not part of it, heavily. It also undervalues your dedication to your work in their eyes. Your coworkers and others may not say anything to you, but from personal experience, your bosses will notice what you are doing and you will be skipped from promotions and seniority.
With the best of my intentions, and please don't take it any other way: If you want seniority, and the compensation and perks that come with it, plan for it much in the same way you plan development.
Thanks, I appreciate the comment (and your intentions), however working in a Swiss company with a _lot_ of German speakers (plus actual Germans, too ;) ) I can assure you that if the occasional 'quack' was the issue something would have been said a long time ago :)
EDIT: Now self-deprecating humour, that has been an issue :D
EDIT2: I mean _other_ forms of self-deprecation, not quacking.
Seriousness is overrated. Most of the technical problems are dry and benefit from a bit of frivolity. That doesn't contradict working hard or respecting your colleagues. But you don't have to respect a rubber duck.
