threading

[Rustom Mody]

On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody:
> 
> > What you are saying is that what the OS is doing, you can do better.
> > Analogous to said C programmer saying that what (data structures) the
> > python programmer can make he can do better.
> 
> 
> 
> I'm sorry, but I don't quite follow you there.

Ok let me try again (Please note I am speaking more analogically than logically)

There was a time -- say 1990 -- when there was this choice
 - use C -- a production language with half-assed data structures support
 - use Lisp -- strong support for data structures but otherwise unrealistic

>From this world and its world view its natural to conclude that to choose 
a strong data structure supporting language is to choose an unrealistic language

I was in the thick of this debate then
http://www.the-magus.in/Publications/chor.pdf

This argument is seen to be fallacious once we have languages like python
(and Ruby and Java and Perl and Haskell and ...)

Today we are in the same position vis-a-vis concurrency as we were with 
data structures in 1990.

We have mainstream languages -- Java,C,C++,Python -- with half-assed 
concurrency support. And we have languages like Erlang, Go, Cloud Haskell which 
make concurrency center-stage but are otherwise lacking and unrealistic.

I disagree with you in saying "We cant do better (than stay within the options
offered by mainstream languages"

As an individual you are probably right.
>From a larger systemic pov (hopefully!) not!

I disagree with Sturla in what is considered invariant and what is under one's control.

He (seems?) to take hardware as under control, programming paradigm as not.
I believe that the mileage that can be achieved by working on both is more than
can be achieved by either alone.


> I see the regular multithreaded approach as
>  (2) inviting race conditions carelessly--no mortal is immune.

This I understand and concur with

> 
>  (1) oversimplification which makes it difficult to extend the design
>      and handle all of the real-world contingencies

This I dont...