
The practice of programming, 18 years later - f2f
https://blog.kjamistan.com/the-practice-of-programming-18-years-later/
======
gtrubetskoy
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.

~~~
falcolas
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!

~~~
eropple
_> 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.

------
NumberSix
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).

~~~
Aloha
> 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.

------
ChuckMcM
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.

------
baguette
> 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.

------
ptero
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.

------
nickcw
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

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

~~~
nickcw
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.

------
petercooper
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.

