Compiler as dll

[Yigal Chripun]

Bill Baxter wrote:
> On Fri, Jan 30, 2009 at 8:40 AM, Christopher Wright<dhasenan at gmail.com>  wrote:
>> Daniel Keep wrote:
>>> Personally, I think the best approach is to combine the two; write the
>>> hot spots in C, D or some other fast language, and all the glue in a
>>> dynamic language.  For all it's expressiveness, there are just some
>>> things that are easier to do with a dynamic language like Python or Lua
>>> than with D.
>> I keep hearing this stated, but I don't see very many use cases put forth
>> where it is clearly better to use a dynamic language. For me, I'm not
>> familiar with any dynamic languages to a sufficient degree to ever get an
>> advantage from using them, but if I see a sufficient use case, I'll change
>> that.
>
> Since Variants are kind of the basic variable type in dynamic
> languages, basically anywhere you can benefit from variants is a win
> for dynamic langs.   More generally there are times when you can't
> really know what types things are going to be till run time.   For
> instance dealing with a database.  In a dynamic lang you can create
> new aggregate types on the fly that are just like built-in types.   Or
> say you have an algorithm that can work on lots of different kinds of
> data types.  But you need to load the data from a file at runtime,
> including the type.  To do that with C++/D templates you have to
> pre-instantiate every possible type you want to support, even though
> most runs of your program will use only one or two instantiations of
> it.  With a dynamic language you don't have to pre-instantiate
> anything, so such things are a lot easier.
>
> In GUIs when you need to loosely couple different components, dynamic
> langs can make life a lot easier.  With std.signals in D, for
> instance, you have to be so anal about the call signatures.  And you
> may have trouble calling a delegate that takes a bool when the signal
> sends out an int, etc   Such things are rarely any problem for a
> dynamic language.  Variable numbers of args are also generally very
> easy to use.
>
> Basically imagine any annoyance you have with D or C++.  With a
> dynamic language it pretty much disappears. :-)   (But of course you
> will encounter new issues, like performance, or higher testing burden
> because no types are statically checked).
>
> One thing, though, that I noticed using Python, is that a lot of what
> is considered so easy-to-use about dynamic languages is just that
> people are more willing to use expensive (but elegant) abstractions.
> If you're willing to do things in a slightly less efficient way, you
> can make the code look pretty darn elegant.  I think this is the basis
> of much of Bearophile's libs.  Most of the time you really don't need
> that extra performance.  With a dynamic language there's no way to
> really get the performance, anyway, so you might as well use something
> elegant.   People seem to have a harder time throwing away their
> desire for efficiency when they know their language *is* capable of
> being efficient.  I'm certainly included in that group.   I would have
> a hard time convincing myself to code in D similar to how I code in
> Python.  It just feels so sloppy to me when it's in D, because I know
> D can do better.   But in truth, most of the code I write would
> probably perform fine even with large helpings of extra slop.
>
> --bb

Static languages can have Variant/box types that'll give most of the 
same functionality of dynamic languages. so, instead of instantiating 
list!(int), list!(string), etc, you can get one list!(Variant)..
C# provide such a feature with a keyword instead of rellying on templates.

The real difference is that static languages have mostly read-only RTTI. 
(Java provides a very limited capability to reload classes, IIRC)
a scripting language allows you to manipulate Types and instances at 
run-time, for example you can add/remove/alter methods in a class and 
affect all instances of that class, or alter a specific instance of a 
class. This cannot be done in a static language.