By: Maynard Handley (name99.delete@this.name99.org), July 13, 2015 7:18 pm
Room: Moderated Discussions
EduardoS (no.delete@this.spam.com) on July 13, 2015 4:48 pm wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on July 13, 2015 3:24 pm wrote:
> > Strict and easy is very good for high level languages.
>
> At such high levels languages if everything below is so f***ed up the language will only
> have to options: give that complexity to the programmer, which is against the "simple"
> or put barriers everywhere which will slow down things to unacceptable levels.
>
> Guess what, everybody opted for the first, so Linus is arguing in favor of a sane world where
> things happen in the order the programmer asked for, hardware makers f***ed up and shuffled
> the order completely compiler makers said: "since everything is already a mess we will not try
> to fix anything, instead we will f*** up a little more and give the problem to the programmer",
> so what you thing for high level languages is not going to happen, neither is for Linus, you
> kind of agree with him but you think this should be accomplished by impossible means.
>
I don't think this is at all a reasonable description of most programming. It's really only the case if you insist on working in a C-like language.
With more sophisticated languages
(a) the compiler can keep track of what state is stored where --- no raw pointers allowing for possible random writes from anywhere to anywhere
(b) the compiler has knowledge of what is and is not mutable (and the language encourages the use of immutable structures)
The end result is that
- there is not that much state that NEEDS to be protected between possible threads (because most is immutable)
- that which does need to be protected can be protected automatically by the compiler because it knows who is writing when
Coupled with the fact that in these languages people aren't writing their own cross-thread queues and MP-safe hashtables and suchlike --- they assume the language gives them that already, and the most explicit multi-threaded thing they ever do is to dump a block/lambda/anonymous function into some MP-queue.
And the higher up you go the less it's an issue. Just write a large map/reduce in your favorite functional language and you assume the system will do the right thing (worst case you might have to throw in a "parallel" keyword).
> dmcq (dmcq.delete@this.fano.co.uk) on July 13, 2015 3:24 pm wrote:
> > Strict and easy is very good for high level languages.
>
> At such high levels languages if everything below is so f***ed up the language will only
> have to options: give that complexity to the programmer, which is against the "simple"
> or put barriers everywhere which will slow down things to unacceptable levels.
>
> Guess what, everybody opted for the first, so Linus is arguing in favor of a sane world where
> things happen in the order the programmer asked for, hardware makers f***ed up and shuffled
> the order completely compiler makers said: "since everything is already a mess we will not try
> to fix anything, instead we will f*** up a little more and give the problem to the programmer",
> so what you thing for high level languages is not going to happen, neither is for Linus, you
> kind of agree with him but you think this should be accomplished by impossible means.
>
I don't think this is at all a reasonable description of most programming. It's really only the case if you insist on working in a C-like language.
With more sophisticated languages
(a) the compiler can keep track of what state is stored where --- no raw pointers allowing for possible random writes from anywhere to anywhere
(b) the compiler has knowledge of what is and is not mutable (and the language encourages the use of immutable structures)
The end result is that
- there is not that much state that NEEDS to be protected between possible threads (because most is immutable)
- that which does need to be protected can be protected automatically by the compiler because it knows who is writing when
Coupled with the fact that in these languages people aren't writing their own cross-thread queues and MP-safe hashtables and suchlike --- they assume the language gives them that already, and the most explicit multi-threaded thing they ever do is to dump a block/lambda/anonymous function into some MP-queue.
And the higher up you go the less it's an issue. Just write a large map/reduce in your favorite functional language and you assume the system will do the right thing (worst case you might have to throw in a "parallel" keyword).
