Lambda the Ultimate

After considering public and private complaints and suggestions from valued members of the LtU community, and after discussion between some of the site editors, we have created a new "probationary" category of site user. A user account will be placed in this category for repeated behavior that is not consistent with LtU Etiquette. Comments by these users will be reviewed by an editor before being approved for publication on the site, and any such comments that lack constructive content, or are unnecessarily inflammatory, etc. will not be approved.

Currently, only one account has been placed in this category, and there are no current plans to add any other accounts (although new accounts making suspicious posts will be scrutinized carefully). As Ehud put it, genuine members of the community, who are sincere and care about the quality of discussion on the site, need not be concerned that their status will be changed, even if they occasionally receive an [Admin] notice. Such notices will be posted when necessary, and are intended as a gentle reminder to everyone about the kind of comments we'd prefer to avoid.

Control-Flow Integrity - Principles, Implementations, and Applications:

Current software attacks often build on exploits that subvert machine- code execution. The enforcement of a basic safety property, Control-Flow Integrity (CFI), can prevent such attacks from arbitrarily controlling program behavior. CFI enforcement is simple, and its guarantees can be established formally, even with respect to powerful adversaries. Moreover, CFI enforcement is practical: it is compatible with existing software and can be done efficiently using software rewriting in commodity systems. Finally, CFI provides a useful foundation for enforcing further security policies, as we demonstrate with efficient software implementations of a protected shadow call stack and of access control for memory regions.

A Theory of Secure Control-Flow:

Control-Flow Integrity (CFI) means that the execution of a program dynamically follows only certain paths, in accordance with a static policy. CFI can prevent attacks that, by exploiting buffer overflows and other vulnerabilities, attempt to control program behavior. This paper develops the basic theory that underlies two practical techniques for CFI enforcement, with precise formulations of hypotheses and guarantees.

Not very language oriented, I am afraid. However, this is related to PCC and TAL which were discussed here in the past.

From Yearning for a practical scheme - "I don't want to load a SRFI

I do wonder about the scalability of CL or Scheme along the number-of-coders axis. When you have 20+ programmers working on code that was originally written by a separate group of 20+ programmers... The limitations of a language like Java might actually be a benefit in these

This is an issue close to my heart, and one that I think the LtU under-discusses. First of all, a few confessions: I am a Haskell afficionado, and hate Java with a passion for the mindset that it promotes, where coders become nothing more than LoC mincers. It saddens and angers me that people are wasting time learning it, because there is nothing in Java (or C#) that is new; and old in them are botched and bungled. That said, however, I have started to appreciate them in a different capacity.

I've recently started a position with as a lead and architect, and so also manager. After floundering for a bit, I started to think like a manager (much to my regret). The business reality is that most "programmers" (and I use the term loosely) are not LtU material. They probably didn't see the symbol lambda during their university educations. Furthermore, asking them to understand the intricacies of CPS transforms and endo-hylo-cata-ana-expi-ali-docious morphims. They wouldn't be interested either. Most programmers are just Java monkeys; it arises from the fact that there are more people than can competently (by our standards) program who are willing to take the salaries that the industry offers. Doubtlessly, if they did not work in the industry, the industry as a whole would produce better work (though not more work; more on this in a minute). The wages would also be higher... which would then attract them right back. The fact is that we count competence in terms of elegance and a feeling that a piece of code will last -- a Mona Lisa of the pyramids. The customers of our industry, however, does not hold us to such high standards. They are happy to spend less time looking for their data. They are really happy when you can save them even the smallest bit of time. They will also be satisfied with a poorly written piece of shit that passes the basic mustard. This is the reality, and no amount of Mary Poppins impressions will change that.

These problems plague all fields, engineering especially. There is one main aspect in which we stand out, which is that we deal with more complexity than any other field. Other industries struggle with structure more than 20 or 30 layers deep, while we brush them off and imagine towers so tall that we can't imagine any further. We then build them, and see how we can build even taller. I estimate (also known as pulling numbers outta my ass) that we deal with 100 times more layers of structure than any other field. In a way, it can be said that software engineering is all about complexity management.

Which brings me back to Java. It, as a language, sucks. Its one redeeming feature is that it is a lowest common denominator. I could get my English majoring friend to learn it. At first glance, the language itself is poor as hell to manage complexity. Surely the fact that you need tens of files just to equal a page of Haskell already represents a huge LoC count? Not to mention readability? Yes, in my opinion. But that's also not where Java shines. Indeed, Java is less about programming and libraries and so on, and more about the processes which are built around them. Everything from the consistency of presentation of documentation to universality of training schemes that exist. These are extra-language features that have made it popular. It is also, AFAICK, the first language that was commercially pushed successfully. These things we cannot ignore.

The first lesson that I learnt doing project management, is that a project is less about the technologies, even less about the product, and almost all about the team. The people that make up the project are the project. If you are lucky that you've got a crack team of PL specialists and who are also experts in the problem domain, then you will succeed. But you're never going to get that. At best, you will get 10 Java monkey level people, and 1 who can grok the difference between structure subtyping and nominal subtyping (not in those words, however). This is where the Java processes become invaluable -- they've laid out all the correct procedures that you, as the lead, should do to get everyone to work together. You draw some UML diagrams, etc and just generally follow the road. At the end of the day, if it fails, you can simply say that as an industry, you weren't ready to take on the challenge, and be absolved of personal responsibility. Furthermore, it also helps you with planning -- how many packages, how many components, how many classes == how many man-hours == easy calculation of projected costs and timescale. These are the things that the customers care about, and it is a rare customer that cares even about "maintainance" costs, where you'd have some leeway to build in some reason to sneaky something good in. Oh, and the worst thing is that most won't even care about that -- they'll ask about risk, which forces you to justify any and all choices, especially ones perceived by the local "expert" as outliers.

On these fronts, Java stands unrivalled (except for C#, which for the moment is almost the exact same). It makes economic sense. It also makes no sense in any other way. If I get a Lisp guru to hack up some code, the resulting poetry will be unutterably beautiful, and will take another equal guru forever to read it, all the while exclaming the great use of macro transformers. It becomes a single person pursuit. There is nothing wrong in general with single person endevours, but there are times when you need to get something done quicker than one person can, and then you need more people to help.

Thus we are back at the beginning. We have unimaginable complexity, and we have people who can't comprehend it. We do need formal processes to help us. So far, the only successful industrial scale ones have been extra-language. I wonder if it would be possible to bring them into the language? In other words, to have the language incorporate a framework to help with the workflow? I've personally tried to control the complexity by using industry standard protocols to set out the edges of components and hoping that each component can be done by one person. I have a feeling that there is always going to be a gap between those who can see the system in the whole, and those who will be working the trenches; I also find it unsatisfactory. I also don't have any better ideas.

For a while, I've been awaiting a scholarly book on the topic of virtual machines. Bill Blunden's book ain't it; and the other books (until recently) which were relevant were all practical works on particular VMs, usually that of Java or the MS CLR.

Now, it appears that two textbooks on the topic are in print: One is Iain Craig's Virtual Machines (ISBN:1852339691) published by Springer; the other is Virtual Machines: Versatile Platforms for Systems and Processes by Smith and Nair, (ISBN:1558609105), published by Morgan Kaufmann.

Judging strictly from the summaries at Powell's website; the former appears to be a slightly more academic treatment of the topic; the latter looks a bit more practical-oriented. (I'm interested in both). The latter also seems highly concerned with topics like CPU emulation and OS-level virtual machines (like VMware), as opposed to VMs as a programming model/programming language runtime (like JVM or CLR). A summary is here.
I couldn't find any in-depth reviews of the Craig book online, especially from reputable reviewers.

Has anyone read either book (someone mentioned the first one in another thread), and have any recommendations, pro or con? The second book is on the shelf at Powells, so I might go check it out. The first book is on backorder.

Thanks!