On Monday, 28 April 2014 at 18:45:54 UTC, John Colvin wrote:
Libraries.
not part of the language (unless you count the standard
library. I don't see anything particularly special about
python's standard library).
Hmm… I think that for Python, Ruby and Perl, the libraries and
the ecosystems to a large extent are part of the language. And I
think the lack of C-like efficiency in the language encourage
that, e.g. you don't really care that much about a library being
50% faster/slower. You care primarily about getting the job done.
Not so with C/C++ libraries…
For closures for arrays and dicts.
I don't understand
I used the wrong term, I meant list comprehensions. The most
important feature in Python for me. I find it very powerful in
combination with tuples, lists and dicts.
improvements. It's surprising how much python-style tuple code
you can do in D already, but the syntax is a little lacking.
But for tuples the ease-of-use syntax is important, otherwise you
can just use struct or some other aggregate. Tuples are often
used as anonymous on-the-fly structs.
(Runtime integration of python and templates.)
I presume you mean web templates?
That is the most common scenario.
This is a strong point in favour of an interpreted language,
although the compile-time approach in vibe.d is powerful. As
long as the code doesn't change too often, you can always
recompile it and load as a shared library (I believe this is
being looked at by vibe.d developers).
Yeah, except when you build a CMS, but you can always include a
scripting language.
However, given the trade offs I still think I would prefer static
typing (such as D) because runtime errors tend to show up after
release. (Assuming fast on-the-fly compilation which is a
must-have for web development.)
Lots of how-to-stuff on the web.
Ditto
Actually, I think it is part of the language's resulting eco
system.
I believe "toolbox" languages like Python and Perl will have more
recipes and "nimble quick fix libraries" on the web than
application languages.
