Hi Alan, Le 25 juil. 2011 à 10:08, Alan Kay a écrit :
> 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. As you mention it it looks to me the really hard problem is the design and how to push OOP to its boundaries. From this perspective, I'm not convinced that DSLs are really critical. DSLs could matter more in the lower levels. For example, a DSL such as the s-expression language described in 'PEG-based transformer provides front-, middle and back-end stages in a simple compiler' seems very convincing, at least the overall result is very impressive. I was able to understand an entire non-trivial compiler for the first time in my life :-) But the closer we get to the user the less critical they seems to be imo. So I get the impression that STEPS could be written Smalltalk or some improved dialect with a marginal impact on the code base size. Compared to a normal operating system that weights several millions loc, with an entirely rethought design but no DSLs, it might be possible to reduce the whole system to 100 000 or 50 000 loc. Then using DSLs would allow to compress the code a bit more and go down to 20 000 loc, but the real gain would come from the new design approach rather than the DSLs. imo there is a tension between DSLs and frameworks/libraries. As a framework design is refined more and more, the more the framework stands as its "own distinct language". When this point is reached where using a framework feels close to writing in a dedicated language, it's then relatively easy to add a DSL as syntactic sugar, but the expressivity or code compression gains seem then limited in most cases. If you implement the DSL earlier during the framework development, the gains can be more important, because the DSL will cover the framework design limitations, but these will probably manifest elsewhere at a later time. To take a concrete example, what looks important in OMeta is the concept but not OMeta as a DSL. For instance, Newspeak executable grammars or PetitParser appear to do almost the same than OMeta but without a dedicated DSL. So I'd be curious to know what yours take on this DSL vs framework issue. I also wonder if you have studied how big would become Nile or some other STEPs subprojects using DSLs if they were rewritten in Smalltalk… Cheers, Quentin. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
