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

D can actually do a rather good job of runtime reflection. I made a runtime reflection module (https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/ShardTools/Reflection.d / https://shardsoft.com/docs/ShardTools/Reflection.html) for my own personal code and it's served the uses I've needed it for quite nicely. Python I'd imagine has runtime reflection by default, but you could do this in D too by using RTInfo to automatically generate reflection data for every class. And while I'm sure Python has much more advanced reflection capabilities, I don't think the vast majority of users really require much more than the basics like looking up fields / invoking methods from user input, which D can easily handle. In the situations where you do need a completely dynamic type, people have already made such types in D by using opDispatch (http://forum.dlang.org/post/kuxfkakrgjaofkrdvgmx@forum.dlang.org).

(I wouldn't recommend others to use my reflection module directly as it'll get breaking changes and probably has bugs, but it's Boost licensed so if anyone wanted to they could add relevant parts into their project. I think it's also responsible for very large executables on OSX/Linux, but not on Windows.)

On Monday, 28 April 2014 at 17:28:16 UTC, Ola Fosheim Grøstad wrote:
> 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.

But all of the above are extra steps you have to take and are not really Python anymore. You depend on 3rd party software to tune your code. With D I have full control over my code from the start. Cython and the like can introduce their own little problems. Another layer of complexity. Another black box.

If you have a nice algorithm that really improves the program and then you hear "Well, it takes about 4-10 seconds, it's written in Python", then you go "Arrgghhh!" Cython can help to speed things up, but you have little control over what is going on. So why not craft your own custom code in C or D whenever possible?

My point is basically: a lot of projects / modules start out as little helper functions, prototypes or proofs-of-concept, but grow bigger very fast. Especially in the scientific community Python is popular because one can protoype very fast, test things etc. However, as the code base grows it becomes more and more obvious that Python is too slow and doesn't scale very well. I always say that if you have good code, think production and deployment, choose a systems programming language, it will pay in the end. Because the headaches you will have later with Python/Cython, will outweigh the initial advantages of "fast development". (I think it's better to develop a tad slowlier and consider various options for and aspects of a program than to have a quick success, but a solid mess. A lot has to do with impatience, not only deadlines).

Chris:

> Especially in the scientific community Python is popular because one can protoype very fast, test things etc. However, as the code base grows it becomes more and more obvious that Python is too slow and doesn't scale very well.

Julia seems to be gaining many users, it's a language that is growing very fast, it's already usable despite being rather young. The number of its major design mistakes seems small (like arrays indexing not starting from 0, and few other things).

Bye,
bearophile

Am 28.04.2014 22:31, schrieb bearophile:
> Chris:
>
>> Especially in the scientific community Python is popular because one
>> can protoype very fast, test things etc. However, as the code base
>> grows it becomes more and more obvious that Python is too slow and
>> doesn't scale very well.
>
> Julia seems to be gaining many users, it's a language that is growing
> very fast, it's already usable despite being rather young. The number of
> its major design mistakes seems small (like arrays indexing not starting
> from 0, and few other things).
>
> Bye,
> bearophile

Pascal expatriates like myself won't consider indexes from 1 a design mistake. :)

--
Paulo

Paulo Pinto:

> Pascal expatriates like myself won't consider indexes from 1 a design mistake. :)

What's the good of having all arrays always start from index 1 (this is different from Ada, where you can choose the indexing range and type)?

Bye,
bearophile

On 4/28/2014 6:31 PM, bearophile wrote:
> Paulo Pinto:
>
>> Pascal expatriates like myself won't consider indexes from 1 a design
>> mistake. :)
>
> What's the good of having all arrays always start from index 1 (this is
> different from Ada, where you can choose the indexing range and type)?
>

VB6 let you choose your starting index, too. It was rarely useful and constantly made array-handling code a pain in the ass. Of course, VB made pretty much everything a PITA...(I used to work at a VB6 house. *shudder*)

Nick Sabalausky:

> VB6 let you choose your starting index, too. It was rarely useful and constantly made array-handling code a pain in the ass. Of course, VB made pretty much everything a PITA...(I used to work at a VB6 house. *shudder*)

(As far as I know, and I am ignorant about Julia) in Julia you can't choose the start index of an array, they start from index 1. So the situation is not the same as VB.

I have written more Delphi code than D code, and I've seen that being able to choose the index range is quite useful, you can use enumerations and characters to index arrays :-) You avoid "c - '0'" the idiom used in D, and associative arrays with enum keys, while keeping the code very efficient and generally not bug-prone.

I don't know VB much, but all language features should not be abused. And they work or fail not just being good themselves, but in the context (and ecology) of all other features of a language. This means choosing arrays index types and start values is very good in Ada, it's rarely a PITA. But perhaps a similar feature is not good if used in VB. Ada has a very strong static typing, so being able to specify array index types gives you back lot of safety that probably is not available in VB. So the return of investment is probably different.

I think it could be a good idea to add something intermediate to D: optional strong typing for array indexing. I'd like to write a DIP on this someday (note that this does not mean I am suggesting D array indexes to optionally start from values different from 0. I am referring just to types, and enumerations are could be not supported).

Bye,
bearophile

On Monday, 28 April 2014 at 22:31:58 UTC, bearophile wrote:
> Paulo Pinto:
>
>> Pascal expatriates like myself won't consider indexes from 1 a design mistake. :)
>
> What's the good of having all arrays always start from index 1 (this is different from Ada, where you can choose the indexing range and type)?
>
> Bye,
> bearophile

True, in Pascal languages you can choose the starting index.

On 4/28/2014 7:02 PM, bearophile wrote:
> Nick Sabalausky:
>
>> VB6 let you choose your starting index, too. It was rarely useful and
>> constantly made array-handling code a pain in the ass. Of course, VB
>> made pretty much everything a PITA...(I used to work at a VB6 house.
>> *shudder*)
>
> (As far as I know, and I am ignorant about Julia) in Julia you can't
> choose the start index of an array, they start from index 1. So the
> situation is not the same as VB.
>
> I have written more Delphi code than D code, and I've seen that being
> able to choose the index range is quite useful, you can use enumerations
> and characters to index arrays :-) You avoid "c - '0'" the idiom used in
> D, and associative arrays with enum keys, while keeping the code very
> efficient and generally not bug-prone.
>
> I don't know VB much, but all language features should not be abused.
> And they work or fail not just being good themselves, but in the context
> (and ecology) of all other features of a language. This means choosing
> arrays index types and start values is very good in Ada, it's rarely a
> PITA. But perhaps a similar feature is not good if used in VB. Ada has a
> very strong static typing, so being able to specify array index types
> gives you back lot of safety that probably is not available in VB. So
> the return of investment is probably different.
>

Yea. To be perfectly fair, "classic" VB made pretty much anything a pain. I imagine a better language could probably manage custom index ranges much better than VB6 did.

In VB6, it was a pain because of iterating over the elements. Since it lacked anything like foreach (as I recall), the simplest "iterate over an array" was something like (from memory, might not have it exact):

FOR index = 0 TO Len(myArray)

*But* that code was wrong. It would *usually* work, and then suddenly blow up whenever someone used a different starting index. So instead, it was best to use this syntactic mess every time you iterated:

FOR index = LBound(myArray) TO UBound(myArray)

Ugh, I don't miss VB. Worse still, it was so "simple" it encouraged companies (like the one where I worked) to use "programmers" who were absolute bottom-level and wrote the WORST code. I saw shit at that job that (I'm not exaggerating here) even CS 101 students know not to do. It was amazing any of our codebase even worked at all.

Back to the point though, having never looked at Julia, I assume it probably does a much better job of this stuff than VB did.