Lambda the Ultimate

Thanks. This looks fun.

until i get to be the maintenance programmer who has to debug the thing... :-P

Ah? I guess you mean you agree with Lamport. Right?

if only i were smart enough to be as logical as he suggests. if only all the others involved were, as well.

Ok, good. I'd have been surprised if it turned out you were saying the opposite.

So the predicament is systems that are smarter than us. It seems then, as I have been thinking all along, that what we need urgently are better ways for understanding and studying systems (including systems that are up and running; in vivo SE if you will), not only better construction methods. How's that as a suggestion for the in-the-large thread?

"no obvious bugs" vs. "obviously no bugs"

and

"debugging is twice as hard as writing" so you have to write it half as smartly to avoid screwing future self

etc.

?

A classic example is UML where the motivation was to mimic engineering methods in software design.

This would make sense, if not for the fact that the first page of the UML's official first book (by Rumbaugh) states completely different goals.

Well, there is no google book preview of any title by that author, so I must resort to a decade old memory of Rumbaugh's presentation of UML goals when drawing analogies to blueprints used by mechanical engineers and trying to carry over these ideas to programming.

Software engineering always likes to pretend to be like grownup engineering disciplines. But that's just rhetoric. UML's roots are in the software world. And it shows.

getting OT, and maybe more about in the large, i'd like to ask if you think there could be a version of SE today like Grownup Engineering? something that is known but is just not used, because e.g. not enough of us know Coq yet (or whatever other magic bulletish if you get abstract enough trick we need)? i mean, i presume day to day use of real math is mostly what makes for Grownup Engineering, but i'm curious if there's something else.

I've been known to argue that SE is an incoherent goal. Put simply, one argument is that software is a medium, not a category of artifacts or products. Just as there is no "concrete engineering" for buildings made using concrete, there is never going to be a SE.

Before the flames begin,let me remind everyone that this subthread is for the most part offtopic...

Before the flames begin,let me remind everyone that this subthread is for the most part offtopic...

That's a great way to seek the last word. ;-)

The point on SE relates well to the topic of the paper you posted: Can a Systems Biologist Fix a Tamagotchi? by Cardelli.

I'm a bit curious why you assert software is a medium. Now, if you said that a programming language is a medium (or a platform), I'd probably agree. And you could point out that developing software is very much like developing a 'program language', and I'd grant that, too. But the result of all this development is some sort of service - possibly an important, reproducible, and reusable component of another product. And components of products are products.

Besides, we have 'materials engineering' and 'chemical engineering' and 'broadcast engineering' and 'electronics engineering' and 'electrical engineering' and 'traffic engineering' and 'aerospace engineering'. There is precedent for engineering disciplines named by mediums or services.

Perhaps it is 'Engineering' that has grown incoherent...

Of course the plan was to have the last word :-)

Saying that software is a medium is meant to reflect the enormous variety of systems whose only commonality is that they are (or include) "software". The claim is that this not enough to lead to a sound engineering discipline.

I expected the argument about things like "chemical engineering". Without going to the details of each case, my inclination is to agree that in many of these cases the term engineering is either incoherent, or the name simply reflects a set of related but distinct engineering disciplines. (We should keep in mind that we are interested in the disciplinary aspects of engineering, not with the word, hence "Sanitation Engineer" etc. do not count as counter-examples!)

Please, let's just focus on quality solutions to problems and having awareness of why other approaches are inferior. Leave taxonomy discussions out of it. I don't care if you call what you do computer science, pure mathematics, computational biology, or software engineering. I care that you can develop quality solutions to problems and explain why those solutions have qualities that other solutions would require an order of magnitude or more effort to achieve. I also care if you can generalize your results.

that was such a wonderful way to put it, and i want to become better able to answer that question.

I assume that by "magic bulletish" you mean some kind of UMLish software design methodology. Functional flow diagrams can (most likely) be put on a solid mathematical foundation using category theory. See these papers:

• Baez J. C., Stay M. Physics, Topology, Logic and Computation: A Rosetta Stone

• Selinger P. A survey of graphical languages for monoidal categories
• Coecke B., Paquette E. O. Categories for the practising physicist

Incidentally, John C. Baez has been discussing categorical foundations for circuit diagrams (and generalizations such as bond graphs) in the latest issues of 'This Week's Finds in Mathematical Physics'.

Ehud, what on earth does that even mean? What is a "software world"? It sounds like you are making a value judgment, based on your surrounding words.

If by "UML's roots are in the software world", you mean object technology, then absolutely. Describing systems via Characteristic functions is a really good way to model problem domains. For example, a Generalization is then guaranteed to contain all elements in a set of classes. If UML does not use either abstract data types or objects, then that would be something else altogether!

I somehow think that people who criticize visual programming somehow imagine it has a wild departure from data abstraction altogether.

As a side note, I don't really use UML drawings at work, ever. However, I think clearly in terms of objects and therefore when I design systems I can see the drawings in my head.

What is a "software world"?

I meant that Rumbaugh, Booch and Jacobson, and their respective methodologies, did not come from electrical engineering.

I hope I didn't sound rude above.

Anyway, a methodology is different from a notation.

The major problem with notation is that it can quickly be hijacked to mean different things to different people. Schlaer-Mellor, prior to UML, had their own ideas for executable visual specifications. Many people who adopted UML saw it as a standard for executable visual specifications. However, the three amigos (Rumbaugh, Booch, Jacobson) saw it as a way for "specifying, visualizing, and documents artifacts". Issues like round-trip engineering aren't even really mentioned, which is a testament to how advanced Real-time Object-Oriented Modeling's ideas were in the early 1990s (before UML even existed). The unverifiability of UML's semantics is a testament to how little focus on execution there was.

I also think that for asynchronous communication and incremental specification, you can't beat a visual notation. Directional text doesn't cut it. People find it too confusing. Especially for repairing "living systems" you describe. Karl Fant wrote a textbook on the subject of clockless and concurrent systems, and just about everybody on Slashdot who heard about the book via a front page article basically ripped it without even bothering to read it. Really, you don't NEED to read a 400 page book to understand the ideas. All you need is perspective. But most people are so habituated in their thinking that it really might take 400 pages, plus some training and experience, before they drop their existing habits and belief system.

Does Karl Fant's book actually discuss models for concurrent systems in detail? From what I could make of the /. discussion (as well as other references to Fant's work) it is mostly a strange polemic against mathematics as a foundation for computer science. This is not a good sign, to put it mildly: there is a vast and expanding literature on the best ways to understand and express concurrent processes, but the bulk of this literature obviously relies on mathematics and the theory of computation. It's true that mathematics tends to come up short in some areas, but these tend to involve pragmatics and user interaction.

Does Karl Fant's book actually discuss models for concurrent systems in detail?

Yes, but not in a deep mathematical sense e.g. such as you might see in action refinement algebra. Fant's solution is essentially monolithic in that he uses his "NULL convention logic" to provide monotonicity to all Boolean expressions; a data path and association relationships among circuits either "are-data" or "not-data". This is done to detect update even when a value doesn't change. Thus, he directly encodes behavior into the meaning function of a Boolean expression. His argument is that this allows better symbolic manipulation, akin to that of what a mathematician is used to, because it precisely defines boundaries between computational steps and does not require managing propagation delays throughout the system in order to achieve determinancy.

From what I could make of the /. discussion (as well as other references to Fant's work) it is mostly a strange polemic against mathematics as a foundation for computer science.

It definitely comes off that way, even in the book. However, his basic point is *how* you think about math as applied to process calculi is what matters, and will ultimately effect many (early) design decisions.

I am not too familiar with similar books. Milner's recent book (2009) -- I'm not done reading yet -- is good and deep in math but assumes more about the audience.

I've not read the book so I can't comment, but I always thought the purpose of UML was so companies like Rational could sell CASE tools.

Yes, indeed. I've been unhappy using UML design derivatives for ten years or so. Tools provided by the likes of Rational are clearly targeted at managers, rather than at developers/testers.

There's a possible Lambda discussion out there that addresses the interface between graphical representation and language. UML, RR, and the rest don't do that. Until they do, I will continue to swallow my pride and put this irritating nonsense on my CV.

the interface between graphical representation and language

Visual programming languages have been discussed here on LtU several times. The papers I linked above show how dataflow notation can be directly mapped to typed lambda calculus (or rather, its multiplicative fragment; trying to model bicartesian categories is a bit harder).

There may even be a way of using similar diagrams to reason about monads and monadic code (see Dan Piponi on Commutative Monads, Diagrams and Knots [video]), including stateful computation.

In addition, there are some specialized diagram types which can be useful in some contexts, such as state-transition diagrams, Petri nets and others.

Data design is also well understood, and graphical notations for it have been perfected. UML incorporates much of this work in its Structure diagrams, which seems to account for most of its practical utility. Unfortunately, the theoretical foundations of Object Oriented design are mostly unknown or undeveloped, so other parts of the UML spec lack a clear semantics and are only useful as a shared visual grammar for self-styled 'software architects'.