On Sat, 2015-03-14 at 18:11 +0000, Chris via Digitalmars-d wrote: […]
> 
> 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.

Java will have the same problem as Python regarding shipping source to anyone who knowns how to decompile Java.

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

I would reject C as a language of implementation for everything except small operating systems – which includes many embedded things, most being effectively operating systems. I can see people using C++, but it would be better if they used D, but I doubt this will happen :-(

Mixing Python, Cython, and C does require standard compiled project management, but is no worse than pure C, C++ or D systems. I would suggest that the "messiness" is due to the Python people not doing the Cython and C properly, and the C people objecting to having Python involved. It usually comes down to the people and not the technology.

-- 
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 3/14/2015 2:26 AM, Russel Winder via Digitalmars-d wrote:
> On Fri, 2015-03-13 at 00:22 -0700, Walter Bright via Digitalmars-d
> wrote:
>> On 3/12/2015 11:57 PM, Russel Winder via Digitalmars-d wrote:
>>> How about lining up some features for removal.
>>
>> Easier said than done. I've proposed a couple things for removal, but got a lot
>> of pushback. Some things have been successfully removed:
>
> Pushback can be ignored, and indeed should in some cases.

Not ignored. But sometimes I do override others' judgement in the interest of doing what I believe is best. Somebody has to make decisions on controversial issues.

(I had proposed removing the 'lazy' storage class.)

>> . octal literals
> C should be incinerated for the 0777 abomination. At least 0o777 can
> work reasonably.

Even better:

    octal!0777

The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals.


>> . builtin complex numbers
> Electronics folk love these. Many people use Python exactly for this
> type.

Complex numbers are still available, but as a library type, which is not inferior to the (former) builtin type.


>> Has any language been successful at abandoning their user base (i.e. existing
>> code)? Going from D1 to D2 nearly destroyed D. I'm not eager to try that again.
> The war is being played out in the Python 2/3 arena certainly.
> Interestingly though there are fewer and fewer Python 2 hold outs. Their
> holding out has made Python 3 change a little, and for the better in my
> view – even though I refuse to write any Python 2 specific code.

It's a good example. Didn't Perl 6 go through a paroxysm, too? But not so successfully.

On 3/14/2015 2:12 AM, Russel Winder via Digitalmars-d wrote:
> On Fri, 2015-03-13 at 20:12 -0700, Andrei Alexandrescu via Digitalmars-d
> wrote:
>> I'm surprised Russel fell for it. -- Andrei
> Fell for what?

The mark of a successful long con! :-)

On 3/14/15 11:24 AM, Russel Winder via Digitalmars-d wrote:
> But yes, it certainly shows you can create shared-memory
> "multi-threading" this way,

So your affirmation has been refuted.

> but anyone actually doing it would be being
> very silly.

That's "design by prayer". Aren't most bugs created by people doing very silly things?

> Sending addresses down multiple channels

One is enough.

> 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

Yes, of course it's not the right thing to do. Your point being...?

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

Probably not as that would further hamstrung the language.


Andrei

On Saturday, 14 March 2015 at 11:51:54 UTC, Russel Winder wrote:
> On Sat, 2015-03-14 at 09:44 +0000, deadalnix via Digitalmars-d wrote:
> […]
>> No, that is the classical "prove that god do not exist" trick. This is up to Go to prove it is safe. Hint: it isn't.
>
> This could go on ad nauseam. It is up to C, C++, D, Rust, Fortran, Java,
> Python, Ruby, etc., etc. to prove they are safe. Hint: they aren't. The
> closest there is is Spark Ada, and that has problems.

When it come to concurrency, Rust is. None of the other are.

Now you can double down on trying to make me prove a negative, but that only makes you sound like a religious zealot.

On Saturday, 14 March 2015 at 18:24:51 UTC, Russel Winder wrote:
> 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
>

So now we are going from Go is safe, to well, it is obviously not safe (then, why were you so eager to have a proof ?) but nobody in their right mind would do something like this.

But this is only a short snippet. This can happen the same way in a million line codebase, and good luck finding it.

Also, the "no good programmer would do this" is an immediate red flag. Not only programmer will do this, but the one that claim they won't will do it even sooner as they evidently lack self awareness.

On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
> The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals.
>

It makes it sounds like you don't know the spec about string literals.

On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
> The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals.


user defined literals can be quite ugly where sugar is expected(i.e, Tuples)

On 3/14/2015 3:19 PM, deadalnix wrote:
> On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
>> The point is, with a library abstraction the core language can be simplified.
>> D's ability to create user defined literals largely ends the pressure to make
>> more complicated and specialized core language literals.
> It makes it sounds like you don't know the spec about string literals.

I know I don't know what you're driving at :-)

On Saturday, 14 March 2015 at 18:33:24 UTC, Russel Winder wrote:
> On Sat, 2015-03-14 at 18:11 +0000, Chris via Digitalmars-d wrote:
> […]
>> 
>> 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.
>
> Java will have the same problem as Python regarding shipping source to
> anyone who knowns how to decompile Java.
>
>> 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.
>
> I would reject C as a language of implementation for everything except
> small operating systems – which includes many embedded things, most
> being effectively operating systems. I can see people using C++, but it
> would be better if they used D, but I doubt this will happen :-(
>
> Mixing Python, Cython, and C does require standard compiled project
> management, but is no worse than pure C, C++ or D systems. I would
> suggest that the "messiness" is due to the Python people not doing the
> Cython and C properly, and the C people objecting to having Python
> involved. It usually comes down to the people and not the technology.

But why do they keep inventing new technologies and compilation methods for Python when it's already soooo good? Every year I hear "now Python is fast", "now you can write fast and efficient code in Python", and more often than not it is some C-based stuff, some additional layer of complexity.

Try to integrate Python into third party software or some OS framework, and you'll begin to hate it. The question of which version of Python to use is enough to put you off. Some programs are delivered with their own Python version to avoid problems. All this is messy, not clean. I've seen it, and I've done it. I prefer D that gives me native efficiency and can interface with C. No Cython magic needed.