Slate UI

[Waldemar Kornewald]

> > Good, then, I think porting Cairo is the best solution (the BeAPI is 
> > vector-like, so that should not be too complicated), but I will wait 
> > until everything is in-place (maybe someone else is faster ;).
> 
> If everyone kept waiting, nothing would happen.

I just do not want to do more than I have to. There are better things to work on. ;)

> >> However, until Slate has proper concurrency support and that is tied 
> >> in
> >> to the I/O framework, a multithreaded UI and Slate will not interact
> >> very beneficially.
> >
> > At #slate you mentioned that Slate will not allow for easy parallel 
> > computation. Why? :)
> 
> Well, it's pretty obvious, or should be - any language based on 
> procedures / side-effects is going to require some kind of restrictions 
> in order to be simple to reason about in parallel. The languages that 
> excel at parallel / concurrent work are those where side-effects are 
> really local by default.

Okay, thank you. This is a problem if you want a programming language that automatically makes everything paralellizable. I thought of explicitly using an API. Can a human not be more efficient in choosing the right parallelization than today's programming languages? I cannot imagine our stupid languages doing intelligent task distribution.

Bye,
Waldemar