December 19, 2014
October 4, 2014
Optional syntax is a popular feature in recent languages (or really recently popular languages, some of them have been percolating for a long time). Some languages also make parenthesis and commas optional for invocation allowing for "function arg arg arg" and sometimes even "object method arg arg arg" syntax. Optional end of line marks show up couple of places. So far all of the cases where I have seen optional constructs like this include at least one gotcha case where omitting or including punctuation are both meaningful but different.
I'm not a big fan. Optional syntax introduces a choice which allows me to avoid a cost. But the cost is tiny - typing parentheses and other delimiters takes very little time, and reading a language which uses delimiters is not hard. And the cost of making and in that one gotcha case mis-making a choice is notable. Programming productivity is limited by how many good choices you can make in a day, not by time or lines of code. I would prefer not to spend my choices on punctuation.
The end result, familiar to any C++ shop, is that you have to decide on what parts of the language you are going to use in your company so that you can stop making pointless choices and keep your code uniform and understandable. Only in this case it's not libraries or template tricks, but commas.
The argument I usually see for this sort of thing is that it allows the programmer to be expressive, which is a comparison of coding with painting, music or creative writing which is more harmful than useful. You've probably seen some code written in a James Joyce style and do not consider it a masterpiece like Ulysses.
There are a few recently languages that have gone the other way. Python (not that recent any more I suppose) goes somewhat down the line of syntax more rigid than the standard with its significant whitespace, and Go goes even farther which even formatting being part of the language. After initial suspicion about that I very much enjoyed Python and I suspect Go might be similarly satisfying although I haven't yet had the change to work with it.
July 11, 2014
June 2, 2014
A good coding interview question is not just the surface. A lot of programmers who have been interviewees but not interviewers complain about the questions. There are a large number of complaints of course but the one that I'm interested in recently is "how can my answer to this one question tell you much about my programming ability"?
A good coding interview question has several different possible approaches and does not rely on any moments of significant insight. While it's nice to find someone who can intuit the rabbit and turtle solution to list loop detection the ability to do that or not in any particular hour is not particularly indicative of programming skill. And of course with all such insight problems if someone has seen the trick before you learn very little.
A good coding interview question also has a couple of standard traps. Again, I don't mean traps you need supreme insight to get out of, but traps where the naive approach should run into them and think "huh, I need to do something more fancy". In my experience that ability is a very good indicator of a good future coworker - someone who sees the trap and rebuilds around it is much better than those who don't see the trap or those who see it and attempt to bull through it. Falling into a trap is not a red flag for me, especially for junior developers. Failing to see it once you're in it is trouble, and failing to see it once it is explained to you is a disaster.
Finally a good coding interview question is one with experience. If you can keep your question from being splattered all over the web long enough to use it on a series of applicants, you can now measure them against each other. You can learn what sort of speed to expect, which traps everyone always falls into and which ones it takes a special amount of inattention to fall into, and so on.
None of this is really apparent until you've been the interviewer a large number of times, so it's unsurprising that programmers who have only been interviewees doubt how much can be learned from a simple coding question. But like any skill in programming, you can't expect to understand it deeply without getting down and working with it.
May 28, 2014
An interesting metaphor with a little more example than is really necessary I think, but maybe that's because when he described his programming approach I instantly thought yes, that's true:
...my experience has led me to conclude that the most efficient way to program is to approach your code as if you were a dictionary compressor. Like, literally, pretend you were a really great version of PKZip, running continuously on your code, looking for ways to make it (semantically) smaller.