Hi Benoît I don't know of an another attempt to build a whole system with wide properties in DSLs. But it wouldn't surprise me if there were some others around. It requires more design effort, and the tools to make languages need to be effective and as easy as possible, but the payoffs are worth it. I was asked this question after the HPI talk: what about the "Tower of Babel" from using DSLs -- isn't there a learning curve problem?
My answer was: yes there is, but if you can get factors of 100s to 1000s of decrease in size and increase in clarity, the tradeoff will be more like "you have to learn 7 languages, but then there are only a few hundred pages of code in the whole system -- vs -- you only have to learn one language but the system is 4 million pages of code, so you will never come close to understanding it". (Hint: try to avoid poor language designs -- like perl etc. -- for your DSLs ...) This is kind of a "mathematics is a plural" situation that we already have. Maths are made up as DSLs to efficiently represent and allow thinking about many different kinds of domains. One of the things one learns while learning math is how to learn new representations. This used to be the case 50 years ago when most programming was done in machine code. When I was a journeyman programmer at that time, I had to learn 10 or 12 different instruction sets and macro-assembler systems for the many different computers I had to program in the Air Force and then at NCAR. We also had to learn a variety of mid-level languages such as Fortran, COBOL, RPG, etc. This was thought of as no big deal back then, it was just part of the process. 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. Cheers, Alan ________________________________ From: Benoît Fleury <[email protected]> To: Fundamentals of New Computing <[email protected]> Sent: Sun, July 24, 2011 11:45:10 AM Subject: Re: [fonc] HotDraw's Tool State Machine Editor Hi Dr Kay, thank you for the pointer to Newman's work I was not aware of. Regarding the state machine, Engelbart already pointed out that it was not a good model for user control language in [1]. "In the first attempt, the control language was described as a finite state machine, and the language allowed a formal textual definition of such a machine. [...] It was originally thought that such an approach was adequate for the definition of user-system control languages. But, to paraphrase John McCarthy, the model is metaphysically adequate, but epistemologically inadequate. Implementation revealed that the dialogue is a non-Markovian (nonstochastic, historically dependent) process on the part of both the machine and the user, and accurate characterization as a finite state machine results in so many states that the model is useless. A better model is a two-stack automaton with a small number of immediate-access storage registers." I didn't encounter a lot of systems like NLS/AUGMENT during my time at a french engineer school. I guess the situation is similar to US universities. I'm trying now to catch up and was wondering if there are other software systems built using the same principles and techniques (collection of domain specific languages). I, of course, know already about Franck and the STEPS project. Thank you again for the pointers. - Benoit [1] Development of a multidisplay, time-shared computer facility and computer-augmented management-system research (Final Report), http://bitsavers.org/pdf/sri/arc/Development_of_a_Multidisplay_Time-Shared_Computer_Facility_Apr68.pdf On Sat, Jul 23, 2011 at 11:39 PM, Alan Kay <[email protected]> wrote: > The idea of using a grammar to create a user interface goes back at least as > far as Engelbart's AHI group. They used a distant past cousin of OMeta > (called Tree Meta) to do this. Ca. 1966. > > One of the first systems to specify and make graphical grammars (and UIs) > via user interactions was William Newman's "The Reaction Handler" PhD thesis > about the same time. (William is the Newman of "Newman and Sproull"). > > It's worthwhile to contemplate that a state machine (recursive or not) is > the opposite of "modeless" -- it is the epitome of modes. So this is not a > great way to specify a really nice modeless interface (because you have to > draw arrows outward from pretty much every state to pretty much every other > state). "Modeless" at PARC meant "you don't have to explicitly back out of > your current 'mode' to initiate any other command". > > Cheers, > > Alan > > ________________________________ > From: Benoît Fleury <[email protected]> > To: Fundamentals of New Computing <[email protected]> > Sent: Sat, July 23, 2011 11:05:49 PM > Subject: [fonc] HotDraw's Tool State Machine Editor > > Hi, > > I found HotDraw's tool state machine editor [1] very interesting as a > graphical editor for a "syntax-directed translator". The state machine > transforms a stream of mouse events into a stream of commands on the > structured drawing. Did I push the analogy too far? > > I was wondering if anyone knows similar examples of graphical editor > for grammars? > > Moreover, we didn't find (yet) a good metaphor for writing programs in > general purpose programming language in a graphical editor. Do you > think that might change with "domain specific languages"? > > Thank you to everyone on this list for the very interesting > discussions and links. > > - Benoit > > [1] http://st-www.cs.illinois.edu/users/brant/HotDraw/Conversion.html> > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
