Sign In

Communications of the ACM

Letters to the Editor

Computer Science Is Not a Science


Letters to the Editor

Credit: iStockPhoto.com

To the question Vinton G. Cerf addressed in his President's Letter "Where Is the Science in Computer Science?" (Oct. 2012), my first answer would be that there isn't any. A true science like physics or chemistry studies some aspect of physical reality.

The full text of this article is premium content


Comments


Anonymous

Regarding Carl Hewitt's claim that the relational model is obsolete ...
Carl's comments might have been useful if he had provided even a smidgen of explanation about what his proclamations actually meant. As it is I haven't a clue.


Anonymous

I believe that the criticisms of the "relational model" are the result of a fundamental misunderstanding about the role of a relational database and the nature of the model. Databases are used to model external systems. In general this model need not be an analogical model. The database has mechanisms for collecting and storing facts about the external system and computational procedures for deriving consequences of those facts. In this sense a relational database is like a mathematical theory where data are the axioms of the theory and query operators are the inference rules. The basic operators of the relational system are those of set theory -- a very powerful theory which is expressive enough for all of mathematics. A claim that the "relational model" is inadequate for describing modern systems is tantamount to a claim that mathematics, which has proven to be adequate for describing the physical universe, is for some reason inadequate for describing modern computing systems.


Anonymous

Tedre wrote about the problems of "is computing a science" discussion: We can't define what we mean by "science" and we can't define by what we mean as "computing as a discipline".

http://dl.acm.org/citation.cfm?id=2034974


CACM Administrator

The following letter was published in the Letters to the Editor in the May 2013 CACM (http://cacm.acm.org/magazines/2013/5/163765).
--CACM Administrator

Carl Hewitt's letter to the editor "Relational Model Obsolete" (Jan. 2013) betrayed a shallow and too-common level of understanding of the relational model. Of the five specific claims he made regarding "limitations" of the model, none is valid:

Inexpressiveness. This was simply wrong. Negation and disjunction are easily in fact, almost trivially expressible. Type generalization and specialization are easily expressible, too, though, to some extent, this is more an issue for the accompanying type system than for the relational model as such.

Inconsistency non-robustness. This one was both wrong and confused. Suffice it to say that "p AND NOT p" is an inconsistency, but "Alice says p AND Bob says NOT p" is certainly not. Moreover, even if a database really does contain an inconsistency, the relational model would still function (so we are not talking about a problem with the model); rather, the problem is with the database and with the consequent fact one cannot trust the answers given by the system. Further, a query language based on logic that encourages logical contradictions is nonsense.

Information loss. Whether one's updates "lose information" is entirely up to how one uses the model; it has nothing to do with the relational model. One of us (Date) co-authored a book(1) 100% devoted to the use of the relational model to manage temporal data and thereby not "lose information." For the record, the relational model requires no "correction," no "extension," and, above all, no perversion, for this desirable aim to be realized.

Lack of provenance. This point has to do not with the model as such but with how it is used. Note "Alice says" and "Bob says" are provenance information. In fact, the relational model is ideally suited to recording such information, and even SQL DBMSs are widely used for this purpose.

Inadequate performance and modularity. Criticizing the relational model for having no concurrency abstraction is like criticizing a cat for not being a dog. (Hewitt said it is SQL that has no concurrency abstraction, but SQL and the relational model are not the same thing; indeed, SQL has little to do with the relational model.) As for "a . . . type should be an interface that does not name its implementations," and to the extent we even understand this remark, types in the relational model meet this criterion.

We would never publish a critique of (for example) Hewitt's actor model without understanding it well; why then does he feel he can publish a critique of the relational model, when he demonstrably does not understand it?

C.J. Date
Healdsburg, CA,

D. McGoveran
Deerfield Beach, FL

REFERENCE

(1) Date, C.J., Darwen, H., and Lorentzos, N.A. Temporal Data and the Relational Model. Morgan Kaufmann, San Francisco, 2003.


CACM Administrator

The following letter was published in the Letters to the Editor in the May 2013 CACM (http://cacm.acm.org/magazines/2013/5/163765).
--CACM Administrator

Unfortunately, Date and McGoveran make no good arguments against the limitations of the relational model, as outlined in my letter (Jan. 2013), partly because we are using incommensurable terminology (such as "negation," "disjunction," "concurrency," and "abstraction"); for details, see articles in Proceedings of Inconsistency Robustness 2011 (http://robust11.org), especially regarding the requirement for inconsistency robustness. My point is not to dismiss relational databases as a failure but to build on their success and overcome their limitations.

Such an effort must meet several requirements:

Compatibility. All capabilities of current relational databases must continue to be implemented; in addition, incrementally integrating inconsistent information from multiple relational databases with incompatible schemas (something awkward in the relational model) must become standard practice; and

Natural language + gestures (as lingua franca for communication with computer systems). Semantics of natural language and coordinated gestures of multiple participants must be expressible. An important consequence is expressions and gestures must be able to mutually refer to each other, something awkward in the relational model; for example, if Alice points her finger at Bob and charges, "I accuse you of harassing me," and Bob retorts, "I deny it!," then the mutual co-reference of language and gesture must be expressible.

To move beyond the relational model, I propose the actor model because it already meets these requirements, in addition to the ones I included in my earlier letter. I further propose ActorScript(1) as a more appropriate foundation than SQL for a family of languages for information integration, as it includes the following characteristics:

Security and safety. Applications cannot directly interfere with one another.

Excellent support for concurrency.
+Not restricted to just the transactional model of concurrency, as in SQL;
+Messages directly communicated without requiring indirection through channels, mailboxes, pipes, ports, or queues;
+Integration of functional, imperative, logic, and concurrent programming; and
+Low-level mechanisms (such as threads, tasks, locks, and cores) not exposed by programs.
Language extension. ActorScript has excellent meta-language capabilities for implementing extensions without interfering with existing programs.

Capabilities for extreme performance.
+No overhead imposed on implementation of actor systems; for example, message passing has essentially the same overhead as procedure calling and looping; and
+Concurrency dynamically adapted to available resources and current load.

Relational databases have been an outstanding success and become dominant in the commercial world. However, computing has changed dramatically in the decades since the relational model was developed. Consequently, the relational model and SQL have become obsolete due to the limitations I've outlined here, and innovations like the actor model and ActorScript are required to address current and future needs.

Carl Hewitt
Palo Alto, CA

REFERENCE

(1) Hewitt, C. Tutorial for ActorScript. arXiv. Cornell University, Ithaca, NY, Mar. 2013; http://arxiv.org/abs/1008.2748


Displaying all 5 comments

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.
  

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.