It is true that the ideas presented are very intuitive and not streamlined yet.
My proposal is: Avoid a great deal of complexity in computer systems by eliminating as many issues related to presentation and representation mismatch as possible. The most important ingredients for this are: 1) Present data in a generic way that corresponds to the structure of the data. 2) Use this genericity to eliminate a lot of UI programming tedium. For example, the tree-editing functionality is implemented only once and it is part of the system. 3) Get rid of established but unnatural ways of manipulating data. Most importantly, get rid of flat text and find neat graphical representations for the most common structures. If I were to pick two, I would pick a table view and a rooted ordered-edge digraph view. A specific way to achieve this would be something like that: Implement an editor which allows me to manipulate a rooted directed ordered-egde graph, each node of which carries an arbitrary transparent binary blob or an opaque function. Augment it with a dynamic compiler that accepts programs represented as such graphs. The language should be efficient and easy to dynamically compile -- sort of a graph based assembler. The resulting compiled function would operate on the graph structures, too. Finally make the editor extensible from within using the programs constructed using the editor itself. At this point, run the editor and start building the system by creating programs represented as graphs, use them to extend the editor to make further interactions with the system easier, implement higher-level languages represented as graphs etc. At a certain point in this process, the graph of binary blobs will not be worked with directly anymore. The categorical quantum mechanics was just one of the examples to show that rich notation is useful. Yes, there are a lot of isolated programs that implement a rich environment for a specific domain. The point is, much of the rich editing/viewing stuff is identical across such isolated programs, so it would be great if it were just part of the operating system graphical shell. On Sat, Jul 20, 2013 at 2:07 AM, Noon Silk <[email protected]> wrote: > My feedback is that you've made some comments, but not provided a concrete > example of something to give proper feedback on. > > Exactly what is your proposal? The categorial quantum mechanics > programming is somewhat implemented in Quantomatic - > https://sites.google.com/site/quantomatic/ - (which you are probably > aware of, but you didn't mention it explicitly in your post.) > > I like Quantomatic. But in some sense it's still pretty similar to > isolated programs; and it's hard to compare it to a general purpose > programming language ... > > > > On Sat, Jul 20, 2013 at 9:37 AM, Pavel Bažant <[email protected]> wrote: > >> Dear list members, >> >> I am new to this list, so I will quickly introduce myself and then >> present my bloat reduction ideas. I am currently a PhD >> >> student in the area of quantum computers at Czech Technical University. I >> started programming when I was 10 years old and enjoyed it greatly. Today I >> am programming semi-professionally to support myself financially and >> absolutely hate it. The company I work for is full of very kind and >> cooperative people, and I enjoy figuring out concepts and designing things, >> but... I absolutely hate real-world computer systems. What follows is a >> description of a system I would like to work with, if it existed, in its >> pure form. A real system would violate these rules on the boundaries with >> older systems, but not internally. >> >> A system contains some data in its memory. Part of this data may be >> programs applicable to other data. I want to be able to efficiently view >> and manipulate the data. 90 % of data has structure that falls into one or >> more general categories: >> >> general multigraph, >> digraph, >> regular graph, >> bipartite graph, >> complete graph, >> directed acyclic graph, >> planar graph, >> linear graph, >> cycle graph, >> tree graph, >> forest graph, >> connected graph, >> general nD array, >> square matrix, >> unordered set, >> ordered set, >> + a few others. >> >> >> A node of the graph can of course itself represent another graph. I want >> to see these structures and manipulate them in ways that directly >> correspond to the categories into which they belong. For example, I want to >> be able to manipulate, navigate, search, etc. all trees in a unified >> fashion using the same point and click commands. Deleting a subdirectory >> will be done the same way as deleting a paragraph in a document. The UI >> will not be restricted to editing graphs and tables (you can still use a >> painting application), but I want to be able to manipulate a pixmap as a >> general table, because it falls into that category. I want to "eradicate" >> working with data in an unnatural/inappropriate representations. The most >> prominent example of such stupid representation is flat text. I want to >> make flat text unnecessary at all levels. Programs=ASTs, not their >> linearized encodings. Path is a list of tree node names. No parsing of >> anything ever. No character escaping ever. No absurd tabs vs. spaces wars. >> Little need for regexpes. The eradication of flat text wherever possible is >> central to my approach. >> My goal is to find and bootstrap a ridiculously simple structure >> manipulation-based core system that can be grown *from within* to a fully >> featured system -- after bootstrapping, all programming will be done by >> direct tree and graph manipulations. >> Note: An important influence in this respect is Lyx - the document >> editor. Lyx is a structure editor, even though the authors do not have this >> viewpoint. In Lyx, one directly manipulates the structure. It uses Latex to >> render its output, but this is not essential. You can create and edit >> macros that essentially extend the editor with new allowed elements in the >> structure. The Lyx macro definitions are edited in a structured way, too. >> No encoding of structure in text at all. No syntax checking -- it is not >> possible to create a syntax error. >> Another influence is mathematical and engineering notation. >> Mathemeticians invented a rich notation to visually represent math concepts >> and structures. For example, Penrose notation and the notation of >> categorical quantum mechanics. Architects have rich notation for buildings. >> Electrical engineers have rich notation for circuits. Musicians have their >> special notation. It is just the programmers (well, perhaps not all of >> them) who seem to think that representing complex programs as equally >> spaced rows of fixed width characters from some limited charset is >> comfortable and efficient. >> >> Any feedback appreciated. >> >> Pavel Bazant >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> > > > -- > Noon Silk > > Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/ > > "Every morning when I wake up, I experience an exquisite joy — the joy > of being this signature." > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
