CLI tools FTW

To make sure my Go skills are kept up to date, I’ve decided to attempt (will see how long this lasts) a useful CLI tool every few days to 1) help me work… and 2) keep me thinking about Go.

None of these tools will be huge, interesting or unique…  but they’ll keep the brain active!  But also, I really do think they will be useful (to me) in my day to day work.

So far I’ve got 2. One is a basic tail program (built for Windows but will work on anything)…. since, well you know… Windows doesn’t have a tail. 🙂   Secondly a similar program to tail but it parses and displays interesting parts of EventStore statistics logs. Basic, short…   got me thinking more about file IO in Go though 🙂

 

 

Advertisements

Practical coding vs “the fancy stuff”

How do I write this without sounding like I’m bashing on functional programming?

I’m not an FP convert. I get that having no side-effects can be appealing at times, but I do also believe that forcing every problem to be solved in a FP manner seems like the old “every tool is a hammer” type of situation. I recognise that what different people consider simple can vary a lot. Some people swear that FP is simple and that I just have to learn enough of it to appreciate and “live and breath” it. Hmmm time will tell on that one.

In the not-too-distant future I’ll be doing more F# (work), so will get to have more time to appreciate what FP can give me vs my heathen languages such as Go. But, in the case of Go, to me the language is SOOOO simple, so very few keywords, very basic concepts and a pretty decent (IMHO) standard library out of the box. Do I really care that more boiler plate needs to be coded every now and then? (especially for error handling?). Honestly… no. To me the code is readable, completely understandable and most importantly maintainable.

I’m still new enough to FP that my mindset isn’t naturally tuned to grok it immediately. No, I’m not strictly OO but I’m not FP. One of the main complaints that I keep hearing about Go is that it doesn’t have map, reduce, filter etc….  I’m not sure I really care.

IF I really wanted something (not generic… ooooo don’t go there) to do mapping over an array of strings (for arguments sake), yes, I could write up something like:

func mapper( input []string, myfunc func(string) string) []string {

   results := make([]string, len(input))

   for pos,i := range input {

     res := myfunc(i)

     results[pos] = res

   }

   return results

}

This is just a simple map type function. Give it a list (slice) of strings and a function that takes a string and returns a string. Bang, done… yes, it’s some utility method but is it critical for my codes readability or maintainability? Personally I don’t think so.

Same goes for filter, reduce etc. To me they’re utility functions that sure, sometimes I might like to use… and other times not so much. They don’t define a language nor state if it’s a good one (or not).

Even if I wanted to go down the route of making a generic version (fortunately I don’t have to, Rob Pike has already done it. ) But as he says on github

“I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn’t hard.Having written it a couple of years ago, I haven’t had occasion to use it once. Instead, I just use “for” loops.You shouldn’t use it either.”

I completely agree about using for loops. Yes, they’re simple…  they might look like “oh, this coder doesn’t know how to use feature X, so they went for the dumb approach”. But seriously, I don’t have issues debugging nor reading for loops.

I often felt the same when coding lots of C# in the past. Some co-workers (who I still completely admire) would be jumping into some complex looking (to me) LINQ queries. Apart from LINQ being a memory hog, I never EVER found them easier to read than a simple for loop. Yes, their code was shorter and as we know fewer lines mean fewer lines to debug. But these LINQ queries took TIME to read and understand. I know I spoke to other devs there and they also had the same experience of 1-2 people might instantly know what these LINQ queries did… but most others would need to sit there for a few minutes and figure it out.

You don’t have to do that with for loops (or any other basic component of a language). Maybe this indicates that I’ve just worked with mediocre devs (and a few stars) and I myself am just an ok pleb. But I bet that’s not the situation. Sometimes using simple primitives makes for easy to understand code.