On Mon, Jul 25, 2011 at 4:08 AM, Alan Kay <[email protected]> wrote:
> So when people started talking in the 60s about "POL"s in research (Problem > Oriented Languages -- what are called DSLs today) this seemed like a very > good idea to most people (provided that you could get them to be efficient > enough). This led partly to Ted Steele's idea of an "UNCOL" (Universal > Computer Oriented Language) which was a relatively low-level target for > higher level languages whose back-end could be optimized just once for each > cpu. Historically, C wound up filling this role about 10 years later for > people who wanted a universal target with an optimizer attached. > > Overall, I would say that the biggest difficulties -- in general -- are > still the result of not knowing how to design each and every level of > software well enough. > Yet, it is well known that source-to-source compilation techniques are not really good for optimization, as documented in Kennedy and Allen's text on dependence-based graph optimizing compilers. They summarize their huge mistakes in source-to-source experiments by noting the semantic information thrown away from stage-to-stage, such as structural information, could be kept and re-used to implement optimizations like explicit vectorization. [1] Such an obvious idea as the importance of preserving structural information for each compiler pass has been downplayed by "worse is better" software and monolithic compilers like gcc. We repeat history with C-as-UNCOL by promoting "JavaScript as Web assembly". Most JavaScript VMs have to dynamically determine invariants for JavaScript code as it executes, JITing some code and un-JITing it when the invariant breaks. What I am trying to say is that the difference between C and UNCOL is that UNCOL was itself a tool for defining POLs/DSLs/whatever-you-want-to-call-it. C and JavaScript are just 2 examples. F#, C# and VB.NET running on the so-called "Common Language Runtime" demonstrates another, and the joke inside Microsoft is that the CLR has become "the C# runtime", since the CLR engine team optimizes code that would be difficult for C# specifically to generate, and so functional programming compiler techniques like closure conversion currently have very poor support on the CLR. Beyond UNCOL, there are very few noteworthy thoughts on pluggable compiler architecture up until a few years ago (CoSy is one exception I found [2]). Later, LLVM came as a replacement to C, but it is probably not as general as it could be, even though many are happy with the LLVM IR and want LLVM's IR to be "the last IR you'll ever need". I think this perspective augments your own, since I don't see value in distinguishing JavaScript with "low level" languages that could perform "faster". It is not low level languages that you need; it is higher and higher level languages that better describe the semantics of your problem domain, and a clean mapping to hardware abstractions -- this is Ivan Sutherland's key software architecture contribution, Alan. He wrote a paper that many have nicknamed "The Great Wheel of Reincarnation" to describe this phenomenon he saw in computer graphics hardware architecture in the '60s and '70s, where designs would evolve from "specific" to "General". [3] For some reason, in other areas of computer science, the wheel does not reincarnate as quickly as graphics hardware and graphics languages. The final challenge is preventing things like Denial of Service by rogue remote code hogging a graphics card or whatever. While you mention 2.5 D windowing, most people have a practical wish for 3 D abstractions, and 99% of the chip space on GPUs these days is devoted to 3D, and chip space for 2D primitives have shrunk expontentially in the last 15 years. Thoughts? [1] For those who don't know much about vectorization, it is why MATLAB is a fairly efficient language for its problem domain, despite being an interpreted language. [2] http://www.ace.nl/compiler/cosy.html [3] http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
