Yes indeed, I quite agree with David.
One of the main points in the 2012 STEPS report (when I get around to finally
finishing it and getting it out) is exactly David's -- that it is a huge design
task to pull off a good DSL -- actually it is a double design task: you first
need to come up with a great design of the domain area that is good enough to
make it worth while, and to then try to design and make a math for the
fruitful ways the domain area can be viewed.
This pays off if the domain area is very important (and often large and
complicated). In the STEPS project both Nile (factors of 100 to 1000) and OMeta
(wide spectrum flexibility and compactness) paid off really well. K-script also
has paid off well because it enabled us to get about a 5-6 reduction in the
Smalltalk code we had done the first scaffolding of the UI and Media in. Maru
is working well as the backend for Nile and is very compact, etc.
In other words, the DSLs that really pay off are actual languages with all
that implies.
But it's a little sobering to look at the many languages we did to learn about
doing this, and ones that wound up being awkward, etc. and not used in the end.
On the other hand, our main point in doing STEPS was for both learning --
answering some lunch questions we've had for years -- and also to put a lot
of effort into getting a handle on actual complexities vs complications. We
purposely picked a well-mined set of domains -- personal computing -- so we
would not have to invent fundamental concepts, but rather to take areas that
are well known in one sense, and try to see how they could be captured in a
very compact but readable form.
In other words, it's good to choose the battles to be fought and those to be
avoided -- it's hard to invent everything. This was even true at Xerox PARC
-- even though it seems as though that is what we did. However, pretty much
everything there in the computing research area had good -- but flawed --
precursors from the 60s (and from many of us who went to PARC). So the idea
there was brand new HW-SW-UI-Networking but leaning on the promising
gestures and failures of the 60s. This interesting paradox of from scratch
but don't forget worked really well.
Cheers,
Alan
From: David Barbour dmbarb...@gmail.com
To: Fundamentals of New Computing fonc@vpri.org
Sent: Tuesday, January 8, 2013 8:19 AM
Subject: Re: [fonc] deriving a POL from existing code
Take a look at the Inform 7 language (http://inform7.com/) and its modular
'rulebooks'.
Creating good rules-based languages isn't trivial, mostly because ad-hoc rules
can interfere in ways that are awkward to reason about or optimize. Temporal
logic (e.g. Dedalus, Bloom) and constraint-logic techniques are both
appropriate and effective. I think my RDP will also be effective.
Creating a good POL can be difficult. (cf.
http://lambda-the-ultimate.org/node/4653)
On Tue, Jan 8, 2013 at 7:33 AM, John Carlson yottz...@gmail.com wrote:
Has anyone ever attempted to automatically add meaning, semantics, longer
variable names, loops, and comments automatically to code? Just how good are
the beautifiers out there, and can we do better?
No, I'm not asking anyone to break a license agreement. Ideally, I would
want this to work on code written by a human being--me.
Yes, I realize that literate programming is the way to go. I just have never
explored other options before, and would like to know about the literature.
Say I am trying to derive language for requirements and use cases based on
existing source code.
I believe this may be beyond current reverse engineering techniques which
stop at the UML models. I don't want models, I want text, perhaps written in
a Problem Oriented Language (POL).
That is, how does one derive a good POL from existing code? Is this the same
as writing a scripting language on top of a library?
What approaches have been tried?
Here's the POL I want. I want a POL to describe game rules at the same order
of magnitude as English. I am not speaking of animation or resources--just
rules and constraints. Does the Object Constraint Language suffice for this?
Thanks,
John
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
--
bringing s-words to a pen fight
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
