Lambda the Ultimate

inactiveTopic Why American Computer Science Seems Incurable
started 8/23/2002; 1:30:29 AM - last post 8/23/2002; 4:02:32 AM
jon fernquest - Why American Computer Science Seems Incurable  blueArrow
8/23/2002; 1:30:29 AM (reads: 1478, responses: 2)
Why American Computer Science Seems Incurable
Dijkstra talks about how teaching and research in American computer science suffers from industrial pressure and influence pursuing a "dream of full automation." This bad influence is reflected in an interview with a faculty candidate who:

"...did not claim that he had gained any new insights or that you could learn anything interesting from studying his thesis, and the sole justification was to be found in his final product... this software was very important because (i) there were thousands of Fortran programs 'out there', and (ii) the system was fully automatic, an absolute requirement for industrial acceptance... his gadget worked in such a small set of circumstance that its main feature became that one could apply it unthinkingly."

Dijkstra also sees the widespread idea in corporate America of technical employees being replacable like a part or a light bulb as a barrier to brilliant and innovative scientists. The essay raises the question: Should academic research be judged on how it improves teachable material or by industrial acceptance?
Posted to teaching/learning by jon fernquest on 8/23/02; 1:38:13 AM

Ehud Lamm - Re: Why American Computer Science Seems Incurable  blueArrow
8/23/2002; 2:02:43 AM (reads: 776, responses: 0)
Is this directly related to programming languages?

jon fernquest - Re: Why American Computer Science Seems Incurable  blueArrow
8/23/2002; 4:02:32 AM (reads: 791, responses: 0)
> Is this directly related to programming languages?

What he finds disagreeable in the faculty's candidate's research (on Fortran optimization) certainly is.

It is the tendency of some programming language research to hide a useful idea behind a buzzword or concept or gadget or language that prevents you from thinking anymore or allows you not to think anymore or that forces you to think only in terms of their buzzwords. An intimate relationship with some company or the DOD as well as non-disclosure agreements are a likely source of this behavior.

In any science including programming languages the problem and its solution have to repeatable, otherwise the work is unfalsifiable (Karl Popper) and not really science at all. Open sourced code or detailed specs (and test cases that show the problem being solved) allow a problem and its solution to be duplicated.

Instead of hiding the ideas in a black box that allows you to be an unthinking consumer, the ideas should be put it in a white box (or at least grey box) where as well as consuming them, the ideas can be understood, reused if need be, or extended if need be. (Dijkstra: "...his gadget worked in such a small set of circumstances..." vs. "new insights").

Dijkstra's objections to the unthinking nature of the candidate's research bears great similarity to the limitations of black box abstraction (Dijkstra: black box = "apply it unthinkingly" = "final product" = "fully automatic"):

"...the well known failures of black box abstraction in component and distributed systems. These include the loss of rationale, invisibility to the client of critical implementation efficiency issues, and the inability of the client to specialize any behaviors that cross-cut the natural component breakdown of the system." (Gregor Kiczales, Beyond the Black Box: Open Implementation", IEEE Software, January 1996).

Quoted from Toward a Unified Language Model (John Hotchkiss, Group Manager, Harlequin Inc.):

...debuggability, and most importantly reusability, will only be achieved by a combination of advances in software technology. These include better evolutionary architectural specification, run time safety and verification, and developing support for abstractions that span the component segmentation and allow more explicit control over the tradeoffs of component reuse.

It is this last area that I am most interested in: how to provide the benefits of abstraction in building dynamic applications, applications that will have to evolve over their lifetime to support new substrates and functionality, while still allowing the abstraction layers to be selectively flattened to improve performance and to give clients control over performance and the meta-interfaces of a component.

This is a sort of fish net abstraction, as opposed to black box abstraction. Information about the component or distributed object can be exposed to clients, and clients can pick and choose the level of dependency on the available internals they are willing to accept.

For me the beauty of Scheme, SICP, and EOPL is their transparency. Everything is transparent in Scheme: the ideas behind the interpreter, compiler, parser, (soft typing and lazy evaluation systems also) are all there written in Scheme for you to see, understand, and build on.

The core of the language defintion is also transparent. You can look at the s-expressions before and after macro-expansion. Partial application of functions takes place on lambda forms that you can look at before and after. PLT even has macros that allow you to trace the macros expanded back to the original source and it's all there, transparent, for you to read, understand, and build on, rather than re-invent the wheel yet one more time.... which seems to be the real story behind programming languages and their products, computer programs, to date.