[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scriptometer: measuring the ease of SOP (Script Oriented Programming) of programming languages



"Anton van Straaten" <anton@appsolutions.com> writes:

[...]

> 2. How well does it support being externally scripted by some other
> language, possibly including a script-oriented version of itself?
> 
> 2a.  How good is the support it provides to the implementor of an external
> scripting language?

[...]

> Factors which affect scores for 2 & 2a would be the presence of garbage
> collection, support for dynamic code loading and reloading, reflection, and
> more which I touch on below.

hum, this is dangerous, because it *forces* the programming style:
implementing Python/Perl on top of Haskell would be hard because
haskell's library is thought very differently (purity, lazy, monads).
So you couldn't re-use anything from haskell's library.

Ultimately, your question is: does a language provide the features
that *my* scripting language needs. So if the reference is Ruby/Perl,
the response to 2 & 2a will be:
- Perl/Ruby/Python have good support (since their VM is somewhat the
same (if you agree to drop things like determinist GC, ...))
- Java has good support (since it keeps types at runtime, it has a VM,
but its library doesn't use anonymous argument)
- OCaml and C++ are bad (since their type system is powerful enough to
get rid of most runtime information)
- Haskell is bad (since it's lazy oriented...)
- C is bad

I don't think one characteristic of Script-Oriented Programming is the
ability to write a small scripting dynamically-typed OO language ;p

I'd rather have a language-agnostic description of SOP.

Does this make some sense or did i miss something? Our SOP definition
may differ? and maybe i want to keep OCaml/Haskell high and Java low
:)


[...]

> > I don't know either if having two different garbage collectors
> > is better than having only one gc interfacing with C. When
> > extending Ruby or OCaml in C, you don't have to care about
> > garbage collection.
> 
> I'm not sure what you're referring to.  None of the JVM scripting languages
> I've worked with have two garbage collectors - they all rely on JVM
> collection.

I didn't make myself clear enough. Example: use CPython (which is
written in C and has its own GC) to "script" Java.

But let's dump that part which is not the one you're talking about :)