today's lunchtime reading: Colin Garvey's history of the Fifth Generation Computing Project, in which Japanese researchers tried to build a national computing infrastructure based on logic programming, and of the Western responses to it
the American project, of course, has to be competitive and militaristic. there's a lot more good stuff in there about the different forces shaping R&D in postwar USA and Japan
i think next up in this vein will be The Sciences of the Artificial, which is quoted: "solving a problem simply means representing it so as to make the solution transparent". coooool
saw @mengwong refer to @orgoodenough and Flood's contract DFA paper in a presentation about the (very cool) work happening on L4, and I ended up re-encoding that DFA as a Harel chart
statecharts (or Harel charts) promise to solve this kind of problem, and I had never tried to make one before, so I made this one. the contract that takes 45 transitions to express as a DFA takes only 28 as a statechart. neat tool
of course, state explosion is not the only problem with DFAs for this purpose, but statecharts have some cool visual ideas that I'm going to try to remember
ALT A screenshot from Stack Overflow. The answer reads, "For an uglier version of unshift use splice:" and provides a code example. The first comment reads, "why would you do that?"
ALT The DataLex project developed a predicate calculus inferencing system (allowing multiple
instances of variables) which also included a quasi-‐natural language knowledge
representation (Aide). It was a successful approach in that it increased the isomorphism of the
knowledge representation, as well as being logically more powerful. However, it also
increased the complexity of the dialogues with the user necessary to obtain results from the
system, often in ways that could not be easily understood by the user. It was also not as easy
for developers to understand what inferencing steps would be taken when an application ran,
because (for example) a natural language representation of a section of an Act might be split
by the parser of the knowledge-‐base into two or more rules (in Horn clause form). In this
sense, the knowledge representation could be regarded as ‘deceptively simple’.
ALT In the original article, the meaning of homoiconicity seems to be spelled out quite clearly. The article opens by stating that the TRAC language is homoiconic, although without yet using that term explicitly:
The external and internal forms of the TRAC language are the same.
Before introducing the term itself, the importance of a single representation for viewing and manipulation by the user and interpretation by the computer is repeated no less than 5 times
ALT Having read through your blog article, I would say that I essentially agree with your argument. In my view, the root “icon” refers specifically to the concrete appearance of something. For example, “WYSIWYG” in the context of text editing is arguably the same idea as “homoiconic” in the context of programming languages, contrasted to languages like TeX where the document has two very different appearances (the TeX input file and the output document). WYSIWYG editors are homo-iconic not simply in the characters of the document, but also in their formatting (font, spacing, …); but I think the same concept applies.
ALT for a well-encapsulated machine, we cannot observe its inner workings by definition; in that view, making any statement about the internal representation of the machine is meaningless. More generally, the original definition has the problem that the idea that there is a single external and a single internal representation of the program does not match with reality. In fact, there is a whole chain of representations, including electrons in the brain of the programmer, photons emitted from the screen, program text, machine code, and electrons moving in the CPU.