Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Read-Only and Write-Only computer languages

Read-Only and Write-Only computer languages

Rate This
  • Comments 17

A colleague and I were chatting the other day and we were talking about STL implementations (in the context of a broader discussion about template meta-programming and how difficult it is).

 

During our discussion, I described the STL implementation as “read-only” and he instantly knew what I was talking about.  As we dug in further, I realized that for many languages, you can characterize computer languages as read-only and write-only[1]

Of course there’s a huge amount of variation here – it’s always possible to write incomprehensible code, but there are languages that just lend themselves to being read-only or write-only.

A “read-only” language is a language that anyone can understand when reading it, but you wouldn’t even begin to be able to know how to write (or modify) code in that language.  Languages that are read-only tend to have very subtle syntax – it looks like something familiar, but there are magic special characters that change the meaning of the code.  As I mentioned above, template meta-programming can be thought of as read-only, if you’ve ever worked with COBOL code, it also could be considered to be read-only.

A “write-only” language is a language where only the author of the code understands what it does.  Languages can be write-only because of their obscure syntax, they can be write-only because of their flexibility.   The canonical example of the first type of write-only language is Teco (which was once described to me as “the only computer language whose syntax is indistinguishable from line noise”[2]).  But there are other languages that are also write-only.   For instance JavaScript and Perl are often considered to be write-only – the code written is often indecipherable to a knowledgeable viewer (but is almost always totally understandable to the author of the code).  It’s possible to write legible JS and Perl, but all too often, the code is impenetrable to the casual observer.

 

Of course anyone for someone who’s very familiar with a particular language, the code written in that language is often understandable – back when I was coding in Teco on a daily basis (and there was a time when I spent weeks working on Emacs (the original Emacs written by RMS, not the replacement written by Jim Gosling) extensions), I could easily read Teco code.  But that’s only when you spend all your time living and breathing the code.

 

 

 

 

[1] I can’t take credit for the term “read-only”, I first heard the term from Miguel de Icaza at the //Build/ conference a couple of weeks ago.

[2] “line noise” – that’s the random characters that are inserted into the character stream received by an acoustic modem – these beasts no longer exists in todays broadband world, but back in the day, line noise was a real problem.

  • I always felt that APL was the archetypal "write-only" programming language - and at times (given its horrific syntax) was also "write-never" - the days when you needed a keyboard overlay and a special editor to write in APL will not be missed. For the uninitiated - every variable is a matrix (a multi-dimensional array). Even scalar values are interpreted as the 1 x 1 matrix { x }. I shudder to recall it.

  • I always felt that APL was the archetypal "write-only" programming language - and at times (given its horrific syntax) was also "write-never" - the days when you needed a keyboard overlay and a special editor to write in APL will not be missed. For the uninitiated - every variable is a matrix (a multi-dimensional array). Even scalar values are interpreted as the 1 x 1 matrix { x }. I shudder to recall it.

  • Nice line of thought Larry, never really thought about computer languages in this way. I always got really mad when I have to read and understand (and implement in C++) perl code because of its regular expressions shrinking 10 lines in to  one line of code. So I can relate my self to Perl being "write only"!

  • @David: The interesting thing about APL is that it wasn't designed as a computer programming language - it's a language that started as a blackboard notation (seriously).  That's why there are all those funny symbols in the language.

  • @David: In MatLab, scalars are also a special case of a matrix. I don't think you can blame APL's severe unfriendliness on that characteristic.

  • @David I agree with Ben Voigt I've used MatLab (octave does the same) a bit and that never struck me as especially odd, actually why invent a special case if you can get by just fine without it?

    About Perl: In my experience most code starts pretty readable (for perl that is), but as soon as the author has a working version, it's just too easy to succumb to "Well I could rewrite this much more elegantly" - now I do that quite a lot myself (and I don't think that's bad per se), but perl lends itself to ending up with a handful of one liners which nobody really understands without knowing the original version.

  • STL clients may be read-only, but the STL implementation is write-only. (You try reading it without your head exploding!)

  • @Raymond Chen - MSFT:

    For that there is nice series of Channel 9 lectures:

    First episode channel9.msdn.com/.../C9-Lectures-Stephan-T-Lavavej-Advanced-STL-1-of-n

    Enjoy... :D

  • I'm curious: what do you MSFT guys (Larry and Raymond) use in your C++ code for containers? No std::vector? No std::map? I agree that STL implementation is hard to read (I consider it kind of a "black-box"), but what's wrong in *using* STL containers? (...apart from the stl_and_boost_naming_style ;)

    Thanks.

  • I'm curious: what do you MSFT guys (Larry and Raymond) use in your C++ code for containers? No std::vector? No std::map? I agree that STL implementation is hard to read (I consider it kind of a "black-box"), but what's wrong in *using* STL containers? (...apart from the stl_and_boost_naming_style ;)

    Thanks.

  • I'm curious: what do you MSFT guys (Larry and Raymond) use in your C++ code for containers? No std::vector? No std::map? I agree that STL implementation is hard to read (I consider it kind of a "black-box"), but what's wrong in *using* STL containers? (...apart from the stl_and_boost_naming_style ;)

    Thanks.

  • @POKE: I use STL when I'm writing code that can handle exception throwing behavior.  But most of the time I'm not writing code that can allow exceptions, so I use a non throwing collection class.

  • Thanks Larry. Is this non-throwing collection class library publicly available, or is it some code you wrote internally? I'm very prudent in using C++ exceptions, and I'd very much like a template collection class library that does not use exceptions. With STL, Boost and template metaprogramming C++ has taken a direction of growing complexity; I'm not sure this is a good thing...

  • @POKE: It's something that a co-worker of mine wrote several years ago, I've carried it forward on projcts where I needed it.  There isn't anything standardized that I know of.

  • I always viewed APL as being both the best calculator and the worst programming language ever invented.

Page 1 of 2 (17 items) 12