On Saturday, 28 March 2015 at 20:35:07 UTC, Walter Bright wrote:
> On 3/27/2015 12:34 PM, w0rp wrote:
>> Sean Parent's advice for "no raw loops" comes to mind.
>> https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule,
>> basically a one-line body for foreach becomes acceptable.
>
> This really is a great video. Which leads me to wonder why std.algorithm doesn't have a 'rotate'.

Three iterator algorithms don't really work well with ranges. We have bringToFront instead,  which is more general.

http://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront

On 3/28/2015 2:01 PM, Peter Alexander wrote:
> On Saturday, 28 March 2015 at 20:35:07 UTC, Walter Bright wrote:
>> On 3/27/2015 12:34 PM, w0rp wrote:
>>> Sean Parent's advice for "no raw loops" comes to mind.
>>> https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule,
>>> basically a one-line body for foreach becomes acceptable.
>>
>> This really is a great video. Which leads me to wonder why std.algorithm
>> doesn't have a 'rotate'.
>
> Three iterator algorithms don't really work well with ranges. We have
> bringToFront instead,  which is more general.
>
> http://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront

Thank you. I need to learn std.algorithm better.

Am 28.03.2015 um 21:51 schrieb Walter Bright:
> On 3/28/2015 1:32 PM, Sönke Ludwig wrote:
>> I/O is crucial of course, but there are also a lot of other important and
>> inherently impure things such as message passing.
>
> If the message channel is passed as a parameter to the droutine, then
> the droutine can still be pure.

Only if the methods of the channel are also pure. But they potentially have to interact with the system event loop, which involves impure system API calls.

>> I think such a restriction
>> would go way too far. Both fiber and task local storage can also be
>> very useful
>> at times, so it would be a pity to rule them out completely.
>>
>> You'd also usually have the whole application running on "droutines"
>> and not
>> simply use them as a local tool for occasional parallelism needs. This is
>> especially true for any kind of server application. So effectively such a
>> limitation may in practice end up as a limitation of the entire language.
>
> On the other hand, if purity can make droutines much more practical, the
> tradeoff might be worth it.

If you ask me, they are very practical as they are - in fact much more practical than if they could move between threads, not just because of purity or not. I'm for example heavily using vibe.d's tasks for all kinds of UI, 3D graphics, sound and physics related things. All of these require calling various C libraries that are not be compatible with such a scheme.

We could of course add an optional pure+moving mode for those that absolutely need it, but IMHO we should first have hard evidence for practical performance improvements before going such a route.

On 3/28/2015 3:24 PM, Sönke Ludwig wrote:
> If you ask me, they are very practical as they are - in fact much more practical
> than if they could move between threads, not just because of purity or not. I'm
> for example heavily using vibe.d's tasks for all kinds of UI, 3D graphics, sound
> and physics related things. All of these require calling various C libraries
> that are not be compatible with such a scheme.
>
> We could of course add an optional pure+moving mode for those that absolutely
> need it, but IMHO we should first have hard evidence for practical performance
> improvements before going such a route.

Sounds very sensible. When can we get it into Phobos? :-)

On Sat, 28 Mar 2015 19:17:23 +0000, Russel Winder via Digitalmars-d-announce wrote:

> It is a pity that D is not pitching as a Python replacement.

D can't: it doesn't dumb enough to attract people that requires compiler enforcements on whitespace to correctly format their code.

On Sat, 28 Mar 2015 18:39:34 +0000, Russel Winder via Digitalmars-d-announce wrote:

>> yet current CPUs are still the same as 50 years before, that is the problem. ;-)
> 
> I'd suggest that a Intel x86_64 of 2015 bears only a passing relationship to an IBM 360 of the 1960s.

but core principles are still there. it's implementation that is changed, not high-level design.

> With all the transistors available per mm² these days, it is about time
> we investigated alternate, implicitly parallel ways of working.
> Intel had a go a few years ago with various alternative dataflow based
> architectures, but they were told by the software people that they had
> no future because software inertia was more important than innovation.

yes. "computers" are huge industry now, and industry resists to innovations that requires industry players to change their processes.

on the other side of the spectrum was Chuck Moore, for example, who imagines modern computers filled with many cheap and average RISC processors, and using parallel multiprocessor execution to achieve great performance.

and people with expirience on 8-bit Atari, NES or C64 knows by their hearts that having specialized processors can greatly help (and it's a great PITA too ;-).

On Sat, 28 Mar 2015 18:41:04 +0000, weaselcat wrote:

> On Saturday, 28 March 2015 at 17:57:35 UTC, ketmar wrote:
>> On Sat, 28 Mar 2015 14:28:00 +0000, Russel Winder via Digitalmars-d-announce wrote:
>>
>>> It could be argued that it is all just co-routines underneath,
>>> but I think that would be missing the point that we have 55 years more
>>> experience of doing these things since that single processor operating
>>> system model was created. We really should be doing this all a lot
>>> better these days.
>>
>> yet current CPUs are still the same as 50 years before, that is the problem. ;-)
> 
> heavily disagree

it's still good old "me dumb computer bip bip" with all that low-level register crap and so on. it doesn't matter how much advanced current designs are in their cores, 'cause we -- as users -- see the same old bip- bip shit.

On Sunday, 29 March 2015 at 00:24:36 UTC, ketmar wrote:
> On Sat, 28 Mar 2015 19:17:23 +0000, Russel Winder via
> Digitalmars-d-announce wrote:
>
>> It is a pity that D is not pitching as a Python replacement.
>
> D can't: it doesn't dumb enough to attract people that requires compiler
> enforcements on whitespace to correctly format their code.

Urr.... As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently.

On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^"

Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it).

UFCS FTW!

On Sun, 29 Mar 2015 02:15:38 +0000, cym13 wrote:

> On Sunday, 29 March 2015 at 00:24:36 UTC, ketmar wrote:
>> On Sat, 28 Mar 2015 19:17:23 +0000, Russel Winder via Digitalmars-d-announce wrote:
>>
>>> It is a pity that D is not pitching as a Python replacement.
>>
>> D can't: it doesn't dumb enough to attract people that requires compiler enforcements on whitespace to correctly format their code.
> 
> Urr.... As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently.

it was a joke... at least it was almost a joke.

On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
> On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
>> Personally, I'm not sure that much is gained in pitting Go against D
>> precisely because they're so different that they're likely to appeal to
>> completely different sets of people.
>
> I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.

How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code")