Featherweight Musings

Saturday, March 10, 2012

I was wrong

about syntax - semicolons and curly braces are a good idea.

I used to prefer line breaks to delimit lines of code and indentation to delimit blocks (as in Python, but without the colons, or Haskell). I've changed my mind.

Semicolons are a good idea, because logical lines of code should not be forced to be physical lines of code. It is nice to limit physical lines of code to a certain number of characters, say 80, this is useful for doing side by side diffs, etc. But often a logical line of code will be much longer than 80 chars, especially if you are using descriptive names for functions and variables, which is usually a good idea. Thus, you need to break a logical line into several physical lines, and this means you need a delimiter - enter the semicolon. Also, frankly, it is not much effort to type a semicolon, it is so far down my list of daily worries it barely registers.

My argument for curly braces over indented blocks is much more intuitive, after working on a large-ish Python project, I simply found indented blocks (for large methods/classes) too hard to read. Braced blocks are not perfect either, and can easily be abused, but the make reading easier for me. Perhaps this is just down to habit, after all, I am much more used to reading braced code, but I did a fair amount of Python programming and reading indented code never got easier.

Bonus thing I was wrong about - you will always need style guidelines, you can't hope to always codify such things in the compiler, see combining indentation with braces. But, this is something your IDE should really be doing anyway.

Tuesday, March 06, 2012

Bad langauge features

As a programming languages researcher I put a lot of thought in to what makes a good language, or even what would make the best lanaguge. I have a lot of strong opinions about this (there is a blog post about some of the things, but of the top of my head: optional types, virtual classes, ownership types, first class funtions and an emphasis on functional style programming are a good start), but unfortunately so does everyone else, so it seems unlikely we'll ever see the best language (i.e., the one I think is the best).

The last few days I've been thinking about what would make a really bad language. I don't mean bad for a purpose, some great languages can be really bad if used for the wrong thing (think dynamically typed languages for very large projects, C for high level programming, Javascript as the assembly language of the web). But more, which language features are inherently bad choices in every (or nearly every) situation, and which features interact really badly when put together.

Goto (or it's ridiculous cousin, comefrom) must be near to the top of the list, especially when it's combined with properly scoped features like closures. There has also been some really poor syntactic choices such as sticking a dollar sign in front of variables in Basic or the extreme overloading of symbols in C++. Also Lisp.

More generally any PL behaviour that is surprising is probably a bad choice, such as Java wildcards, non-reifed generics, nearly everything about pointers, static method overloading, some operator overloading, scoping of switch statements, the behaviour of nested classes in Java. Prioritising writability over readability is also a bad idea, although this is more debatable, and not thinking of tools, such as requiring type information to parse C++.

Any nominations for truly terrible language features?