I enjoyed Allan's article, but couldn't help thinking that it was about something else. With the exception of the use of three code fragments, I was left with the feeling that I was reading about an article I didn't write. I looked back over my article and saw most of the relevant points analysed, rejected or otherwise expressed. Perhaps I didn't express them clearly or directly as I might have done? So, I guess these comments are also a continuation, response and counter argument!
[0] Just to clarify, the reason that example 2 is presented is because it is often shallow orthodoxy - fashion without style.
[1] "\n" is an abstraction for CR, LF and CR+LF, depending on the platform. That is a requirement of the standard, and is the same in C as it is in C++. The only thing that std::endl offers us in addition to "\n" is an explicit std::flush for all stream types. For streams of uniform data this is not a reasonable necessity. And whether "\n" requires more or less context to understand than std::endl is more a matter of opinion rather than fact!
[2] Be careful with the use of the word "reuse"... ;-)
[3] On my use of the word "minimalism", it is at once intended to be both descriptive and provocative. In use as an ordinary noun "minimalism" refers to omission of the unnecessary and the inessential. The idea of reduction to sufficiency, but not to its elimination, is implicit. Following from this is the inherent coupling to a context and style of composition. This points to the understanding of "minimalism" in terms of "minimum", a mathematical concept, and in particular the application of that to design, which is both a political and a technical act - definitely the main topic of interest.
If one relates "minimalism" to "Minimalism", this points more to the provocative side of things, making reference to art rather than design or science. "Minimalism" has the specific meaning as a term that describes visual art and music movements. It would, however, not be correct to equate what I am talking about with descriptions - and they are only descriptions, not definitions - of the Minimalist movement (fond as I am of it). Refer, yes; equate, no.
The label "Minimalism" was coined originally by critics and not by its practitioners. It therefore suffers the volatility and subjectivity that such a classification will inevitably experience. Contrast:
"The aim of Minimalism is to allow the viewer to experience the work more intensely without the distractions of composition, theme and so on."
with
"Minimalism here becomes deeply relativistic, supportive of the view that 'art' can only acquire value or worth in relation to external factors, such as its social or institutional meaning." (After Modern Art, David Hopkins)
and
"Minimalism is against the subjective realm and for the objective realm." (This is Modern Art, Matthew Collings)
Clearly a movement as much divided by critics as it was defined by them. For some there was the idea that Minimalism made the experience more intense and whole because of the removal of context, and for others there was the idea that intensity and wholeness arose precisely because the art acted as a lens through which the context could be seen.
So I would have said that although it makes for an interesting literal comparison, it is perhaps not a wholly valid conceptual one. The "minimalism" of my article is sympathetic to the "Minimalism" of art, but is more truly drawn from maths and science than art, and is deeply bound to context and purpose through design. And therefore in answer to the question raised: yes, this really is "minimalism", but it is only in part "Minimalism".
[4] In terms of Constructivism, what I am describing also falls a little short of that art movement as described by
"Constructivist art is marked by a commitment to total abstraction and a wholehearted acceptance of modernity.... Objective forms which were thought to have universal meaning were preferred over the subjective or the individual. The art is often very reductive as well, paring the artwork down to its basic elements."
To specifically relate it back to the code fragments, the use of STL is not the same as embracing modernity - although I and others frequently use the term "Modern C++" as a description of the third age of C++. We must be careful in how we apply this label: there are many different styles of code that can claim this title, and some have contradictory aims. Some might be considered elitist and others not. To lump them all together and brand them the same way is not always appropriate. Although the spectre is raised, the question of elitism is never really explored or answered in the article. It's a good question, but a deep one so I will leave it to one side as it is slightly off the main track.
Is the STL necessarily modern? Not really. It represents the adaptation and adoption of functional programming techniques into C++. Is STL radical? Yes, from the perspective of Classic C++ its introduction pushes C++ in quite a different direction to a core Modernist Object creed (interesting mix of movements here...). Some would say that the direction is not different, that it is either a course correction or a clarification. But not all that is radical is modern. It is modern in the sense that "Modern English" is modern, but not truly modern in the sense of Modernism.
I think my article also makes clear that a total - as opposed to sufficient - commitment to abstraction is not the answer. However, there are clearly common points: universal meaning and a reductive tendency ring bells. If such a comparison is to be made, Constructivism more accurately describes generative programming in C++ (see the work of Andrei Alexandrescu, and Krzysztof Czarnecki and Ulrich Eisenecker's) than it does generic programming.
[5] Interestingly, the issue of universal forms actually points to the elimination of context as a factor in Constructivism. If the forms are not universal we have context, if they are universal the distinction between having context and not becomes at best academic - " When everything is a triangulation point, then nothing is a triangulation point " (Software Requirements & Specifications, Michael Jackson). Of course, how this relates to software development is another question!
[6] It is interesting to note that Oberon fails the requirements of sufficiency and utility. Whilst it is has moments of elegance, its ability to express abstractions with appropriate compression is severely restricted. It is as if it has missed the minimum and punched its way through to the x-axis. As described either in terms of what I was exploring in my article or in terms of an art movement, Oberon is not a {m,M}inimalist tool. It increases the amount of code written and the amount of reading required to recover meaning. The idea of capturing a model of usage is missing, and is why the reduction is uninformed from a language user's perspective.
[7] A telling exercise is to attempt to describe the core of each C++ code fragment in English. The first example is quite long, the second example is longer and the third example is the shortest. I would contend that the last fragment is the one that has a structure that most closely captures the intent: " copy from the beginning to the end of items out to the standard output using newline separation ".
[8] The aim of minimalism as described in my article is not to " reduce the physical amount of code ". The reduction of code is not a principle; it is a side effect - " Vigorous writing is concise.... This requires not that the writer makes all sentences short... but that every word tell " (The Elements of Style, Strunk & White). If you reduce code for its own sake you have lost your audience. To further quote from my article, your code " needs an audience, and it will be better off for having one in mind ". So I would say that this is a point of agreement rather than one of divergence between the articles.
[9] In software, coding is still designing. There is little distinction except in level of detail and range of formality: coding is a subset of design. To make a hard and fast distinction is often artificial, and I would say the cause of much misguided thinking in software development. The sculpting of a solution is the process of design, and it makes little sense to have one recommendation for design and a contradictory one for code: if the design should be minimalist then that already covers what we should be doing in code. Of course, we have to choose the right working definition of minimalism :-)
