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