On Monday, 28 April 2014 at 09:10:53 UTC, Chris wrote:
> On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:
>> I am following discussions about GC and some other 'critical' improves in D language for a long time. I see a lot of arguments and heaps of code, that often hard to understand (for example Templates) even more complicated to use it.
>>
>> I like D, but more and more I am playing with Python, and understanding it's philosophy. And I like it because it's do not have any overhead like C++. It's clean any easy to understanding. As result it's harder to write bad code in it.
>>
>> Does anybody make tests of speed most common algorithm in D and Python. I am trying to understand which project better to start in Python and which in D.
>
> In my experience, it is better to start a new project with D, not only because of speed. As a project grows, the restrictions of Python become more apparent (and annoying). If copyright is an issue, D is the better option, too. Python can be decompiled easily. I don't know what kind of projects you have in mind, but in our projects Python is always the bottleneck and has to be rewritten in a different language anyway, sooner or later.

My experience mirrors this exactly. I find Python quite quickly becomes unwieldy for large projects, even if the performance is not an issue.

As with all these things, YMMV; there are many large, successful Python projects.


It is pretty good for interactive work, especially if you can leverage the large body of work that the scientific community has produced in python.


Choosing between D and Python:

Pretty much anything written in pure Python can be easily demolished by D in terms of performance.

D doesn't have much provision for interactive work (work in progress).

You can do 2-way communication between D and Python (https://bitbucket.org/ariovistus/pyd)

Fast algorithms that you use in Python are often implemented in C as extensions. D can call C code directly. C vs D is very much splitting hairs when it comes to performance.

D has a steeper learning curve, but it will teach you widely applicable knowledge and skills.

On Mon, 2014-04-28 at 09:27 +0000, John Colvin via Digitalmars-d wrote: […]
> As with all these things, YMMV; there are many large, successful Python projects.

I think this is a crucially important thing to remember: YMMV.

This is not a black and white, D or Python. Different organization and projects will have different metrics for choice, meaning that Python, D, Go, C++, Java, Groovy, etc. all have valuable roles in the world. Choice of programming language is about making the least worst choice in a given context.

The fact that I am rewriting a Python + GTK project in D + GtkD does not mean I now no longer use Python, it is that the context has changed, making a change of language appropriate.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 28 April 2014 at 09:27:33 UTC, John Colvin wrote:
> On Monday, 28 April 2014 at 09:10:53 UTC, Chris wrote:
>> On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:
>>> I am following discussions about GC and some other 'critical' improves in D language for a long time. I see a lot of arguments and heaps of code, that often hard to understand (for example Templates) even more complicated to use it.
>>>
>>> I like D, but more and more I am playing with Python, and understanding it's philosophy. And I like it because it's do not have any overhead like C++. It's clean any easy to understanding. As result it's harder to write bad code in it.
>>>
>>> Does anybody make tests of speed most common algorithm in D and Python. I am trying to understand which project better to start in Python and which in D.
>>
>> In my experience, it is better to start a new project with D, not only because of speed. As a project grows, the restrictions of Python become more apparent (and annoying). If copyright is an issue, D is the better option, too. Python can be decompiled easily. I don't know what kind of projects you have in mind, but in our projects Python is always the bottleneck and has to be rewritten in a different language anyway, sooner or later.
>
> My experience mirrors this exactly. I find Python quite quickly becomes unwieldy for large projects, even if the performance is not an issue.
>
> As with all these things, YMMV; there are many large, successful Python projects.
>
>
> It is pretty good for interactive work, especially if you can leverage the large body of work that the scientific community has produced in python.

Yeah, Python is good for fast prototyping, that's why the scientific community uses it. However, when it comes to using the code for real world apps, you have to rewrite it in C/C++ or D (or the like).

> Choosing between D and Python:
>
> Pretty much anything written in pure Python can be easily demolished by D in terms of performance.
>
> D doesn't have much provision for interactive work (work in progress).
>
> You can do 2-way communication between D and Python (https://bitbucket.org/ariovistus/pyd)
>
> Fast algorithms that you use in Python are often implemented in C as extensions. D can call C code directly. C vs D is very much splitting hairs when it comes to performance.

This is true, and this is one of the arguments I use, when it comes to rewriting code in D, i.e. that D can interface _directly_ to those libraries anyway.

> D has a steeper learning curve, but it will teach you widely applicable knowledge and skills.

And you can write sound code in D without templates and ranges etc, if you don't understand the concepts yet. Once you understand them, you can soup up your code with all the fancy stuff.

On Mon, 2014-04-28 at 09:43 +0000, Chris via Digitalmars-d wrote: […]
> Yeah, Python is good for fast prototyping, that's why the scientific community uses it. However, when it comes to using the code for real world apps, you have to rewrite it in C/C++ or D (or the like).

Why?

Many people use Python codes in the real world quite happily, there is no necessity to rewrite at all.

[…]

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 28 April 2014 at 13:26:51 UTC, Russel Winder via Digitalmars-d wrote:
> On Mon, 2014-04-28 at 09:43 +0000, Chris via Digitalmars-d wrote:
> […]
>> Yeah, Python is good for fast prototyping, that's why the scientific community uses it. However, when it comes to using the code for real world apps, you have to rewrite it in C/C++ or D (or the like).
>
> Why?
>
> Many people use Python codes in the real world quite happily, there is
> no necessity to rewrite at all.
>
> […]

E.g. an algorithm for signal processing. Python is fine for prototyping, but if you want your algorithms to work in a real world app at real time, you'll have to rewrite it in C/C++, D or whatever. I've adopted the policy (where ever applicable) to use D straight away. It's just not worth it to develop something in Python and rewrite it in D later. I don't see the benefits of writing in Python, only drawbacks in the long run.

On Mon, 2014-04-28 at 14:15 +0000, Chris via Digitalmars-d wrote: […]
> E.g. an algorithm for signal processing. Python is fine for prototyping, but if you want your algorithms to work in a real world app at real time, you'll have to rewrite it in C/C++, D or whatever. I've adopted the policy (where ever applicable) to use D straight away. It's just not worth it to develop something in Python and rewrite it in D later. I don't see the benefits of writing in Python, only drawbacks in the long run.

Certainly for signal processing algorithms where speed, concurrency and parallelism are orders of the day, I would choose D or Go from the outset. I wouldn't choose to use Python for this, but many people do, including the folk I am off to do a Python workshop for in a couple of weeks. Their environment is one in which Python is the only option (long story), so they write in Python and then optimize by using Cython on the CPU intensive codes. This actually works very well for them.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 28 April 2014 at 16:22:47 UTC, Russel Winder via Digitalmars-d wrote:
>Their environment is one in which Python is the only
> option (long
> story), so they write in Python and then optimize by using Cython on the
> CPU intensive codes. This actually works very well for them.

Don't forget that pypy compiles rpython to C or llvm.

On Monday, 28 April 2014 at 09:41:43 UTC, Russel Winder via Digitalmars-d wrote:
> On Mon, 2014-04-28 at 09:27 +0000, John Colvin via Digitalmars-d wrote:
> […]
>> As with all these things, YMMV; there are many large, successful Python projects.
>
> I think this is a crucially important thing to remember: YMMV.
>
> This is not a black and white, D or Python. Different organization and
> projects will have different metrics for choice, meaning that Python, D,
> Go, C++, Java, Groovy, etc. all have valuable roles in the world. Choice
> of programming language is about making the least worst choice in a
> given context.
>
> The fact that I am rewriting a Python + GTK project in D + GtkD does not
> mean I now no longer use Python, it is that the context has changed,
> making a change of language appropriate.

Although I stick by the YMMV, I use python 3 several hours a day and it's caused me no end of pain with very little gain. If it wasn't for pandas and (I shudder to say it) matplotlib, I really wouldn't have any reason to stay.

What features does python, as a language (syntactical preferences aside), actually have to recommend it over D (assuming drepl* or similar became full-featured)? This is definitely not a rhetorical question, it could be useful to D development.

* http://drepl.dawg.eu/ and https://github.com/MartinNowak/drepl

On Monday, 28 April 2014 at 18:07:45 UTC, John Colvin wrote:
> What features does python, as a language (syntactical preferences aside), actually have to recommend it over D (assuming drepl* or similar became full-featured)?

Libraries.
For closures for arrays and dicts.
Tuples.
Heavy duty reflection and runtime dynamics.
(Runtime extensible classes.)
(Runtime integration of python and templates.)
System support (app engine, etc).
Lots of how-to-stuff on the web.

On Monday, 28 April 2014 at 18:18:25 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 28 April 2014 at 18:07:45 UTC, John Colvin wrote:
>> What features does python, as a language (syntactical preferences aside), actually have to recommend it over D (assuming drepl* or similar became full-featured)?
>
> Libraries.
not part of the language (unless you count the standard library. I don't see anything particularly special about python's standard library).

> For closures for arrays and dicts.
I don't understand

> Tuples.
std.meta is on it's way, possibly with some small language improvements. It's surprising how much python-style tuple code you can do in D already, but the syntax is a little lacking. (e.g. `int a, b, c; std.typetuple.TypeTuple!(a, c, b) = std.typecons.tuple(2, 3, 7).expand;`)

> Heavy duty reflection and runtime dynamics.
Agreed. However, a lot of this is obviated by the compile-time abilities of D. Perhaps I'm just not that imaginative with my runtime introspections.

> (Runtime extensible classes.)
I don't imagine this being difficult to do as a library type with opDispatch. This would be an interesting little project.

> (Runtime integration of python and templates.)
I presume you mean web templates? 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).

> System support (app engine, etc).
Not part of the language

> Lots of how-to-stuff on the web.
Ditto