On Wed, 2016-09-07 at 20:29 +0000, jmh530 via Digitalmars-d-learn wrote:
> 
[…]
> Are you familiar with Chapel at all? The language allows the user to specify a domain with an array, facilitating sparsity or arrays distributed across different machines. For some reason I was reminded of that when you say that asrange returns a range that enumerates the contents.

I am certainly hoping that Chapel will be the language to displace NumPy for serious computation in the Python-sphere. Given it's foundation in the PGAS model, it has all the parallelism needs, both cluster and local, built in. Given Chapel there is no need to look at C++, D, Rust, Cython, etc.

-- 
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 Wed, 2016-09-07 at 20:29 +0000, deXtoRious via Digitalmars-d-learn wrote:
> 
[…]
> More to the general point of the discussion, I find that most scientifically minded users of Python already appreciate some of the inherent advantages of lower level statically typed languages and often rather write C/C++ code than descend into the likes of Cython. D has considerable advantages over C++ in conciseness and template facilities for achieving zero cost static polymorphism without descending into utter unreadability. Personally, I find myself still forced to write most of my non-Julia high performance code in C++ due to the available libraries and GPGPU support (especially CUDA), but in terms of language properties I'd much rather be writing D.

Or Chapel.

-- 
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 Wed, 2016-09-07 at 16:21 +0000, Kagamin via Digitalmars-d-learn wrote:
> On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote:
> > 
> > The real problem though is the terrifying error message. I am having a hard time finding a way of pitching them to Pythonistas.
> 
> Do they use single assignment a lot?

Python has no notion of single assignment. Exactly the opposite, Python allows everything to be changed at any time.

I fear there is a confluence of disjoint subthreads happening here. Probably my fault.

-- 
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 Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder wrote:
>
> I am certainly hoping that Chapel will be the language to displace NumPy for serious computation in the Python-sphere. Given it's foundation in the PGAS model, it has all the parallelism needs, both cluster and local, built in. Given Chapel there is no need to look at C++, D, Rust, Cython, etc.

I care about performance, but also about productivity. Chapel still has some ways to go on the latter. Also, they are still in the early stages of GPU support, I think.

On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder wrote:
> I am certainly hoping that Chapel will be the language to displace NumPy for serious computation in the Python-sphere. Given it's foundation in the PGAS model, it has all the parallelism needs, both cluster and local, built in. Given Chapel there is no need to look at C++, D, Rust, Cython, etc.

I can see where you are coming from, I have taken a look at Chapel and high performance computing is their top priority. I think they hope that it will be the next Fortran, but I think it is very much a domain specific language. They have clearly given plenty of thought to distributed computing, parallelization and concurrency that could yield some very nice performance advantages. However Python's advantage is that it is a dynamic language and can act as a front end to algorithms written in C/C++ for instance as Google has done with TensorFlow. In the future it could even act as a front end to Chapel since they now have a C API.

However, I feel as if computer programming languages are still in this static-dynamic partnership, e.g. Python with C/C++, R and Fortran/C/C++. It means language overhead always maintaining code in more than one language and always having to amend your interface every time you change something in one or the other. In essence, nothing fundamentally different is happening with current new languages. I hate to sound like a broken record, but what Sparrow proposes is a unification in such a way that all kinds of overheads go away. Making something like that work with the principles of Sparrow would be a revolution in computing.

On Thursday, 8 September 2016 at 10:20:42 UTC, Russel Winder wrote:
> On Wed, 2016-09-07 at 20:29 +0000, deXtoRious via Digitalmars-d-learn wrote:
>> 
> […]
>> More to the general point of the discussion, I find that most scientifically minded users of Python already appreciate some of the inherent advantages of lower level statically typed languages and often rather write C/C++ code than descend into the likes of Cython. D has considerable advantages over C++ in conciseness and template facilities for achieving zero cost static polymorphism without descending into utter unreadability. Personally, I find myself still forced to write most of my non-Julia high performance code in C++ due to the available libraries and GPGPU support (especially CUDA), but in terms of language properties I'd much rather be writing D.
>
> Or Chapel.

It's very early days for Chapel at the moment, but I don't really see it as being remotely comparable to D or even Julia, it's much closer to a DSL than a general purpose language. That's by no means a bad thing, it seems like it could be a very useful tool in a few years, but it's never going to completely substitute for the likes of Python, C++ or D even for purely scientific programming. I'm also a bit concerned about how limited the compile time facilities seem there at the moment, but I guess we'll just have to wait and see how it develops over the next couple of years.

On Thursday, 8 September 2016 at 10:26:04 UTC, Russel Winder wrote:
>> Do they use single assignment a lot?
>
> Python has no notion of single assignment. Exactly the opposite, Python allows everything to be changed at any time.

Then you probably shouldn't pitch them alien concepts?

On Thu, 2016-09-08 at 13:09 +0000, jmh530 via Digitalmars-d-learn wrote:
> On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder wrote:
> > 
> > 
> > I am certainly hoping that Chapel will be the language to displace NumPy for serious computation in the Python-sphere. Given it's foundation in the PGAS model, it has all the parallelism needs, both cluster and local, built in. Given Chapel there is no need to look at C++, D, Rust, Cython, etc.
> 
> I care about performance, but also about productivity. Chapel still has some ways to go on the latter. Also, they are still in the early stages of GPU support, I think.

For computational work I'd say Chapel was just as productive as any other language, probably better. This is though likely an issue on which there is only opinion and no facts.

GPGPU support is not in Chapel as yet I believe, but then it isn't in Python either.

-- 
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 Thu, 2016-09-08 at 14:39 +0000, data pulverizer via Digitalmars-d- learn wrote:
> […]
> 
> I can see where you are coming from, I have taken a look at Chapel and high performance computing is their top priority. I think they hope that it will be the next Fortran, but I think it is very much a domain specific language. They have clearly given plenty of thought to distributed computing, parallelization and concurrency that could yield some very nice performance advantages. However Python's advantage is that it is a dynamic language and can act as a front end to algorithms written in C/C++ for instance as Google has done with TensorFlow. In the future it could even act as a front end to Chapel since they now have a C API.

Why write algorithms in C or C++ when you can do it in Chapel? The point here is that Python folk should look to languages like Chapel and not C, C++, or even D when they reach the limits of Python performance.

And yes I am trying to get PyChapel to run on Python 3 as well as Python 2.

> However, I feel as if computer programming languages are still in this static-dynamic partnership, e.g. Python with C/C++, R and Fortran/C/C++. It means language overhead always maintaining code in more than one language and always having to amend your interface every time you change something in one or the other. In essence, nothing fundamentally different is happening with current new languages. I hate to sound like a broken record, but what Sparrow proposes is a unification in such a way that all kinds of overheads go away. Making something like that work with the principles of Sparrow would be a revolution in computing.

But how are they going to get traction?

Should we be giving up on D and switching to Sparrow?

Polyglots programmers tend to be better programmers. This is not opinion, there is experimental evidence for this in the psychology of programming literature.

-- 
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 Friday, 9 September 2016 at 13:24:18 UTC, Russel Winder wrote:
>
> For computational work I'd say Chapel was just as productive as any other language, probably better. This is though likely an issue on which there is only opinion and no facts.
>
> GPGPU support is not in Chapel as yet I believe, but then it isn't in Python either.

What I mean is that Chapel doesn't have a lot of libraries (also true for D, but things are getting better). If I'm going to do some analysis, it usually takes much less time for me to do it in R/Python/Matlab because they typically already have the libraries that can do everything I need.