Colas.Nahaboo.net - programming

One year retired

2022-02-24T00:00:00+00:00

I have been retired for one year now, and what happened? Well...

I basically stopped coding and reading about anything computer-related for eight months. I didn't expect it, I was thinking I would start coding at once, going through my huge todo list of various projects.</li>
I enjoyed being able to go SUP surfing at will, but I ended up actually less on the water than before, simply because i didn't feel pressured into going on the water if the conditions were not enjoyable: I have now all the time in the world, I can wait for better conditions.</li>
I started what I should have done years ago: Stretching at least 30 minutes daily, and warming up a full 10 minutes before going surfing. Work and play for me were mainly sitting in front of a computer, and I had become awfully stiff. I will detail my routine in later posts, it is worth it.</li>
I dived deep in modern physics: astrophysics, cosmology and quantum mechanics. This also will warrant a full separate post.</li>
I started re-coding in the last four months:
- The first month I began working on various bits of code (shell scripts), progressively getting back to speed, and also deciding to learn the language Go. I was looking for a very longtime for an efficient language to replace lisp or C as compliment to scripting (I never liked Java), and was hesitating between Rust and Go. A discussion with Olivier Arsac</a> convinced me to try Go.</li>
- I switched to git (I was using mercurial) for version control, and moved</a> my publicly available source codes from my personal web site to my GitHub</a>. It may sound ridiculous, but at now 61, setting things up so they do not disappear when I do is becoming an important consideration. I will thus progressively stop using self-hosted sites to publish on places that will survive me, as nobody in my family is tech-savvy enough to maintain a web site.</li>
- Then in December I stumbled upon the Advent of Code</a> challenge that I decided to do in bash for the challenge, and it was unexpectedly productive? I learned more in these 25 puzzles than in my last 10 years of professional bash scripting. You can see my solutions in my post Bash lessons learned with AoC 2021</a>.</li>
- Thus, after finishing the Go tutorial, I decided to do the previous AoC years in Go. And I just finished the AoC 2015 in Go</a>. This definitively made me a Go enthusiast, I realized that the designers of Go had exactly the same opinion of what should be a general programming language: They worshiped readability, simplicity, performance and maintainability while hating inheritance and the feature creep of most modern languages.</li> </ul> </li> </ul>
 That was my first year. And now, embarking for the next one!

Completed the 2015 Advent of Code challenge in GO

2022-02-24T00:00:00+00:00

And I completed the 2015 challenge! (see my previous post</a>). You can read my notes on it on my GitHub</a>.

This was quite interesting, and I thing a great way to learn a language just after completing its tutorial, as this challenge as a feel of "real life" situations, and allow for a variety of solutions, so that you can put different approaches to the test.

I forced myself to not look at the solutions available on the net, except for two cases:

Starting the 2015 Advent of Code challenge in GO

2022-02-09T00:00:00+00:00

I discovered the advent of code</a> in 2021, and did it in bash</a> for the challenge. But since I started learning GO, I decided to code the previous AoC years in GO as a mean to practice it. So, although my bash code can be useful to see some tricks of a seasoned bash programmer, these GO solutions must be considered as "student code".
So I started coding the 2015 year of AoC in GO, available on my GitHub: advent-of-code-my-solutions/go/2015</a>
The code is in GO, with some housekeeping scripts in bash.

My bash library on Github

2022-02-05T00:00:00+00:00

I have started to publish on Github, at colas-bash-lib</a>, my collection of various bash functions I reuse often in my bash scripts.
Fell free to copy and use in any of your projects or compilation of bash tools.
I have tried to make them the fastest possible, by avoiding forking sub-shells or external commands, and benchmarking extensively to compare the possible way of coding them. Of course, I will gladly accept suggestions or code to make them faster. But it means that error checking is often terse and minimal, and readability of the code was not a priority.
I have a kind of «anti-npm» approach, in that I copy these functions into my scripts rather that using hem as a true external library that I would load at runtime. It thus avoid installation issues, and the ependency problems that may arise from automated upgrades.

What is good code?

2008-10-22T00:00:00+00:00

I stumbled upon the blog post "Is it important to write good code?</a>" the other day, and became more and more ill at ease as I realized that I thought that I preferred the original code, that the author was trying to ridicule, over his new "improved" object-oriented version. At first I guessed this was another manifestation of the the "Worst is best" scenario - enhancements are often not worth the added complexity - but I realized that it was perhaps a more profound factor:
The original code is very good because it ... is small. It fits on a teminal screen, so an human being can read it at once and have less items to maintain in his short term memory</a> and also understand it easily because it follows a natural way of thinking with sentences using IF. This becomes obvious by reading the body of the blog post surrounding the code samples, where you can see that the author is using phrases such as "if I need this I do that", showing that in plain english, the if statement is the best way to make people understand what you mean. And making code that people understand is the best way to make debuggable and maintainable code.
At this moment I noticed the citation in the blog header: "Good programmers write code that humans can understand"
Indeed :-)
PS: I know I am a bit exaggerating the issues there, and that I unfairly nitpick on Fredrik Normé, but it is that it seems to me from my personal experience that the two changes I see most in my coding efficiency as I grow older is a decrease of my short term memory capacity, and that I make more and more typos where I realize I mix up totally words with totally different meanings but that sound the same, for instance writing "never" instead of "nether", making me suspect that our natural way of thinking may be much more language-based that I imagined...