Lambda the Ultimate

The server hosting LtU crashed on Thursday evening. I took this as an opportunity to migrate LtU over to a server running much newer versions of Linux, Apache, PHP, MySQL etc., which takes care of a major aspect of the long-planned upgrade to the latest version of Drupal. For the moment, we're still running the same version of Drupal, since that upgrade requires some software customizations, which are still in progress.

If you notice any problems with the site which didn't exist before, please post a message here.

CODeDOC 2002 was a collection of 'software art' projects. One work, W. Bradford Paley's CodeProfiles.java [requires Java support in browser], is particularly interesting because it shows three different ways in which code is "read". The first, and simplest, is a linear scan through the source (the amber highlighting). Second is the sequence in which code was written (white). Third is the execution flow as the program executes.

It's striking how unrelated these three sequences are. Since temporal sequencing lies at the heart of programming, this struck me as worrying. But then, how should they be related? How should the program's structure and creation be related to its temporal flow? And, of course, how does this relate to the language chosen?

For example: if the code were purely declarative then why would there be any correlation between execution and layout? Is my intuition about the importance of any simple relationship between these flows misguided?

Anyway, it is certainly pretty.

First off, thanks for the most excellent blog on Programming Languages.

Can we add a section on Books (along the same level as Courses, Research Papers etc.), which would be immensely helpful. I see references and links to CTM, POPL etc. in various articles, comments, but collecting them in a single place would be good.

Best Regards,
-senthil

Does Abstraction add Fuzziness to software?

I observed that Asbtraction though it helps in better communication of ideas will actually add fuzziness to the program understanding when we actually have to write some code that actually works.

(The context of abstractions here is that they are in a domain , as in a financial software or some product etc.. and consider OOP and consider systems in the wild)

The reason why i feel that it adds fuzziness is that it does not immedietly allow me to write some code after understanding the abstractions.Even in a well designed system, I know what objects i should invoke, but it does not exactly tell me what should be done.It will be ok if the abstraction uses a standard design pattern, which usually is not the case.

I have found that for objects which map realworld entities, these abstractions will be easy to understand. But when these abstractions involve process information , the control flow becomes very fuzzy.I cannot figure out the exact control flow of the code from a Java source code . Some people may find this statement pretty stupid , but i think that they have trained their minds to look at things that way, but the fuzziness still remains .

For example, the processing of a transaction might involve creating lots of objects. These objects each perform a specific operation on the given transaction. This code base is was written by many teams and each team has its own way of looking at it.For example some object computes risk of that transaction, for that it needs to be instantiated with other objects whose values we should know before.For other team for the process of printing a report, a type of report might be the basic abstraction in his world.So thats additional mapping. Also once i also came across an asbtraction that was made to make it easy to test code, which is common IMHO.

Now in a large team of say 500 memebers, how do we expect people to get in proper abstractions. Refactoring the code may not be an option because there is a lot of code that runs using these abstractions. Also, the above code is a very stripped down version and for each task we need to be aware of many special cases which usually cannot be abstracted or abstraction may not make much sense or was an overkill.

The problem is only aggravated in a badly designed system as it does not follow known patterns or ways of doing things. The reason why i see bad designs at my work place is not because people are bad, but because there might be a change in the requirement which was assumed would not change, but it did change during the final stages of the testing or the system was extended beyond what it was intended to do.

Please leave your comments, opinions or flames on this issue.