These are questions for wise men with skinny arms

Learning F# as part of a real project is more than just the application code, it’s everything that’s involved with building up the system requirements to deploying updates. At this point in my adventure my attempts at working FRP into the solution weren’t proving fruitful, so I found it easier to focus on the rest of the ecosystem and other aspects of the solution. Testing There was an upside to creating a system that didn’t work; to discover why it didn’t work I needed a much more powerful testing framework than before.

This is continuation of my previous journal on working with F# in comparison to an existing C++ program and supporting Python systems. It ended on a still-prototype level system that was heavily OO, but used some of F#‘s nicer type and syntax features to cut down boilerplate and organizational complexity. F# was easy enough to learn and use, but I was looking to push the system from a prototype to something more polished.

A coworker was talking to me about how difficult it can be sometimes to explain technical problems to non-technical users. Most users want to know how the system works, especially if it’s critical to their daily responsibilities, but it’s important for software developers to draw a line where the domain ends and the technical details remain. Saying a problem was caused by a key consistency error from something strange with Posgres sequences should not mean anything to a user wondering why restoring old data didn’t work.

I’ve previously mentioned a passing interest in F# because it was sufficiently different from languages I knew and had many concepts that sounded immediately useful. It took me almost 2 years to take the plunge and implement a non-trivial app in F#. It took 3 tries to get something that felt usable and idiomatic. This the first part of my journal of lessons learned. Starting out I didn’t buy any books or take any classes, but I did read every bit of literature online before writing anything at all.

Planning for things to go wrong is important. Even with all the ounces of prevention, there still needs to be some cure to catch what slips through the cracks. When anything breaks there are two parts: Knowing what broke and a solution to get things working again. I’ll take three examples: Bicycle, application, server. Bicycle I got flat tire, it took me longer than I’d like to admit to notice it.

I started off my career thinking that coding was the hardest thing I had to do every day. That fixing bugs, building features, and writing documentation was the toughest part of building software. It’s what I spent all my time studying in school, so I figured that once I knew how to code well enough to make things work, the rest of the job would be easy. I heard “The first programing language is the hardest”, so I expected to struggle with the basics.

Once upon a time my primary editor was vim. I picked it up early in CS1 after hearing about the dreaded emacs pinky and used it at a novice level until I left college.I never stuck in an any single environment for long enough to become accustomed to any default bindings. Eclipse (and family), VS, Processing, Matlab, Notepad++, NetBeans, KWrite, Textmate, GEdit, Anjuta and vim were all about equal with familiarity.

A Reintroduction I’m moving my content from tumblr to here. I only used tumblr before because it was resonably public and seperate from other blogging and social networks that I already had established. Now I have a dedicated site serves that same purpose (with a higher cost to me of course). Tumblr had fine formatting tools and tagging, but since I didn’t visit it often or interact with anyone on the site I figured I might as well just make my own island for this stuff.

A recent project had me looking for cheap micro-controllers that are supported by a particular industrial automation platform. As part of this, I found that the most readily available micro-controller runs on 16-bit DOS and the last supported compiler is more than a decade old, so it carries this disclaimer: The Software was not designed to operate after December 31, 1999. It may be incomplete and it may not function properly.

I’ve wanted to work in a pair programming environment, but it was always difficult to justify the lost initial productivity of two programmers working on the same task. When the tasks are numerous and trivial it makes sense to break them up so they can be solved in parallel. Even when an individual task is difficult, I’ve found that it can be even more challenging for two people to see the same solution to a problem.