Reading Before Writing
Another brain-dump on things that have inspired me to write about techie topics.
I kept reading about programming languages over the weekend instead of coding anything like I originally planned. I had a whole list of things I was looking forward to coding:
- Python - Complete feature for the BitPim filesystem view multi-select
- Dart - Compile from source for server-side use
- Go - Finish another round of optimizations for Boggle
- Go - Review the recent commits to Chihaya
- fish shell - Test bash source support for aliases
None of these even got started, but it feels like I made progress here after transcribing my //TODO list from G-mail tasks. Instead I read blog posts from 2004, lots of blog posts. I think I started with some Jeff Atwood ones before reading most of Steve Yeggie’s rants. Then I switched over to Paul Graham’s essays from the same time period. This marathon started on Friday night and ended just a few hours ago when I exhausted all my opened tabs.
I loved it. It inspired me and let me know that I wasn’t crazy about the things I’ve been noticing about languages and style. Maybe I’ve just read other pieces like Steve’s rants before in other places, because these attitudes seem to be popular in today’s programming culture. I’m not talking about Lisp and Emacs but about common problems that haven’t changed much in 10 years. The fact that these three were able to predict with pretty good accuracy some big trends still going on today show how in touch they were with the direction of technology.
I’ve followed these sorts of technical discussions before but never at the meta-level that permeates much of Yeggie/Graham’s posts. It was a guilty pleasure to read about someone trying something new and being successful and supportive! It wasn’t about being a technology hipster, it was about learning and testing new things for real gain. Programmers not trying new things would be like doctors not trying new drugs or treatments. There are similar real advantages and risks to being an early mover.
This reading marathon session came at a fortunate time. A prominent senior engineer posted an essay proposing D as a production language for future company projects. I don’t think I would have appreciated the essay as much, or have been as critical of it had these language issues been fresh on my mind. I’m really glad I’ve been able to switch from just coding blindly to taking the time to learn more foundational skills. Just last month I spent a day rereading Journeyman to Master and then a book on technical management. Before that I was spending my time on just writing projects, thinking that the ‘just do it’ would help me learn new skills. It wasn’t as effective as I’d hoped. Looking back, it was probably because I used the same inefficient techniques I had to do at work, I wasn’t introspectively critical enough to see that I had to aim before I’d hit my target. I know that other engineers at my company do have very efficient tools (vim plugins that got me curious). I’ll have to focus on developing those next before I start again on a programming project designed to test them.
I still want to ‘just do’ some things with new tools, but I think I’ll focus on learning it instead of just fumbling around with it long enough to do what I want it to do. So on that note, I’ll list the languages I’m going to focus on instead of the goal of the project. For these I’ll probably just re-implement a toy/game program for simplicity. The FP languages I list here have been bouncing around in my head for a bit, but all the Lisp/OCaml ravings will get me to commit it to my new FIXME list. This list is long enough that if I learned all of these to proficiency it would probably take me years, but I’m just going to focus on familiarity. I want to be able to read or understand the basics of the language and what it would take to implement something trivial with it. I found in learning Go that I was able to jump from understanding to implementing pretty quickly, but I also expect that the languages I’m listing will take me more than a week to become familiar. I don’t expect to be a polyglot, I just want to see what else I’m missing after doing C++ day in and day out.
- JavaScript - I think I need a re-introduction, since I think learning it along with Angular last time might have elided some key points. It’ll probably implement the toy program with Node this time just to keep me from trying to do a real web project with it. (which I have a handful of on my //todo list)
- Dart - A serious try this time, pitting it directly against my JavaScript lessons
- Haskell - Probably not much beyond “Learn you for great good”. It seems to be a well written tutorial, so hopefully the concepts themselves rubbing on me will do some good later.
- Clojure - Use to implement a toy program. It will be a good test of “Do I know enough to continue”.
- Scala - Mostly just to compare to Clojure, Java was my first language, so I assume Clojure will be the harder one to learn
- D/Rust - Undecided, probably neither, unless something really catches my eye. I’m looking for foreign food here, so hearing “Like C++, but safer!” makes me less interested
- Ruby/Python - I’d say I’m already familiar with Python, but coming back to it after all these other ones might give me some cool perspective.
This blogging thing is fun minus Tumblr crashing FF(30.0 stable! I wasn’t even using Aurora this time!) and transferring writing this in Notepad++ instead. 5k words and I still can push off talking about my Python adventure from more than a week ago!