On Tuesday, 13 January 2015 at 10:51:33 UTC, Russel Winder via Digitalmars-d wrote:
>
> On Mon, 2015-01-12 at 13:04 -0800, Walter Bright via Digitalmars-d wrote:
>> On 1/12/2015 11:27 AM, Russel Winder via Digitalmars-d wrote:
>> > Unless you are writing Python code.
>> 
>> 
>> Nobody would be in this forum if we preferred Python :-)
>
> Why does one have to "prefer" a language to the exclusion of all
> others (unless one is the author of a language ;-)

I have found that Python quite nicely can replace perl, php, bash, awk and sed... What's not to like about this swiss army knife that can get rid of all that junk?

> I like Python for lots of things, but it is crap for some, hence
> Java/Groovy/Scala/Kotlin/Ceylon/Clojure for JVM-based work and

I have almost no experience with these, why so many? What do they bring to the table versus one another?

> PyD needs more support from the D community!

I'd consider using Python with D if the memory model was integrated. Not a bad idea, actually, but would take some real work.

On Tuesday, 13 January 2015 at 12:14:07 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 13 January 2015 at 10:51:33 UTC, Russel Winder via Digitalmars-d wrote:
>>
>> On Mon, 2015-01-12 at 13:04 -0800, Walter Bright via Digitalmars-d wrote:
>>> On 1/12/2015 11:27 AM, Russel Winder via Digitalmars-d wrote:
>>> > Unless you are writing Python code.
>>> 
>>> 
>>> Nobody would be in this forum if we preferred Python :-)
>>
>> Why does one have to "prefer" a language to the exclusion of all
>> others (unless one is the author of a language ;-)
>
> I have found that Python quite nicely can replace perl, php, bash, awk and sed... What's not to like about this swiss army knife that can get rid of all that junk?
>

As long as it is only used for scripting nothing.

But when people remember to use it for writing applications, then it is just plain slow and I don't see PyPy fixing that.

There is a reason why Go is getting Ruby and Python developers.

--
Paulo

On Tuesday, 13 January 2015 at 12:53:15 UTC, Paulo  Pinto wrote:
> As long as it is only used for scripting nothing.
>
> But when people remember to use it for writing applications, then it is just plain slow and I don't see PyPy fixing that.

But you don't need everything in an application to be fast, so you can tie components together with scripting. Python is essentially built up around having reasonably fast components that are plugged together. But I expect that Python will be displaced with something that can compile efficiently to javascript.

One should keep in mind that  javascript is plenty fast for UI-bindings. It is the C++ part of browsers (layout engine) that is the slowest part today, IMO. When WebCL becomes available in browsers you probably could do the majority of applications in the browser. That is kinda scary.

So the utility of compiled languages is shrinking fast. A language that makes it easy to connect building blocks and also can be used on both a server and in a webclient (compilable to javascript) will probably win in the long run.

> There is a reason why Go is getting Ruby and Python developers.

Sure, Go is useful for web related infrastructure, has static typing, provides decent concurrency and latency and is more "lightweight" than JVM. Good all round qualities.

On Monday, 12 January 2015 at 19:27:34 UTC, Russel Winder via Digitalmars-d wrote:
>
> On Mon, 2015-01-12 at 09:54 -0800, H. S. Teoh via Digitalmars-d wrote:
>> 
> […]
>> Yeah, exceptions are supposed to be ... well, *exceptions*, rather than the norm. :-) If you're using exceptions to do flow control, you're doing something wrong.
>> 
> […]
>
> Unless you are writing Python code.

You are doing Python a disservice here. Their use of exceptions for control flow statements is an implementation detail, introduced because Python exceptions are fast. (In the C runtime a Python exception is a global variable and functions that return 0;. ) The whole argument stands on its head.

The discussion of good Python coding style and Python's usefulness might be found elsewhere.

On Tuesday, 13 January 2015 at 13:28:04 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 13 January 2015 at 12:53:15 UTC, Paulo  Pinto wrote:
>> As long as it is only used for scripting nothing.
>>
>> But when people remember to use it for writing applications, then it is just plain slow and I don't see PyPy fixing that.
>
> But you don't need everything in an application to be fast, so you can tie components together with scripting. Python is essentially built up around having reasonably fast components that are plugged together. But I expect that Python will be displaced with something that can compile efficiently to javascript.
>
> One should keep in mind that  javascript is plenty fast for UI-bindings. It is the C++ part of browsers (layout engine) that is the slowest part today, IMO. When WebCL becomes available in browsers you probably could do the majority of applications in the browser. That is kinda scary.
>
> So the utility of compiled languages is shrinking fast. A language that makes it easy to connect building blocks and also can be used on both a server and in a webclient (compilable to javascript) will probably win in the long run.
>
>> There is a reason why Go is getting Ruby and Python developers.
>
> Sure, Go is useful for web related infrastructure, has static typing, provides decent concurrency and latency and is more "lightweight" than JVM. Good all round qualities.

Sure, but JavaScript enjoys some of the best JIT compilers for dynamic languages, whereas Python has a JIT compiler that still is catching up with the current language version, doesn't support most of the extensions and is ignored by the CPython developers.

If PyPy becomes the official implementation, then I will change my mind.

Please note I used Python a lot while at CERN, so I do know the eco-system.


--
Paulo

On Tue, 2015-01-13 at 11:50 +0000, Paulo Pinto via Digitalmars-d wrote: […]
> Which doesn't scale in software that requires plugins.

Probably true.

> Imagine Eclipse, for example, implemented as a collection of processes.

Imagine Eclipse actually working… ;-)

-- 
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 Tue, 2015-01-13 at 13:29 +0000, via Digitalmars-d wrote: […]
> You are doing Python a disservice here. Their use of exceptions for control flow statements is an implementation detail, introduced because Python exceptions are fast. (In the C runtime a Python exception is a global variable and functions that return 0;. ) The whole argument stands on its head.

I think you miss my point. The thread appeared to be assuming the use of exception handling was a boolean, whereas it is a scale. The cost of raising and handling an exception compared to the cost of a function call is a critical metric. Thus C++ exception handling is at one scale, Python at a totally different one, with Java somewhere between. The cost determines the idioms. Because exceptions are so cheap in Python it can be used for implementation detail, and is.

I assume D sits with C++ rather than Java, so exception handling is for termination semantics, not error handling. Certainly not for control flow as with Python.

Go does have exceptions, there is one and it terminates execution.

-- 
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 Monday, 12 January 2015 at 20:07:17 UTC, deadalnix wrote:
> On Sunday, 11 January 2015 at 13:06:27 UTC, Dicebot wrote:
>> What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.
>
> Rust has an approach very similar to exception, but they do not unwind and trash the whole task instead. Under the hood, it is exception, but tend to be faster as you don't go through the landing pad/personality function dance, but do not fundamentally differ.

I think it does unwind (i.e. call destructors), but the exception cannot be called and ultimately will lead to task failure. At least this was the case some time ago, maybe it has changed?

On Monday, 12 January 2015 at 23:01:53 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 12 January 2015 at 22:06:32 UTC, deadalnix wrote:
>> No, Exception are a bail out mechanism. It is the, I have no idea what to do about this mechanism.
>
> The way it is done in C++, yes.
>
>> If you put aside performance concerns, exceptions for control flow also tend to make many code path implicit and makes for very unreadable/unmaintainable code.
>
> But exceptions are control flow. There is no such thing as normalized control flow, all state changes implies "control flow". Think in terms of a state machine. You could just remove all variables and only have a big state machine (assuming finite dimensions). Every single state transition implies flow of control.
>
> The control flow you see in the source code is just the programmer's "rendition" of control flow. Exceptions is a mechanism for getting cluttering resolution out of that rendition to make the code more readable and maintainable. The goal is to retain the meat of the computation and remove the noise.
>
> Or to put it differently, there are many ways to write the same function. Good use of exceptions removes the clutter and leaves the things you care about visible. It's a mechanism, not a moral issue or a religion.
>
> So there is nothing wrong with throwing HTTPStatus(409) or HTTPStatus(201), even though it returns state to the environment. If that means the code is more maintainable and more likely to be correct, then that is good use of the mechanism.

I usually don't do this, but I really need to post a "+1" here:

+1

On Tuesday, 13 January 2015 at 00:05:31 UTC, Walter Bright wrote:
> On 1/12/2015 3:17 PM, deadalnix wrote:
>> On Monday, 12 January 2015 at 22:17:57 UTC, Walter Bright wrote:
>>> Yes, it does. Returning an int in EAX now becomes returning a pair [EAX,EDX].
>>
>> It is not that big of a deal, EDX is a trash register anyway if memory serve,
>> but then, it become very bad when it do not fit in register anymore.
>
> Returning a slice, for example, already consumes EAX and EDX. Adding an error code pushes that into returning via a pointer to a stack temporary.
>

There are techniques to mitigate that. For example, Rust is smart enough to encode the "not-present" state for pointers as a NULL pointer (Rust pointers are non-null).

If an error code needs to be returned, it can be encoded as a misaligned pointer (if you're feeling adventurous). Don't know whether Rust does the latter, though.

Of course, these things have costs of their own.