archives

Dennis Ritchie passed away

I have just learned that Dennis Ritchie (1941-2011) has passed away. His contributions changed the computing world. As everyone here knows, dmr developed C, and with Brian Kernighan co-authored K&R, a book that served many of us in school and in our professional lives and remains a classic text in the field, if only for its style and elegance. He was also one of the central figures behind UNIX. Major programming languages, notably C++ and Java, are descendants of Ritchie's work; many other programming languages in use today show traces of his influences.

Update

Bjarne Stroustrup puts the C revolution in perspective: They said it couldn’t be done, and he did it.

By Ehud Lamm at 2011-10-13 06:45 | General | History | 79 comments | other blogs | 30424 reads

machine-ported reference algorithms

The following sentence, at http://danny.sadinoff.com/hebcal/, got me thinking.

Hebcal has been successfully ported to Perl, C, and Javascript, but I'm currently only maintaining the C implementation.

How can we avoid such situations? In my opinion they are all too common.

Before I go further, let me assure you that I am not trying to open up a discussion lamenting the Tower of Babel problem or naively proposing that language X (possibly invented by me) is the one everyone should use everywhere.

But what I would like to get some input from LtU members about is, how can a reference implementation of an algorithm be machine-ported to a variety of languages? My premise is that this would be desirable for the Hebrew calendar algorithms and many other algorithms like it. Such an algorithm would have the following properties.

  • Valuable to call natively.
  • Tricky to port.
  • Expected to have maintenance, i.e. expected to have need to re-port (merge).
  • Not performance sensitive.
  • Though valuable to call natively, not important to be implemented idiomatically.

    By "valuable to have natively" I mean valuable to have inside a language instead of outside it, e.g. cases where the following are true.

  • Not good to have as a C library (e.g. host language is not C, C++, or a language in which an FFI to C is available).
  • Not good to have as a library in one of the bytecode VM ecosystems (e.g. host language is not a JVM or .NET language).
  • Not good to have as a separate process that can be talked to via some IPC mechanism like IO streams, files, or command-line arguments.
  • Not good to have as a web service. I guess a web service could be thought of as a distributed IPC mechanism but I thought it was worth calling out on its own.

    So, if an algorithm has these properties, it would be nice to have a reference implementation in some language that could be what I call "machine-ported," which could mean machine-translated or interpreted, i.e.

  • Be machine-translated to a variety of other languages.
  • Be interpreted inside a variety of other languages.

    Has anyone done this, e.g.

  • Here's my reference algorithm in (possibly-novel) language X and here are its machine-translations into languages A, B, and C.
  • Here's my reference algorithm in (possibly-novel) language X and here are interpreters for X written in languages A, B, and C.

    Note that in the interpreted strategy, the interpreter is provided along with the code instead of being expected to be present in the host language. So this is different from the a proposal of a universal extension language (e.g. Lua embedded everywhere). Such proposals are interesting, but suffer somewhat from the same problems as proposals of a universal host language (e.g. Java everywhere).

    Thoughts?

    • By bdenckla at 2011-10-13 18:30 | LtU Forum | 1 comment | other blogs | 3958 reads