Compiler as dll

[bearophile]

Bill Baxter:

>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.<

It's also a matter of handy syntax too, and having some type inferencing (or dynamic typing. Type inferencing may require a more complex type system, and a more complex and often slower compiler).

I want to add two notes:

1) My work on ShedSkin (a partial Python => C++ compiler) has shown me that you can have a very handy syntax in statically typed C++-like language too.

For example in Python you have list comps and generator expressions that are handy syntax, you need more code to write them in D:

foo = [[x*y for x in someiterable] for y in somestring.split()]
foo = ([x*y for x in someiterable] for y in somestring.split())

Other handy syntax is from iterators:

def bar():
  for x in xrange(10):
    yield x*x

I miss those three things in D still. In my libs there are ways to do similar things, but they become quite more hairy and full of {}(), so in the end you may want to not use them at all in a real program.
I hope D developers will eventually add list comps, iterators, and some other syntactic sugar to D.


2) Haskell compilers (and the Stalin Scheme compiler) show that if build a complex enough compiler, it can often be able to compile such abstractions to fast enough code. Not as fast as C code, but good enough for every noncritical spots in your program.


>People seem to have a harder time throwing away their desire for efficiency when they know their language *is* capable of being efficient.<

This requires you to know other languages, and to perform some self-control. Self-control is often one of the main things hat tell apart an adult professional person from a young newbie, outside the field of programming too.
I think it can use to perform some "katas", shape exercises where you write the same code in various ways (and maybe you also benchmark them).

----------------------

dsimcha:

>"wait a minute, I _could_ do it that way in D, it's just that I never would because when I'm in D coding mode I'm so used to thinking about efficiency."<

That's why it's good to learn to program in different languages (Prolog, Lisp or Scheme, Haskell, Python, Erlang, C, C++, Mathematica, Java or C#, Oz or Mozart, a data flow language, and little else). You may need a life to learn them all :-) And when you know them, you may be too much old to do something good, that's why life is evil :-)


>Now, when I'm coding a part of a D program where performance isn't going to matter, like a function that gets run once at startup, I actively try to force myself _not_ to think about efficiency and to just keep it simple and elegant.<

Because:
>We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.<
:-)

Bye,
bearophile