On 20 Jun., 17:28, Stefan Behnel <stefan...@behnel.de> wrote: > Kay Schluehr wrote: > >> You might want to read about "The Problem with Threads": > > >>http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > >> and then decide to switch to an appropriate concurrency model for your use > >> case. > > > and to a programming language that supports it. > > Maybe, yes. But many different concurrency models are supported by a larger > number of programming languages in one way or another, so the choice of an > appropriate library is often sufficient - and usually a lot easier than > using the 'most appropriate' programming language. Matter of available > skills, mostly. There's usually a lot less code to be written that deals > with concurrency than code that implements what the person paying you makes > money with, so learning a new library may be worth it, while learning a new > language may not. > > Stefan
This implies that people stay defensive concerning concurrency ( like me right now ) and do not embrace it like e.g. Erlang does. Sometimes there is a radical change in the way we design applications and a language is the appropriate medium to express it succinctly. Concurrency is one example, writing GUIs and event driven programs in a declarative style ( Flex, WPF, JavaFX ) is another one. In particular the latter group shows that new skills are adopted rather quickly. I don't see that a concurrency oriented language has really peaked though yet. -- http://mail.python.org/mailman/listinfo/python-list
