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 like Python for lots of things, but it is crap for some, hence Java/Groovy/Scala/Kotlin/Ceylon/Clojure for JVM-based work and C++/D/Rust/Go/Chapel for native-based work.

PyD needs more support from the D community!

-- 
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 Tuesday, 13 January 2015 at 09:58:56 UTC, bearophile wrote:
> Take a look at the ideas of "C++ seasoning" (http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning ), where they suggest to do kind of the opposite of what you do, it means throwing out loops and other things, and replacing them with standard algorithms.

Yes... you can do that. For little gain since C++'s support for high level programming is bloat inducing. Just take a look of all the symbols you need to have a conforming iterator or allocator... An allocator should be a simple 5 line snippet, it is bloatsome in STL:

https://gist.github.com/donny-dont/1471329

Then I needed a circular buffer. STL didn't have one. So I downloaded the Boost one. It was terribly inefficient, because it was generic and STLish.

I ended up writing my own using a fixed size log2 array with a start and end index. Clean conditional-free efficient code due to the log2 property and modular arithmetics.

So, in the end I get something faster, that produce more readable code, give faster compiles, is easier to read, is easier to debug and was implemented in less time than finding and figuring out the Boost one...

I have no problem with using array<T> and vector<T> where it fits, but in the end templated libraries prevent transparency. If you want speed you need to understand layout. Concrete implementations make that easier.

>> A solution like list comprehensions is a lot easier on the programmer, if convenience is the goal.
>
> There's still time to add lazy and eager sequence comprehensions (or even better the computational thinghies of F#) to D, but past suggestions were not welcomed. D has lot of features, adding more and more has costs.
>
>
>> Phobos "ranges" need a next_simd() to be efficient. Right?
>
> Perhaps, but first std.simd needs to be finished.

Right, but you need to support masked simd if you want to do filtering. Maybe autovectorization is the only path.

Still, you also need to keep your loops tiny if you want to benefit from X86 loop buffer. The CPU is capable of unrolling tight loops in hardware before hitting the execution pipeline. Thus getting the conditionals out of the pipeline.

Then you have cache locality. You need to break up long loops so you don't push things out of the caches.

So, if you can gain 2x by good cache locality/prefetching and 4x by using AVX over scalars, then you gain 8x performance over a naive implementation. That hurts.

On Mon, 2015-01-12 at 11:32 -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 1/12/15 11:30 AM, Russel Winder via Digitalmars-d wrote:
> > 
> > On Mon, 2015-01-12 at 10:43 -0800, H. S. Teoh via Digitalmars-d wrote:
> > > 
> > […]
> > > And what exactly should operator[] return if a key wasn't found?
> > > 
> > […]
> > 
> > Go has an interesting solution, key lookup in a map return a pair (result, ok), if lookup succeeded then result is the associated value, if ok is false then result is undefined. I quite like this.
> 
> How can you like undefined? That's a terrible solution again
> underlining
> Go's conflation of union and product types. -- Andrei

They may be fiddling with type systems, but I was wrong about undefined: if the key is not found then lookup returns the zero value for the value type. Given this is useless to me, I think in terms of it being undefined, which is technically wrong, but good for my code.
-- 
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 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 like Python for lots of things, but it is crap for some, hence
> Java/Groovy/Scala/Kotlin/Ceylon/Clojure for JVM-based work and
> C++/D/Rust/Go/Chapel for native-based work.
>
> PyD needs more support from the D community!

I've just seen that PyD has moved to github[1] and has had a considerable cleanup of documentation. Hooray :)   Now if only we had shared library support on OS X then I could actually use it....

[1] https://github.com/ariovistus/pyd

On Mon, 2015-01-12 at 12:58 -0800, Walter Bright via Digitalmars-d wrote:
> On 1/12/2015 11:30 AM, Russel Winder via Digitalmars-d wrote:
> > Go has an interesting solution, key lookup in a map return a pair (result, ok), if lookup succeeded then result is the associated value, if ok is false then result is undefined. I quite like this.
> 
> 
> That's just putting the responsibility of array bounds checking on the caller.
> 
> Would you want (result, ok) returned every time you indexed an
> array? I sure
> wouldn't. An associative array isn't conceptually any different.

Why not?

There is a fundamentally different approach to error handling depending on whether exceptions are integral cf. Python or anathema cf. Go and most functional programming languages. It is unreasonable to impose the idioms of one model onto another. And vice versa.

arrays, sparse arrays and associative arrays are both very different and quite similar. The properties of the keys makes for very different approaches to algorithms, and possibly error handling of key lookup: contiguity of keys of an array is important.

-- 
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 Mon, 2015-01-12 at 12:52 -0800, Walter Bright via Digitalmars-d wrote:
> […]
> 
> If code is throwing exceptions as part of its normal operation, it
> is designed
> wrong.
> 

OK so I know you hate Python, but…

> And yes, if you take that as a challenge to try and concoct a
> counterexample,
> the point still stands :-)

Python.

-- 
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 06:50 +0000, Tobias Müller via Digitalmars-d wrote:
> 
[…]
> The problem with exceptions is, that the *callee* has to decide, not the caller.

Callee always has the responsibility, it is just a question of whether or how callee may propagate the problem back up the chain.

-- 
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 10:58 +0000, John Colvin via Digitalmars-d wrote:
> 
[…]
> I've just seen that PyD has moved to github[1] and has had a considerable cleanup of documentation. Hooray :)   Now if only we had shared library support on OS X then I could actually use it....

The standard Go development team response to the "we must have dynamic library support in Go" is "you do not need it, use operating system processes and pipes". For operating systems that support many small processes, this is a most viable solution. UNIX and Linux are supposed to be such. Of course it helps that Go is channel and dataflow focused, so it is just a variation of the standard model.

Conversely CPython (and now by necessity PyPy, but not Jython or IronPython since it is irrelevant for them) trivially supports C and C++ for extensions. If D is to compete in this milieu, it is essentially to support C linkage dynamic linking on all platforms. I'm on Linux, it works for me :-) On the other hand if it doesn't work on Windows and OSX then perhaps it is broken?

> [1] https://github.com/ariovistus/pyd
-- 
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 Tuesday, 13 January 2015 at 11:23:27 UTC, Russel Winder via Digitalmars-d wrote:
>
> On Tue, 2015-01-13 at 10:58 +0000, John Colvin via Digitalmars-d wrote:
>> 
> […]
>> I've just seen that PyD has moved to github[1] and has had a considerable cleanup of documentation. Hooray :)   Now if only we had shared library support on OS X then I could actually use
>> it....
>
> The standard Go development team response to the "we must have dynamic
> library support in Go" is "you do not need it, use operating system
> processes and pipes". For operating systems that support many small
> processes, this is a most viable solution. UNIX and Linux are supposed
> to be such. Of course it helps that Go is channel and dataflow
> focused, so it is just a variation of the standard model.
>

Which doesn't scale in software that requires plugins.

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

--
Paulo

On Monday, 12 January 2015 at 19:32:22 UTC, Andrei Alexandrescu wrote:
> On 1/12/15 11:30 AM, Russel Winder via Digitalmars-d wrote:
>>
>> On Mon, 2015-01-12 at 10:43 -0800, H. S. Teoh via Digitalmars-d wrote:
>>>
>> […]
>>> And what exactly should operator[] return if a key wasn't found?
>>>
>> […]
>>
>> Go has an interesting solution, key lookup in a map return a pair
>> (result, ok), if lookup succeeded then result is the associated value,
>> if ok is false then result is undefined. I quite like this.
>
> How can you like undefined? That's a terrible solution again underlining Go's conflation of union and product types. -- Andrei

They posted recently a blog post about error handling in Go.

https://blog.golang.org/errors-are-values

--
Paulo