Today I picked my copy of Beautiful Code after a long time. And the chapter I picked for the day- Beautiful Concurrency - this chapter basically tries to walk you through the pit falls of concurrent programing and goes on to introduce Haskel and concept of Software Transactional Memories. Really powerful concept I would recommend a read to this if you are involved in serious concurrent programming - don't worry if do not have access to the book, its available on simonpj's site at MS research -.
While reading through it, my brain tuned to think in terms of C and machine language started to think how this might be implemented. As if there is concurrency and shared resource involved some kind of locking has to be used and all this is trying to suggest it make locks implicit and not exposed to programmers - Aren't us programmers have bad rep in screwing up anything remotely complex - a good thought anyhow, this led me to think then why not implement it as a framework in C or C++ and hide the locks from programmers. Very much possible and as mentioned in the paper can be achieved to a degree.
So the question why we need to a new language to achieve this?
And the answer I think goes like this any framework provided assumes that every one programs to its interfaces and do not try to bypass it. Also as with any framework programmers need to learn it and resist the temptation to use quick "safe" shortcut using the underlying language flexibility or feature - We programmers are lazy too - . At this point things start going southward, as the shortcut we assumed "safe" may not be safe or most probably will not remain safe in future. To solve this problem we try to introduce coding guidelines, but I have yet to come across a big project which follows all the guidelines religiously.So we solve this problem by inventing a new language learning that can be roughly equivalent to learning a new framework but syntax and construct of focused language might be able to ensure that using "safe" shortcuts are extremely hard if not impossible, and going back to the confession that programmers are lazy we will not spend time breaking the system hard way - unless of course we are hacking to have fun :)
While reading through it, my brain tuned to think in terms of C and machine language started to think how this might be implemented. As if there is concurrency and shared resource involved some kind of locking has to be used and all this is trying to suggest it make locks implicit and not exposed to programmers - Aren't us programmers have bad rep in screwing up anything remotely complex - a good thought anyhow, this led me to think then why not implement it as a framework in C or C++ and hide the locks from programmers. Very much possible and as mentioned in the paper can be achieved to a degree.
So the question why we need to a new language to achieve this?
And the answer I think goes like this any framework provided assumes that every one programs to its interfaces and do not try to bypass it. Also as with any framework programmers need to learn it and resist the temptation to use quick "safe" shortcut using the underlying language flexibility or feature - We programmers are lazy too - . At this point things start going southward, as the shortcut we assumed "safe" may not be safe or most probably will not remain safe in future. To solve this problem we try to introduce coding guidelines, but I have yet to come across a big project which follows all the guidelines religiously.So we solve this problem by inventing a new language learning that can be roughly equivalent to learning a new framework but syntax and construct of focused language might be able to ensure that using "safe" shortcuts are extremely hard if not impossible, and going back to the confession that programmers are lazy we will not spend time breaking the system hard way - unless of course we are hacking to have fun :)
