On 3/14/15 1:59 AM, Russel Winder via Digitalmars-d wrote:
> What D should do is ensure that it can be a language usable from
> Jupyter?

It should secure a strong champion with the interest and expertise in making that work. -- Andrei

On 3/14/15 2:02 AM, Russel Winder via Digitalmars-d wrote:
> On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via Digitalmars-d
> wrote:
>> On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote:
>>> The removal of shared memory multi-threading in favour of using
>>> processes and channels should never be underestimated as a Really Good
>>> Thing™ that other native code languages (*) have failed to do anything
>>> about. Thus Go wins, others lose.
>>
>> That's a marketing success as well. Go didn't "remove" shared memory
>> multi-threading, it just unrecommends it. That's quite unremarkable from
>> a programming language design standpoint, but as discussed that's not
>> always crucial for success. -- Andrei
>
> I think you need to show a bit of Go code that uses threads to be able
> to back up that claim.

package main

type Data struct {
    i int
}

func func1(c chan *Data ) {
    var t *Data;
    t = <-c
    println(t)
}

func func2(c chan *Data ) {
    var t *Data;
    t = <-c
    println(t)
}

func main() {
    c := make(chan *Data)
    t := Data{10}
    go func1(c)
    c <- &t
    go func2(c)
    c <- &t
    println(&t)
}

On 3/14/15 7:45 AM, rumbu wrote:
> As you can see, there is nothing wrong with the language itself, but
> with the library.

s/library/documentation/

On Saturday, 14 March 2015 at 00:33:43 UTC, engnieer wrote:
>
>> [1] The problem is that all these nice Python and R implementations are practically useless for real world applications. Too slow, too cumbersome, too many dependencies. It has to be rewritten anyway. (I'd be happy, if they used at least C.)
>
> No, no, no. Your "real world" doesn't seem to include all the engineering industries. I work for an engineer company and use python everywhere for application code, and of course matlab-simulink for hard realtime code.
>
> For us, Russel's comment on super structure is right on target.
>
> - engineer.

Unfortunately, for speech and language processing (synthesis, speech recognition etc) Python is too slow. Everybody uses Python at first, but the serious code that is later put into real world applications is usually written in C or C++. This is a fact. I know people who developed speech analysis frameworks in Python and are now thinking of rewriting it in C++ for commercial purposes.

Python is good for protoyping, but if you need fast applications, it is usually C/C++ (or D).

On Saturday, 14 March 2015 at 17:22:27 UTC, Chris wrote:
> On Saturday, 14 March 2015 at 00:33:43 UTC, engnieer wrote:
>>
>>> [1] The problem is that all these nice Python and R implementations are practically useless for real world applications. Too slow, too cumbersome, too many dependencies. It has to be rewritten anyway. (I'd be happy, if they used at least C.)
>>
>> No, no, no. Your "real world" doesn't seem to include all the engineering industries. I work for an engineer company and use python everywhere for application code, and of course matlab-simulink for hard realtime code.
>>
>> For us, Russel's comment on super structure is right on target.
>>
>> - engineer.
>
> Unfortunately, for speech and language processing (synthesis, speech recognition etc) Python is too slow. Everybody uses Python at first, but the serious code that is later put into real world applications is usually written in C or C++. This is a fact. I know people who developed speech analysis frameworks in Python and are now thinking of rewriting it in C++ for commercial purposes.
>
> Python is good for protoyping, but if you need fast applications, it is usually C/C++ (or D).

And by the way, the fast Python code is usually a module written in C or some Cython magic. So it's back to C again.

On Sat, 2015-03-14 at 09:56 -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 3/14/15 1:40 AM, Russel Winder via Digitalmars-d wrote:
> > On Fri, 2015-03-13 at 16:13 -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> >> On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote:
> >>> On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d
> >>> wrote:
> >>> […]
> >>>
> >>>>
> >>>>      File("/tmp/a").byChunk(4096).joiner.startsWith(s)
> > […]
> >>
> >> How do you mean "conversely"? Maybe you meant "incidentally"? -- Andrei
> >
> > In functional languages, each stage in the pipeline returns Option to avoid error handling. Go does not give you this facility as it refuses to allow activity without proper error checking.
> 
> Go does not give you this facility for a multitude of reasons, starting with its lack of generic programming.

This is not the reason, although it is a huge factor, the following is…
> 
> > So if byChunk returns a failed read, functional language just carry on, Go would force the error check, D does…
> 
> D throws an exception. Is that good or bad?

Works for me, unacceptable in Go which forbids exceptions for anything other than termination.

-- 
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 Sat, 2015-03-14 at 17:22 +0000, Chris via Digitalmars-d wrote: […]
> 
> Unfortunately, for speech and language processing (synthesis, speech recognition etc) Python is too slow. Everybody uses Python at first, but the serious code that is later put into real world applications is usually written in C or C++. This is a fact. I know people who developed speech analysis frameworks in Python and are now thinking of rewriting it in C++ for commercial purposes.

I can believe it is believed to be true, but this is based on metrics for using only pure Python. I bet you can get good performance just with judicious profiling and use of Cython or better still Numba.

"Commercial reasons" may well include "we are not prepared to ship Python source code, so you will rewrite in C or C++ so we can ship a binary executable" and be nothing to do with performance. I have had this in the past.

> Python is good for protoyping, but if you need fast applications, it is usually C/C++ (or D).

If you just use pure Python yes. But no-one does. it is always mixed systems. Why rewrite the Python that is not performance critical in C, C ++, or D, there is no point.

-- 
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 Sat, 2015-03-14 at 17:24 +0000, Chris via Digitalmars-d wrote: […]
> 
> And by the way, the fast Python code is usually a module written in C or some Cython magic. So it's back to C again.

What is wrong with that. It is entirely reasonable for there to be C, C ++ or D components to a Python system. There is no law forbidding this mix.

And people are using Numba these days which uses LLVM and not C to create native code from Python. Using Numba avoids all the annotations that are needed for Cython.

-- 
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 Saturday, 14 March 2015 at 18:01:57 UTC, Russel Winder wrote:
> On Sat, 2015-03-14 at 17:22 +0000, Chris via Digitalmars-d wrote:
> […]
>> 
>> Unfortunately, for speech and language processing (synthesis, speech recognition etc) Python is too slow. Everybody uses Python at first, but the serious code that is later put into real world applications is usually written in C or C++. This is a fact. I know people who developed speech analysis frameworks in Python and are now thinking of rewriting it in C++ for commercial purposes.
>
> I can believe it is believed to be true, but this is based on metrics
> for using only pure Python. I bet you can get good performance just with
> judicious profiling and use of Cython or better still Numba.
>
> "Commercial reasons" may well include "we are not prepared to ship
> Python source code, so you will rewrite in C or C++ so we can ship a
> binary executable" and be nothing to do with performance. I have had
> this in the past.

This may be part of it. But I know that open source free software in this sector is also written in C/C++ or Java. I haven't seen a single system that was acceptable in Python. Sooner or later they all go back to C.

I just don't see the point in using Python only to rewrite performance critical parts in C/C++ or D. Why not start with D or C from scratch. Also, I know that this Cython and C module mixing becomes a mess very quickly which makes development tricky and deployment a pain in the a**. I believe that as soon as you have to mix languages like that, there is something wrong, and you begin to rely heavily on an infrastructure that helps you to keep track of the whole mess.

>
>> Python is good for protoyping, but if you need fast applications, it is usually C/C++ (or D).
>
> If you just use pure Python yes. But no-one does. it is always mixed
> systems. Why rewrite the Python that is not performance critical in C, C
> ++, or D, there is no point.

On Sat, 2015-03-14 at 10:11 -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 3/14/15 2:02 AM, Russel Winder via Digitalmars-d wrote:
> > On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> >> On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote:
> >>> The removal of shared memory multi-threading in favour of using processes and channels should never be underestimated as a Really Good Thing™ that other native code languages (*) have failed to do anything about. Thus Go wins, others lose.
> >>
> >> That's a marketing success as well. Go didn't "remove" shared memory multi-threading, it just unrecommends it. That's quite unremarkable from a programming language design standpoint, but as discussed that's not always crucial for success. -- Andrei
> >
> > I think you need to show a bit of Go code that uses threads to be able to back up that claim.
> 
> package main
> 
> type Data struct {
>      i int
> }
> 
> func func1(c chan *Data ) {
>      var t *Data;
>      t = <-c
>      println(t)
> }
> 
> func func2(c chan *Data ) {
>      var t *Data;
>      t = <-c
>      println(t)
> }
> 
> func main() {
>      c := make(chan *Data)
>      t := Data{10}
>      go func1(c)
>      c <- &t
>      go func2(c)
>      c <- &t
>      println(&t)
> }
> 
I see no threads in this code! :-)

But yes, it certainly shows you can create shared-memory "multi-threading" this way, but anyone actually doing it would be being very silly. Sending addresses down multiple channels is obvious here and definitely not the right thing to do unless the datum contains an embedded lock which is then used. cf. https://talks.golang.org/2012/10things.slide#3

It would be better if channels could only accept value types, and not reference types.

Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to mention JCSP and GPars.


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