Journal Articles
| Browse in : |
All
> Journals
> CVu
> 275
(10)
All > Journal Columns > Editorial (221) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Editorial: Selective ignorance
Author: Martin Moene
Date: 10 November 2015 08:50:04 +00:00 or Tue, 10 November 2015 08:50:04 +00:00
Summary:
Body:
I was reading the blog of one of the lead developers of an open-source library recently, and it was interesting to note some of the remarks made about code quality and user friendliness. The user friendliness of an API is about how other developers perceive it, and of course it’s a subjective thing – to a point. Code quality is one of the factors in any attempt to improve user friendliness, so if the quality is low, it can be very hard to change in order to improve it. Nothing remarkable about that, it’s an issue experienced by lots of programmers every day, and is certainly nothing new! And that’s the problem, right there – it’s nothing new, there are loads of libraries and programs that are needlessly hard to use.
Very often the problem arises because the developers are so fixated on the underlying structure of the technology they’re exposing – be it some hardware interface with lots of registers, a security protocol, a database system or whatever – that they forget about what the user might actually want to do. How many times have you used a library that required you to invoke several functions or methods to initialize something, and pass arcane-looking parameters that had to be in the right combinations for anything to work? Of course, you can write your own wrapper to do the right thing, but ALL users of the API have to do it, and they’ll all do it slightly differently, and not be able to take advantage of the commonality.
Scott Meyers made the point about making things (he was talking about class interfaces, but it applies here) easy to use correctly, and hard or impossible to use incorrectly. This requires a little bit of thought on the part of the API developer, in making sensible defaults, preventing incorrect combinations of flags and/or parameters, naming the public API artefacts sensibly, and so on. Some programming languages help more than others in this regard, in the support they provide for abstraction. And that’s what this is really about – a higher level of abstraction. If the API doesn’t operate at a high enough abstraction, it becomes a distraction.
</rant>
Notes:
More fields may be available via dynamicdata ..