On 2/29/2012 5:34 AM, Alan Kay wrote:
With regard to your last point -- making POLs -- I don't think we are
there yet. It is most definitely a lot easier to make really powerful
POLs fairly quickly than it used to be, but we still don't have a
nice methodology and tools to automatically supply the IDE, debuggers,
etc. that need to be there for industrial-strength use.
yes, agreed.
the "basic infrastructure" is needed, and to a large degree this is the
harder part, but it is far from a huge or impossible undertaking (it is
more a matter of scaling: namely tradeoffs between performance,
capabilities, and simplicity).
another issue though is the cost of implementing the POL/DSL/... vs the
problem area being addressed: even if creating the language is fairly
cheap, if the problem area is one-off, it doesn't really buy much.
a typical result is that of creating "cheaper" languages for more
specialized tasks, and considerably more "expensive" languages for more
general-purpose tasks (usually with a specialized language "falling on
its face" in the general case, and a general-purpose language often
being a poorer fit for a particular domain).
the goal is, as I see it, to make a bigger set of reusable parts, which
can ideally be put together in new and useful ways. ideally, the IDEs
and debuggers would probably work similarly (by plugging together logic
from other pieces).
in my case, rather than trying to make very flexible parts, I had been
focused more on making modular parts. so, even if the pipeline is itself
fairly complicated (as are the parts themselves), one could presumably
split the pipeline apart, maybe plug new parts in at different places,
swap some parts out, ... and build something different with them.
so, it is a goal of trying to move from more traditional software
design, where everything is tightly interconnected, to one where parts
are only loosely coupled (and typically fairly specialized, but
reasonably agnostic regarding their "use-case").
so, say, one wants a new language with a new syntax, there are 2 major
ways to approach this:
route A: have a "very flexible" language (or meta-language), where one
can change the syntax and semantics at will, ... this is what VPRI seems
to be working towards.
route B: allow the user to throw together a new parser and front-end
language compiler, reusing what parts from the first language are
relevant (or pulling in other parts maybe intended for other languages,
and creating new parts as needed). how easy or difficult it is, is then
mostly a product of how many parts can be reused.
so, a language looks like an integrated whole, but is actually
internally essentially built out of LEGO blocks... (with parts
essentially fitting together in a hierarchical structure). it is also
much easier to create languages with similar syntax and semantics, than
to create ones which are significantly different (since more differences
mean more unique parts).
granted, most of the languages I have worked on implementing thus far,
have mostly been "bigger and more expensive" languages (I have made a
few small/specialized languages, but most have been short-lived).
also, sadly, my project currently also contains a few places where there
are "architecture splits" (where things on opposite sides work in
different ways, making it difficult to plug parts together which exist
on opposite sides of the split). by analogy, it is like where the screw
holes/... don't line up, and where the bolts are different sizes and
threading, requiring ugly/awkward "adapter plates" to make them fit.
essentially, such a system would need a pile of documentation, hopefully
to detail what all parts exist, what each does, what inputs and outputs
are consumed and produced, ... but, writing documentation is, sadly,
kind of a pain.
another possible issue is that parts from one system wont necessarily
fit nicely into another:
person A builds one language and VM, and person B makes another language
and VM;
even if both are highly modular, there may be sufficient structural
mismatches to make interfacing them be difficult (requiring much pain
and boilerplate).
some people have accused me of "Not Invented Here", mostly for sake of
re-implementing things theoretically found in libraries, but sometimes
this is due to legal reasons (don't like the license terms), and other
times because the library would not integrate cleanly into the project.
often, its essential aspects can be "decomposed" and its functionality
is re-implemented from more basic parts. another advantage is that these
parts can often be again reused in implementing other things, or allow
better inter-operation between a given component and those other
components it may share parts with (and the parts may be themselves more
useful and desirable than the thing itself).
this also doesn't mean creating a "standard of non-standard" (some
people have accused me of this, but I disagree), since often all that is
needed is to create something in the form of the standard (and its
common/expected behaviors), and everything will work as expected.
so, the essence is in the form, and in the behaviors, and not in the
particular artifacts which are used to manifest it. so, one implements
something according to a standard, but the standard doesn't really care
whose code was used to implement it (or often, how things actually work
internally, which is potentially different from one implementation to
another).
sometimes, there are reasons to not just chase after the cult of "there
is a library for that", but, annoyingly, many people start raving at the
mere mention of doing some task without using whatever library/tool/...
they think "should" be used in performing said task.
granted, in a few places, I have ended up resorting to relational-style
systems instead (because, sadly, not every problem maps cleanly to a
tree structure), but these are typically rarer (but are more common in
my 3D engine and elsewhere, essentially my 3D engine amounts to a large
and elaborate system of relational queries (and, no, without using an
RDBMS), and only tangentially towards actually sending things out to the
video card). there are pros and cons here.
or such...
Cheers,
Alan
------------------------------------------------------------------------
*From:* Loup Vaillant <l...@loup-vaillant.fr>
*To:* fonc@vpri.org
*Sent:* Wednesday, February 29, 2012 1:27 AM
*Subject:* Re: [fonc] Error trying to compile COLA
Alan Kay wrote:
> Hi Loup
>
> Very good question -- and tell your Boss he should support you!
Cool, thank you for your support.
> [...] One general argument is
> that "non-machine-code" languages are POLs of a weak sort, but
are more
> effective than writing machine code for most problems. (This was
quite
> controversial 50 years ago -- and lots of bosses forbade using any
> higher level language.)
I didn't thought about this historical perspective. I'll keep that in
mind, thanks.
> Companies (and programmers within) are rarely rewarded for
saving costs
> over the real lifetime of a piece of software [...]
I think my company is. We make custom software, and most of the time
also get to maintain it. Of course, we charge for both. So, when we
manage to keep the maintenance cheap (less bugs, simpler code...),
we win.
However, we barely acknowledge it: much code I see is a technical debt
waiting to be paid, because the original implementer wasn't given the
time to do even a simple cleanup.
> An argument that resonates with some bosses is the "debuggable
> requirements/specifications -> ship the prototype and improve
it" whose
> benefits show up early on.
But of course. I should have thought about it, thanks.
> [...] one of the most important POLs to be worked on are
> the ones that are for making POLs quickly.
This why I am totally thrilled by Ometa and Maru. I use them to point
out that programming languages can be much cheaper to implement than
most think they are. It is difficult however to get past the idea
that
implementing a language (even a small, specialized one) is by
default a
huge undertaking.
Cheers,
Loup.
_______________________________________________
fonc mailing list
fonc@vpri.org <mailto:fonc@vpri.org>
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
