On 3/26/2015 7:06 PM, weaselcat wrote:
> vibe has (experimental?) green threads, doesn't it?
> I don't keep up with vibe, so I may be wrong.

I don't know, but if it does have good 'uns they should be moved into Phobos!

On 3/26/2015 8:53 PM, Laeeth Isharc wrote:
> It's also the view of Feynman, not to mention many great minds of the past.  Ie
> it is limiting to insist on data before forming a strong opinion about something
> (which is not to say that one may not change one's mind in the face of contrary
> data).

Feynman's books are all worth reading, even if you have no interest in physics. His attitude about things is just a marvel.

I once had a roundtable discussion with the question "if you could resurrect any historical figure, who would it be?" I nominated Feynman, and that pretty much ended the discussion :-) nobody could think of anyone more appropriate.

So yeah, I definitely take inspiration from him.

On Friday, 27 March 2015 at 04:35:17 UTC, Walter Bright wrote:
> On 3/26/2015 8:53 PM, Laeeth Isharc wrote:
>> It's also the view of Feynman, not to mention many great minds of the past.  Ie
>> it is limiting to insist on data before forming a strong opinion about something
>> (which is not to say that one may not change one's mind in the face of contrary
>> data).
>
> Feynman's books are all worth reading, even if you have no interest in physics. His attitude about things is just a marvel.
>
> I once had a roundtable discussion with the question "if you could resurrect any historical figure, who would it be?" I nominated Feynman, and that pretty much ended the discussion :-) nobody could think of anyone more appropriate.
>
> So yeah, I definitely take inspiration from him.

Richard P. Feynman
“Well, Mr. Frankel, who started this program, began to suffer from the computer disease that anybody who works with computers now knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is you *play* with them. They are so wonderful. You have these switches - if it's an even number you do this, if it's an odd number you do that - and pretty soon you can do more and more elaborate things if you are clever enough, on one machine.

After a while the whole system broke down. Frankel wasn't paying any attention; he wasn't supervising anybody. The system was going very, very slowly - while he was sitting in a room figuring out how to make one tabulator automatically print arc-tangent X, and then it would start and it would print columns and then bitsi, bitsi, bitsi, and calculate the arc-tangent automatically by integrating as it went along and make a whole table in one operation.

Absolutely useless. We *had* tables of arc-tangents. But if you've ever worked with computers, you understand the disease - the *delight* in being able to see how much you can do. But he got the disease for the first time, the poor fellow who invented the thing.”


― Richard P. Feynman, Surely You're Joking, Mr. Feynman!: Adventures of a Curious Character
tags: computers, humor, programming

;)

On Friday, 27 March 2015 at 01:47:57 UTC, Walter Bright wrote:
> The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it.

Go can move stacks and extend them.
Go is closer to having a low latency GC.

These are not small language issues for D.

On Friday, 27 March 2015 at 04:05:30 UTC, Laeeth Isharc wrote:
> Programming is - for now - still a human activity, and what is important in human activities may not always be measured, and what may be easily measured is not always important.  That doesn't mean one should throw away the profiler and go back to guessing, but it does suggest caution about adopting the prestigious techniques of the natural sciences and applying them to a domain where they don't necessarily fully belong.

What is almost always important is:

1. to be able to ship the product in a predictable fashion

2. not go 300-400% over budget

3. being able to train new people to maintain it in reasonable time

4. being able to add new unexpected features to the code base on request

Perl is a very expressive and productive language. And you can write maintainable software in it if you have discipline. In the real world Perl tends to lead to an unmaintainable mess with the average programmer.

On 3/26/2015 11:40 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Go can move stacks and extend them.

That has no value on 64 bit systems, and is not a language issue (it's an implementation issue).


> Go is closer to having a low latency GC.

I.e. it doesn't have one.


> These are not small language issues for D.

GC issues are library issues, not language issues.

On Friday, 27 March 2015 at 06:53:01 UTC, Walter Bright wrote:
> On 3/26/2015 11:40 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> Go can move stacks and extend them.
>
> That has no value on 64 bit systems,

It has.

> and is not a language issue (it's an implementation issue).

It is if you cannot control references to the stack.

>> Go is closer to having a low latency GC.
>
> I.e. it doesn't have one.

Comes in Go 1.5.

https://docs.google.com/document/d/1wmjrocXIWTr1JxU-3EQBI6BK6KgtiFArkG47XK73xIQ/preview?sle=true

>> These are not small language issues for D.
>
> GC issues are library issues, not language issues.

It is a language issue if you want it to perform well.

On 3/27/2015 12:37 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 27 March 2015 at 06:53:01 UTC, Walter Bright wrote:
>> On 3/26/2015 11:40 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> Go can move stacks and extend them.
>>
>> That has no value on 64 bit systems,
>
> It has.

The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. The MMU can map and remap that to physical memory on demand through the address translation tables.

Moving stacks is a great solution for 1995 computers.

On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote:
> The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack.

If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages.

http://wiki.osdev.org/Page_Tables

On Friday, 27 March 2015 at 08:41:40 UTC, Ola Fosheim Grøstad wrote:
> tables? If you want to address more than 512GB you need to move to 1MiB pages.

Actually, it is 2MiB.

Also keep in mind that there is an advantage to having very small stacks (e.g. 1-2K) when you do simulations.