Prism criticism

[Maneesh Yadav]

On Sat, 5 Jun 1999, Jim Little wrote:

> Maneesh Yadav wrote:
> > 
> > On Sat, 5 Jun 1999, Jim Little wrote:
> 
> > > My eventual goal is for the mini-languages and mini-compilers to
> > > interoperate.  That's what all the different pieces of Prism are for.
> > > The meta-metamodel provides a standard format for program models.  The
> > > global heap provides a place for the different parts of the model to
> > > reside.  And the interpreter provides a compilation engine.
> > 
> > The hard part to get all these languages to communicate is to setup up the
> > details of the communication channels between them.  
> 
> Agreed.  :)  I have some ideas, but nothing worth mentioning at this
> time.
> 
> > I still don't see how
> > your Prism syntax fits into this idea of tonnes of mini languages.  
> 
> By "Prism syntax," I assume you mean the meta-metamodel.  (The _Bit,
> _Map, _Stream stuff.)  It provides two things:
> 
> 1) It's easier to manipulate than plain text.  Every atom corresponds to
> exactly one piece of information, whereas in plain text, it may take
> multiple characters to represent an atomic unit of information.  (For
> example, '(double)31' is an atomic concept that requires multiple
> characters.)  Compilers deal with this by parsing the text into an
> internal format; I'm just making that internal format explicit and
> standardized.
> 
> 2) Language-neutrality.  This isn't as big of a deal, but it means that
> both visual and textual languages are parsed into the same internal
> format.

What makes your format so special that it would be the choice for
representation in textual and visual?  There are other languages that
assume just as much your yet are easier to write and have the adavtage of
already being implemented over platforms, visual and textual environments
(eg C++)?  SO would you code the mini languages you speak of in prism or
the applications or both?  I don't see where this Prism syntax would be
used?

  It also allows multiple languages per metamodel -- as you say
> below, this may not be a good thing :) but it does allow languages to be
> improved over time (taking out ambiguous syntax, adding convenience
> features, etc) without changing the metamodel.

Why not just use well tested and apparently more robust C or a given
bytecode?

> 
> > And
> > how much time would you save, the obvious problem is that if I am doing an
> > application that combines graphics and database searching, I don't want to
> > have to learn a new language for each.  That is a problem today, too many
> > languages each with just a slightly syntacically different way of doing
> > the exact same semantic thing...would your proposal not make it worse?
> 
> This is a really good point, and something I'm a concerned about.  My
> hope is that each mini-language will be really small. 

Have you considered the fact then you would be trading off power?

 Also, I'm hoping
> I can get the interoperability strong enough that each kind of
> programming is handled by a single language.  So any time you want to do
> normal imperative programming, you embed code in the same language you
> always use for imperative programming, no matter what else you're doing
> (web, 3D, etc).  That's the plan, anyway.  I won't know if it's feasible
> until I try...

I really don't see how can possibly test this hypothesis by making 
minilanguages that cover a wide enough spectrum in some reasonable amount
of time by yourself, or if the effort would warrant a number of people
doing it, and how it would be any different from the fact that there
generally are tonnes of mini languagesfor various tasks already available
(POV for raytracing, OpenGL for real time 3d, SQL for database, Java for
dinky web applets), and it is already terribly apparaent to me that
linking these things after designing them is not an easy task, just ask
any one who uses Java and SQL or wants a modeller that will work for
POV...I don't see how the prisim approach will help this situation.

> Jim
> 
> Prism is at http://www.teleport.com/~sphere
>