python vs d

[via Digitalmars-d]

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.