> I�m not complaining that new tools are bad. I�m gust telling that I�d prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus,

But it was never like that.
The old browser is just worse code but the logic is the same.

> tools for traits instead of slots
I do not understand what you mean because this is totally orthogonal.

> etc� I�m not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools.

Yes but not only :)
You see in PHP and perl they use them too.

> The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it.

Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations)
� � � � � � � � and a flexible way to build tool and not spaghetti code, this is why we invested in Spec.
So

> Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it.

LOL
We are doing infrastructure work since years. Just open your eyes to realise it.

� � � � FileSystem,
� � � � OPAL (imagine a new compiler)
� � � � New DebuggerModel,
� � � � Announcement,
� � � � AtomicQueue,
� � � � Cleaning morphic,
� � � � Spec,
� � � � Zinc
� � � � Better handling of rectangle
� � � � Better handling of layoutFrame
� � � � Better
� � � � better
� � � � better

� � � � Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building
� � � � a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest.

> Although you have more experience so maybe it�s better the way it is.
>
> uko
>
>>
>>
>>>>> Yes, This is a nice idea, but I was telling about the other thing. It�s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process.
>>>>
>>>>
>>>> forking processes is not a solution. because you can have shared resources problems and updates and �.
>>>
>>> Yes, you risk races which could be tricky to find/debug.
>>>
>>> I'm **very** interested what's the solution you propose here?
>>>
>>> Jan
>>>
>>>>
>>>>> So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial.
>>>>>
>>>>> Uko
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>