Category Archives: programming

Programming languages compared

Taking part in Code Year (JavaScript) and working with SQL, I find it helps to get a few principles and differences straight, especially for a beginner like me. First off, JavaScript is Turing-complete and SQL is not (not considering extensions like PL/SQL which implements e.g. loops and variables). Moreover, JavaScript is an imperative  and SQL is a declarative programming language – in SQL I tell the program what it should do without having to tell it how to do it (here’s a nice explanation of this contrast). Basically, I focus on describing the result I want to see and leave the execution up to the inner workings of the RDBMS. As a query and data manipulation, i.e. domain-specific language, SQL requires knowledge of the data structures which are its basis.

Two more formal differences that spring to mind:

  • SQL is not case-sensitive
  • syntax is easier in SQL (no brackets and braces, which I got a bit confused about – color coding helps to clarify the blocks that need these “boundaries”)

The precision and abstraction skills gained from cataloging prove to be invaluable when tackling coding. I realize that logic as one of the paradigms of programming is creeping in more and more, so in the long run it probably won’t be possible to avoid that subject …

Interpreting MARC – article

The current issue of the Code4Lib Journal features an excellent article by Jason Thomale, “Interpreting MARC: Where’s the Bibliographic Data?”. The abstract:

The MARC data format was created early in the history of digital computers. In this article, the author entertains the notion that viewing MARC from a modern technological perspective leads to interpretive problems such as a confusion of “bibliographic data” with “catalog records.” He explores this idea through examining a specific MARC interpretation task that he undertook early in his career and then revisited nearly four years later. Revising the code that performed the task confronted him with his own misconceptions about MARC that were rooted in his worldview about what he thought “structured data” should be and helped him to place MARC in a more appropriate context.

I have to say that the project he writes about (ditigal music collection) is very complex, because music cataloging has special rules on top of the regular ones. This doesn’t change the assessment of the MARC data structure, though, which has “as much in common with a textual markup language (such as SGML or HTML) as it does with what we might consider to be ‘structured data.'”

It’s a worthwhile read for both catalogers and programmers: it illustrates the programmer’s perspective looking at and working with MARC data and it provides insights into what made MARC the way it is and into possibilities of dealing effectively with the quirks that exist.