This is great. His Edison language is an interesting early exercise in building the minimal language with good support for concurrency. Prior to this dump there much information about Edison online but now you can get the full write-ups and code:
Thank you.
I am Danish, into coding, and living sort of just down the road from the quondam HQ of Regnecentralen where PBH worked, and yet I barely knew about the man, and much less his writings.
Also, everybody, do check out the entire site. Or sites, rather - there are subdomains, and the author present them as seperate constructs. Troves of stuff. Homepages like we used to know them before the world went bonkers.
Great resource. Thank you. From his "Design of Edison" book:
"programming languages cannot be expected to support complex abstractions, but should instead make it reasonably convenient to adopt programming styles which use simpler concepts to construct the more complex ones"
This was in the context of demonstrating Edison's ability to express both safe and unsafe concurrency (pp. 16-17).
I'm really amazed to see this here - I was his student back in the 1980s when he was a professor at Syracuse University. I implemented the virtual machine for his language Joyce which a hybrid of Tony Hoare's CSP with a Pascal syntax. Great times!
Also I was his teaching assistant for the course based on this book for a few semesters.
“The author examines the synchronization features of Java and finds that they are insecure variants of his earliest ideas in parallel programming published in 1972–73. The claim that Java supports monitors is shown to be false. The author concludes that Java ignores the last twenty-five years of research in parallel programming languages."
I'd like to start with saying that I love such titles (both writing myself and reading others'). I also to check up such claims, so opened up that PDF.
First of all, it's not "book", but a short article (10 pages). Then another quote from it:
> In this paper I examine the synchronization features of Java to discover their origin and determine if they live up to the standards set by the invention of monitors and Concurrent Pascal a quarter of a century ago.
So, the claim being made that Java doesn't support Concurrent Pascal's "monitors". And Captain Obvious agrees, because Java support's Java's monitors, d'uh. Though author puts that as if he owned a trademark for the word "monitor". Maybe he did.
Then he complains that Java allows to write not just fully decoupled threads, but those which share state too. He argues that there should be synchro police hand-holding everyone and not letting them shoot themselves in the feet. He's also apparently oblivious of all of the lock-free paradigm, because well, his Concurrent Pascal's "monitor" is panacea for all the times and uses. So oops, Java adopted a free-will approach instead.
He concludes with the following:
> The 1980s will probably be remembered as the decade in which programmers took a gigantic step backwards by switching from secure Pascal-like languages to insecure C-like languages.
> "In our conversation she talks about what that transition was like as well as why it is important to increase the diversity in the field and how C has grievously wounded the study of computer science."
I very much feel for those gals and guys. I may imagine the outrage that generation felt about C could be compared to that which our generation, rurban, feels about JavaScript.
I believe all his notable scientific works were in English. You can find some minor articles in Danish, e.g. this announcement of the RC4000 in an engineering periodical: https://datamuseum.dk/w/images/d/da/Rc4000d.pdf
Only you can answer questions of relevancy wrt your topics of interest. Think about this for a second: relevancy for 'today' yields such a broad area that, I dare say, no one here or elsewhere will have a satisfying answer _for you_.
Relevant to Systems Programming Languages today, or even modern operating systems. Sorry my English is bad but basically are these books about general principles that don't get outdated.
Ah, I would say that, to some extent they are of historical, as opposed to practical, value. That is, if you just wanted to implement an OS using modern best practices then these works might not be as relevant as other, much more recent works.
However, many of the fundamental themes, principles, and considerations are unchanged in the intervening years, and often clearer in earlier, simpler systems. And you can find forgotten gems.
http://pascal.hansotten.com/per-brinch-hansen/edison-a-multi...