views:

446

answers:

9

Following up on my previous question on the enduring properties of a book on algorithms, see here, now I would like to ask the community what language would you use to write the examples of such a reference book.

I will probably not use MMIX (!) to write the examples of the book, but at the same time, I think just pseudo-code would be less interesting than examples in a real language.

Still, I'd also like the book to be a resource for researchers as well. What could be the choice of the community? Why?

Answer: I knew this was a tough question and that there would be several different answers. Notice that answers cover the whole range from Assembly/MMIX(!!) to Python and pseudo-code. The votes and the arguments compel me to choose Uri's sensible answer, with one caveat: my pseudo-code will be as close to C as I possibly can (without going into platform specific issues, of course), and I will possibly discuss better implementations in side notes (As all of us know, mathematically proving the algorithm works is far, far from the problems of implementing it).

The book is on algorithms in a particular domain, not on the mathematics of algorithms in general (much smarter people have done and will do much better than me on general algorithms). As such, one thing I consider would add value to such a book is the repository of the algorithms, which I will definitely put online in a companion website (maybe in a couple of languages, if I find the time).

Thanks for all the answers. I sometimes feel I should put everybody who answers as co-authors. :)

+1  A: 

I would not use any specific language. Use a pseudo-language that will be clear to most anyone who has done a little programming. Usually these books use something close to the C style, but that is not a rule. I know that you mention that you do not want to use pseudo code, but that will allow you to reach a broader audience.

Ed Swangren
+2  A: 

I would avoid anything that abstracts the core 'mechanics' of any particular algorithm

Bedwyr Humphreys
+1  A: 

C style is often used because many languages use a very similar style so most programmers understand it without explanation. Further, examples can be run on any machine with a C compiler - which is nearly every machine.

However, higher level concepts often require the use of more recent technologies and techniques - OO, functional programming, etc.

These are often expressed in the language that has the required features. Java, C#, Erlang, Ada, etc - most good programmers will grasp what is going on with just a little explanation.

But C is very nearly a universal foundation - you really can't go wrong if you adopt a C style for examples.

Adam Davis
+13  A: 

A good book on algorithms should be written in psueod-code a-la-CLR...

In my experience, most books that go into language-specific examplse end up looking more like undergraduate textbook than like a serious reference or learning books. In addition, most languages are fairly clunky when dealing with collections (esp. C++ and Java, even with generics). Between all the details, too much is lost. You're also immediately eliminating a lot of your potential audience.

The only advantage to language specific books is that if you were writing a textbook, the publisher could attach a CD and add 50$ to the MSRP.

It's easier for me to understand an algorithm from (readable) pseudocode. If I can't figure out how to implement it in my language with my own collections, I'm in trouble anyway.

You could add to every pseudocode listing a note about implementation details for specific languages (e.g., use a TreeSet in Java for best performance, etc.)

You could also maintain a separate website for the book (good idea anyway) where you'll have actual implementations in different languages. No need to kill trees with long printouts.

Uri
disagree and hate pseudo code being used in books
cletus
Actually, I prefer pseudo code in books. Pseudo is actually pretty clear to understand if done correctly. Although, some books take route of showing both pseudo code and C or Java code.
BobbyShaftoe
Code that accompanies pseudocode should be available in electronic form, ideally via a website. Less paper waste, easier to copy-and-paste, and easier to update errata and programming conventions.
Uri
I tend to disagree, simply because psuedocode is often imprecise. I don't mind implementing an algorithm from one language to another, but with pseudocode you don't know... is x[1] the first element of the array, or the second? Because of things like that, I spend time trying to decode the pseudocode, and even then might get it wrong. Real code has to compile, so if in doubt, you can run it and check.
jkerian
+9  A: 

Use a real programming language -- never a psuedo one. Readers are very suspicious of psuedo code , readers like real programming languages. The trap with psuedo languages is that you can define code concepts that the reader cannot impliment in their language of choice

A real programming language has a number of advantages :

1) you can test your code, hopefuly proving your code correct !

2) you can export that code into a published format for insertion in your book, ensuring that anybody following your code would be looking at actual executable code.

3) you would not have to defend you psuedo code.

The choice of language is obvously subjective, but I think that almost any modern language could be used, but I'd recommend one that has 'least overheads' in terms of quick understanding. And perferably one that the reader can get a compiler/interpreter. If you'd like to use C, then perhaps you should check out D. An improved C.

For example, Ruby is of this ilk if you keep you code 'simple', Java is not ( too many support libraries required), in an earlier time Pascal would be a candidate.

BTW: I dont use Ruby now, as I currently use Smalltalk & REBOL, but I would not use either of those languages in a book. Your book would go straight to the remainder bin !

Can you provide any examples of where a data structures book might use a concept in pseudo-code that can't be implemented practically in a particular real-world language?
No, any of the real world languages you would use are Turing complete anyway (please don't worry me about some theorem proving language that is not Turing complete)
BobbyShaftoe
I have never seen [good] psuedo-code that any half-sensible developer couldn't translate into a real language. I have seen my share of code that even good developers can't translate into pseudo-code...
Uri
A: 

I would use something that lets you express exactly the idea behind the algorithm.

Haskell is quite neat, but I think that with algorithms that work with state, it can get in your way, and you would be more occupied with the language than with the algorithm.

I wouldn't use C or its descendants (C++, C#, Java ...) because they will get in your way when your algorithms are more "functional" in nature. Again, you would be more occupied with the language than with the algorithm. I would feel very uncomfortable if I had to work without higher order functions.

So, basically, I would use a multi-paradigm language that you are comfortable with, and with which you feel confident that you can express the algorithms without diving into language specifics.

My personal choice would be something like Common Lisp, but perhaps Python or Scala is workable, too.

Svante
A: 

Python's a good choice all around. It's very readable, even if you haven't programmed in it before. Plus, it's a lot less verbose than some other common language choices.

Jason Baker
+1  A: 

There is a tremendous benefit in Knuth's rendering of the algorithms in an assembly level language. It forces the reader to carefully consider exactly what is going on in the silicon when we code algorithms in some higher level language. Especially for systems programmers, this kind of understanding can't be gotten any other way.

Knuth's new MMIX is ideal: consider it an assembly level pseudo-code.

My ideal textbook would have algorithms written in pseudocode and MMIX, so that we can see the algorithm in both its pretty and gory-complex forms. Pseudo-code should be preferred to "real languages", because it sidesteps pointless "you should have used this language not that language" battles. At this stage, pseudocode needs no defending -- the best extant algorithms textbooks use either pseudocode or in Knuth's case a kind of assembly pseudocode.

Rob Lachlan
+1  A: 

The choice is not going to be able to please everyone.

Robert Sedgewick has written his "Algorithms in..." books in multiple languages. I had the C version for a course and bought the C++ version when I started working with C++ at work.

You can't escape language features (even pseudo language features).

To try to please as many people as possible you could choose two languages, say one functional and one not. It could help illustrate motivations in algorithm choice.

Leah