No doubt profitable nonsense. What follows is a reply to a comment by one Andrew Webb on an InfoQ.com sales-pitch-as-technical-"journalism" puff piece. The piece was "reporting" on a study by Dr Donnie Berkholz of InfoQ.com. This kind of hucksterism is one of the most formidable barriers blocking our craft of software development from ever becoming a professional engineering discipline but, well, read on if you will.
Why here rather than on InfoQ? Simple: even though their reply-entry form states that <a> is an accepted HTML element in comments, it refused to accept any of the links I had in this post. Shoddy "journalism", neet shoddy Web development.
Worse than nonsense; this was written for PHBs, likely as a tool to sell consulting hours training teams in the "more expressive" languages. Anybody who remembers Java's transition from a language and VM into a marketing platform, circa 1997-1998, has seen this done before and better.
Note that I am not talking about Dr Berkholz' original study, the link to which was buried in this puff piece. But there appears to be a real problem with the data that the study was based on from Ohloh. From what I've been able to see, the data covers a period of at least 15 years (late 1990s-present). Subversion(!) was used for 53 percent of the projects in the data set; when you add in now-Palaeolithic CVS, the share rises to nearly 2/3 of the projects covered by the data set.
Let me beat that timeframe to death one more time: In the last 20 years, we've gone through at least two major revolutions in the techniques mainstream developers use. Twenty years ago, if you mentioned "OOP" in half the corporate development centres in North America or Asia, the response would have been "what's wrong?" We as a craft, we were just beginning to get our minds wrapped around object-oriented software development, moving it out of its metaphorical Bronze Age, when the larger revolution which that enabled, BDD/TDD/whatever your flavour of Agile, hit like a silver tsunami. Twenty years ago, I was writing "C/C++", Fortran and Ada code, using various odd bits of version control (anybody else remember how good SourceSafe was before Microsoft bought it?), and checking in massive commits, because centralised SCM systems like SourceSafe, CVS and RCS are a pain; seen less as a design/team-support tool than an insurance policy against Raj's hard drive being wiped by some virus or other. Network connectivity was not as omnipresent, reliable or fast as it is today, by several orders of magnitude.
Nowadays, regardless of what language you're in, you're (hopefully) using some form of agile process. You're strongly encouraged to tunnel in, specifying the smallest change that could possibly fail, and then implement just enough code to make that spec pass. You're not going to check in thousands (or even hundreds) of lines of code at one go; you're going to build that feature you're working on over several commits, on a branch of your SCM tree, and then merge it back into the mainline when it's done. The last ten PHP projects I worked on, over a six-year period, averaged less than 50 lines per commit – in one of the most overly verbose languages since ALGOL 68 and COBOL.
Changes in development practices, and tools, will hopelessly skew that data set unless additional controls are applied, and I could find no description of any. That, to me, says that this is, at best, an enjoyable-in-the-moment bit of data-mining with all the relevance to day-to-day developers' lives of the Magic 8-Ball.
This article was even worse; no examination of assumptions, no discussion of changing trends in the craft and industry, just a vacuous puff piece. An insult to the intelligence of the readers and, despite the possible flaws in the original study, to Dr Berkholz' work as well. If my mind could go take a hot shower to wash the oily residue off, it would. I used to think ZDNet was the bottom of the barrel for this sort of thing. I was wrong.
NOTE: Earlier, I'd previously written "Twenty years ago, I was writing "C/C++", Fortran and Ada code, using Subversion", which is an anachronism, of course. Subversion came out in 2000, and I was not in a time warp in 1994. It just feels like I'd been using (used by?) it for that long.
4 comments:
I'm not sure I'd call ALGOL 68 an "overly verbose language".
As an example of styles here is code to calculate days in month on a particular year. Algol68 can do this in either of Algol68's two complimentary ways: in brief & bold.
Choice clause example with brief symbols:
proc days in month = (int year, month)int:
␣␣(month|
␣␣␣␣31,
␣␣␣␣( year÷×4=0 ∧ year÷×100≠0 ∨ year÷×400=0 | 29 | 28 ),
␣␣␣␣31,30,31,30,31,31,30,31,30,31
␣␣);
Choice clause example with bold symbols:
proc days in month = (int year, month)int:
begin
␣␣case month in
␣␣␣␣31,
␣␣␣␣if year mod 4 eq 0 and year mod 100 ne 0 or year mod 400 eq 0 then 29 else 28 fi,
␣␣␣␣31,30,31,30,31,31,30,31,30,31
␣␣esac
end;
It really comes down to the coder discretion, appropriateness and clarity, e.g. the can also be written:
Choice clause example mixing bold & brief symbols:
proc days in month = (int year, month)int:
case month in
¢Jan¢ 31,
¢Feb¢ ( year mod 4 = 0 and year mod 100 ≠ 0 or year mod 400 = 0 | 29 | 28 ),
¢Mar¢ 31,30,31,30,31,31,30,31,30,31 ¢ to Dec. ¢
esac;
Sometimes a 1-character variable is appropriate, other times "spelling it out" is required.
OT: Your Algol68 coding experience is kind of rare in Singapore. Are you ex-British military?
Neville,
Thanks for the comments. No, I'm not even a Brit; I'm American, and the first half of my career (up to 1994 or so) involved numerous stints where I was operating, maintaining and/or developing for systems that were as old or older than I was. Burroughs B6800 and B7800, IBM 704 and 1401, DEC PDP-8 come to mind. I'm sure there were others (a CDC something-or-other has large, flashing "don't come here!" messages around that memory). I found a couple of months ago that I could still read punched paper tape. One of the "benefits" of moving out of the States a decade or so ago was getting rid of half a ton of old printouts, punch cards, tapes and so on that I'd been unreasonably carting around the country with me.
Some things will scar you for life.
A blog post is over-reacting. The chart presented had 5 different Lisp variants on the scale, positioned approximately equal distance apart from the extreme left to to right of the chart. If the study results are nonsense, why quibble over the methods?
re: " No, I'm not even a Brit; I'm American"
LOL... I spotted that after I posted... but that still it does not disqualify you from being an algol coder. The Air Traffic Control system in the US was Algol58 until 2 very recently. As too NORAD air defense & control system.
http://www.ddci.com/displayNews.php?fn=news_Industry_First_Quick-Turn_Low-Cost_JOVIAL-to-C_Conversion_Service_release.php
Qinetiq is still entrenched in many US bases supporting coldwar Algol 58/60/68 code on applications no-one is allowed to talk about. Your B6800 and B7800 background makes you a prime candidate. BTW I am told that CDC created the BEST Algol68 compiler. Sadly all traces of it have vanished.
Post a Comment