On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote:
> On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
>> On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
>>> Personally, I'm not sure that much is gained in pitting Go against D
>>> precisely because they're so different that they're likely to appeal to
>>> completely different sets of people.
>>
>> I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
>
> How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code")

I think it's more of a competitor to Rails. Ruby as a language is as you say very different from Go. Incidentally, it shows that it is possible to make a language simple without crippling it.

On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote:
> Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it).

There are many alternatives to Python. Like Nim or Dart:

https://www.dartlang.org/articles/beyond-async/
https://www.dartlang.org/articles/await-async/

On Sunday, 29 March 2015 at 12:21:01 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote:
>> Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it).
>
> There are many alternatives to Python. Like Nim or Dart:
>
> https://www.dartlang.org/articles/beyond-async/
> https://www.dartlang.org/articles/await-async/

Nim seems quite interesting indeed, even if I'm not sure how well it scales. It looks like a language that is prowd of a heavy use of macros and DSL definition à la lisp. I know lisp enough to know that it's not a problem in itself, but that it should be developed wisely. It may look at first as a better alternative than D for a pure python developer, but I'll stick with D.

However, I can't see a pythonista being excited in Dart at all, at least not for what he finds in python. More restricted in any way, no clear functional orientation possible, a clear lack of expressiveness... D clearely has the advantage there.

On Sunday, 29 March 2015 at 12:50:38 UTC, cym13 wrote:
> Nim seems quite interesting indeed, even if I'm not sure how well it scales. It looks like a language that is prowd of a heavy use of macros and DSL definition à la lisp.

Nim is also too young to know if it stays around.

> However, I can't see a pythonista being excited in Dart at all, at least not for what he finds in python. More restricted in any way, no clear functional orientation possible, a clear lack

Actually, there is quite a large overlap if you look beyond the syntax. Dart is completely unexciting, but I also find it very productive when used with the IDE. I don't think any language without comprehensions can attract Python programmers for real, but the recent Dart 1.9 release also have compact Pythonesque generators (iterators/ranges) as you can see on the link above so I like the direction they are taking now.

Anyway, my point was more that making Python a target means you have to compete with a large set of other languages in the same vein. In the system language area you only have C++/Rust so it is an easier target. Unfortunately C++ still has a lot of advantages over other languages for real world projects, so it will remain my system level language until a better language starts polishing their low level stuff... :-/

On 3/29/15 4:43 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote:
>> On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
>>> On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
>>>> Personally, I'm not sure that much is gained in pitting Go against D
>>>> precisely because they're so different that they're likely to appeal to
>>>> completely different sets of people.
>>>
>>> I also do not regard Go as a competitor to D. It's more of a
>>> competitor to Java and Ruby.
>>
>> How is Go a competitor to Ruby? I cannot think of a single parameter
>> where Go and Ruby don't take the exact opposite approach!(other than
>> the obvious ones like "both use require the programmer to write code")
>
> I think it's more of a competitor to Rails. Ruby as a language is as you
> say very different from Go. Incidentally, it shows that it is possible
> to make a language simple without crippling it.

... but efficiency. Ruby is 50 times slower than all languages, including itself.

Andrei

On Sunday, 29 March 2015 at 15:57:18 UTC, Andrei Alexandrescu wrote:
> On 3/29/15 4:43 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote:
>>> On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
>>>> On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
>>>>> Personally, I'm not sure that much is gained in pitting Go against D
>>>>> precisely because they're so different that they're likely to appeal to
>>>>> completely different sets of people.
>>>>
>>>> I also do not regard Go as a competitor to D. It's more of a
>>>> competitor to Java and Ruby.
>>>
>>> How is Go a competitor to Ruby? I cannot think of a single parameter
>>> where Go and Ruby don't take the exact opposite approach!(other than
>>> the obvious ones like "both use require the programmer to write code")
>>
>> I think it's more of a competitor to Rails. Ruby as a language is as you
>> say very different from Go. Incidentally, it shows that it is possible
>> to make a language simple without crippling it.
>
> ... but efficiency. Ruby is 50 times slower than all languages, including itself.
>
> Andrei

Not to mention orthogonal safety. Even for a dynamically typed scripting language Ruby sacrifices a lot of safety. Not memory-wise but orthogonality-wise - it's design is very hackish, and you can remove an import("require") to foo.rb from bar.rb thus causing a bug in baz.rb that was importing bar.rb and thus indirectly importing qux.rb because foo.rb was importing it, and qux.rb is monkey-patching class Qux to override some method to return a different value. Have fun trying to debug this!

Computer science is all about tradeoffs. I used to love Ruby, but then a Rails project got out of hand... Nowadays I use it mainly as a bash replacement - Hundredfolds more expressive, only a tiny tiny bit syntax overhead, and for things that bash's safety would be enough Ruby's certainly suffices.

On Sunday, 29 March 2015 at 15:34:35 UTC, Ola Fosheim Grøstad wrote:
> Actually, there is quite a large overlap if you look beyond the syntax. Dart is completely unexciting, but I also find it very productive when used with the IDE.

Glad to hear this - I haven't yet got very far with Dart, but it seems like a toss-up between Dart and Livescript for a passable language to run on the client (for my little use case).

> Anyway, my point was more that making Python a target means you have to compete with a large set of other languages in the same vein. In the system language area you only have C++/Rust so it is an easier target. Unfortunately C++ still has a lot of advantages over other languages for real world projects, so it will remain my system level language until a better language starts polishing their low level stuff... :-/

Peter Thiel is right.  Competition is overrated, and it is much better to have a monopoly in a small domain and build out from there - one shouldn't think in terms of acquiring market share if one is not already one of the dominant players (and even then to do so is often counterproductive).

D isn't a product marketed by Proctor and Gamble.  So nobody is going to make Python a target, as best I can tell.  But one can surely learn from what they do right, to the extent that it applies to new conditions of the future.  The obvious things are documentation, libraries, and having a nice, easy-to-install, and low-friction set of choices in development stacks organised and available.

Knuth is also right that people think in different ways, and it's an entirely natural thing to see a multiplicity of languages emerging that are adapted to these different ways (and of course the particular challenges people face are also different).  That's why religious wars about these things have a bad name.  That doesn't mean people shouldn't have a perspective and argue for it when such discussions are generative.

D will continue to gather success if it keeps getting better and confronting the painful challenges of growth, as seems to me to be happening in my short time here.  Naysayers are an asset if one doesn't get discouraged, because it is difficult to buy good criticism at any price.

On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote:

> Urr.... As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently.
>
> On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^"
>
> Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it).
>
> UFCS FTW!

As an active Python developer, what would you add to or change about the following:
http://bitbashing.io/2015/01/26/d-is-like-native-python.html

On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote:
> As an active Python developer, what would you add to or change about the following:
> http://bitbashing.io/2015/01/26/d-is-like-native-python.html

I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is).

In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like "or web server developments with vibe.d" thrown in a sentence.

Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal "Writting Python in D".

Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python).

I'll try giving it to some friends to see what they think about it :)

On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote:
> On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote:
>
>> Urr.... As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently.
>>
>> On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^"
>>
>> Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it).
>>
>> UFCS FTW!
>
> As an active Python developer, what would you add to or change about the following:
> http://bitbashing.io/2015/01/26/d-is-like-native-python.html

while it mentions concurrency/parallel, a quick example of showing how easy it is to do parallel operations in D would probably benefit considering python's current state of parallelism.