Software Engineering discussion
date
newest »
newest »
I wasn't aware of the C# versus Java issues, but I'm not too surprised. I understand Java a lot better after figuring out C#. Similarly, I understand the previous chapter on Java more after reading this C# chapter.After reading this, I think about the .Net framework as something similar to the JVM. Brad made a comment about the JVM being the thing that survives, and that makes perfect sense. The .Net framework appears to have more long term value than C#.
It was nice to see some comments about LINQ. The more I learn about LINQ the more amazing it sounds.
I think I don't understand the concurrency issues that keep getting mentioned. The .Net framework has amazing interposes communication features that make previously difficult implementation trivial. I would guess they are discussing far more complicated concurrency issues than simple IPC or DBMS issues.
In .NET terminology, the equivalent of the JVM is the Common Language Runtime. In Java terminology, the equivalent of .NET is J2EE (roughly).
The problem with the concurrency discussion in this book is that there are many different meanings and levels, and they are intermixed. For example, you could have very coarse-grained concurrency and run separate programs on separate machines in a distributed system. Or, you could run separate programs in separate processes in the same machine (mapping processes to cores). Or, in a finer-grained manner, you could run separate threads in separate cores.
The coarse-grained concurrency is "easy" with frameworks like .NET and J2EE. The fine-grained concurrency, with shared resources like memory-based variables in the face of multi-threading, is hard... and it is this aspect of concurrency where the language issues are most relevant.
As processor speed plateaus, and the use of multiple cores accelerates, language choice for fine-grained concurrency becomes a hotter topic. This is a main reason for the current interest in Haskell (and other functional languages).
The problem with the concurrency discussion in this book is that there are many different meanings and levels, and they are intermixed. For example, you could have very coarse-grained concurrency and run separate programs on separate machines in a distributed system. Or, you could run separate programs in separate processes in the same machine (mapping processes to cores). Or, in a finer-grained manner, you could run separate threads in separate cores.
The coarse-grained concurrency is "easy" with frameworks like .NET and J2EE. The fine-grained concurrency, with shared resources like memory-based variables in the face of multi-threading, is hard... and it is this aspect of concurrency where the language issues are most relevant.
As processor speed plateaus, and the use of multiple cores accelerates, language choice for fine-grained concurrency becomes a hotter topic. This is a main reason for the current interest in Haskell (and other functional languages).
As someone who doesn't really understand the full scope of the concurrency problems, I would have thought to first look at DBMS and declarative languages for concurrency solutions. If you need to build concurrency in to a language, then you take control away from the developer similar to declarative languages.A Java-Monitor seems like a declarative language idea, right? Would making all objects a Monitor be a solution? Although, I'm sure there are much better solutions. I'm guessing the full scope of concurrency is greater than just that too.
You are right... if a DBMS can solve your concurrency needs and the only shared data resides in the DBMS, you can rely on the ACID properties it provides.
Java provides decent support for concurrency via the synchronized method modifier (which I think is the same as the monitor you are describing). But, as a programmer, you have to know that i=i+1; is not atomic, for example, to know when to use synchronized. If you overuse it, you limit the concurrency. And, there are cases of livelock, deadlock, lock ordering, and exception handling even if you do use it that can make this really hard to get right. In languages less powerful than Java's concurrency model, there is even more opportunity to screw up.
Doing concurrency in Haskell, especially combined with a concept called Software Transactional Memory, greatly eases the programmer burden.
One great reference for all of this is the chapter "Beautiful Concurrency" in the book "Beautiful Code".
Java provides decent support for concurrency via the synchronized method modifier (which I think is the same as the monitor you are describing). But, as a programmer, you have to know that i=i+1; is not atomic, for example, to know when to use synchronized. If you overuse it, you limit the concurrency. And, there are cases of livelock, deadlock, lock ordering, and exception handling even if you do use it that can make this really hard to get right. In languages less powerful than Java's concurrency model, there is even more opportunity to screw up.
Doing concurrency in Haskell, especially combined with a concept called Software Transactional Memory, greatly eases the programmer burden.
One great reference for all of this is the chapter "Beautiful Concurrency" in the book "Beautiful Code".
My Javaphile attitude has kept me from exploring C# in depth. I am still miffed at Microsoft having taken Java... tweaking it so that they could avoid being dependent on Sun. Who ever said language choice was rational? It would be interesting to see a current comparison of C# and Java to see how close they are now.
I did enjoy reading Anders' perspectives and agree with much of what he had to say... noting the repeating themes of functional languages, concurrency, and language/framework bloat.