Monday, June 23, 2014

Useful OSX-specific command line tools

Life-hacker has a short list of uses OS X command line programs that aren't just standard GNU/*nix commands: http://lifehacker.com/eight-terminal-utilities-every-os-x-command-line-user-s-1593793109

This mentions homebrew, which I hadn't heard of before. This answer to a stack overflow question about what are the differences between homebrew and macports gives some info (install location, user space vs sudo use, number of packages, support for multiple versions etc) but may not be enough to allow a definite decision on which to use without some experimentation. For science it appears currently homebrew has some but not all of the standard packages I'd expect.

Thursday, June 05, 2014

The (Forever) Language War

I generally find comparisons between programming languages to be a waste of time given they're largely based on personal preference over objective metrics, and even metric-based comparisons are often superficial or downright misleading (yeah, I'm talking about you Julia). Generally my view is use what best fits the application modulo your expertise, and the language doesn't really matter - it is an implementation choice.

That said, I've lately being feeling rather down about C++ which is the language I develop in most heavily. Sure, it has speed and expressive power but some of the most powerful features are semantically non-trivial and most galling of all, it really doesn't come with many standard "packages" in the way Java and Python do. OK, it comes with the STL, which I do like, but then you have to go to Boost, and then you look at how some of the Boost packages are coded and you wonder if it is even the same language. In a very large and complicated project I find the developer (or more technically, integration troubleshooter and debugger) role to have low productivity. It isn't as bad as perl but it is easy for "other" programmers to write code that is just overly complicated for the job. Oh great, someone has learnt about the Abstract Factory pattern, and has decided to use it everywhere: attempt to drill down through layers of unnecessary obfuscatory abstraction (that manages to be coupled to a million other things instead of decoupling the way abstraction should do) to find what some code is actually doing. Analyze, debug, code, compile ... ... ... and run again, all while you have a supposedly critical release deadline looming.

It is easy to forget the problem what C++ set out to fix, which I was reminded of when I starting reading "Learning OpenCV". Now OpenCV is a wonderfully powerful open source library in my opinion, based on mainly using it before now through its Python bindings. But reading how to use the C API was eye opening. What, I have to remember to delete those resources? Oh great, void* pointers and I have to remember what type to cast to/from. I could just imagine the fun bugs someone had to deal with. Suddenly C++ didn't seem so doddering.

While reading about Apple's new Swift language at Slate.com (Another new proprietary language to tie developers to Apple and in darkness bind them, how exciting for the Mac fan boys!) I came across a link to a discussion by David Green comparing his experience trying out both iOS and Android development tools. The comments are the article reveal the pattern that makes me dislike language comparisons: In a discussion of X and Y you must be biased toward X because you know more about it X so really X and Y are equally good. (There should be a name for this fallacy but I can't seem to find it). However the article itself is worth a look, because it compares the iOS+Xcode+Objective-C platform to Android+Eclipse+Java platform in terms of ease of development. I've always been somewhat curious about Xcode and Objective-C, but David Green's article is enough to stop me wasting my time. What the commentators on his article don't understand is that while you can do great stuff with Xcode and Objective-C it has placed extra hurdles in your way: the extra verbosity needed in the language, the extra time it'll take to hunt down solutions to non-trivial problems. That time might not matter to some developers, in particular to Apple-only developers, but it will to matter to someone and it certainly matters to me.