I've been developing concurrent
systems for several years now, and I
have a pretty good grasp on the
subject despite my lack of formal
training (i.e. no degree).
Many of best programmers I know didn't finish the University.
As for me I studied Philosophy.
C/C++, C#, Java, etc.). In particular,
it can be near impossible to recreate
conditions that happen readily on one
system in your development
environment.
yes
How do you figure out what can be made concurrent vs. what has to be
sequential?
we usually start with a 1000 miles high metaphor to clarify our architecture to ourselves (firstly) and to others (secondly).
When we faced that problem, we always found a way to limiting the visibility of concurrent objects to non concurrent ones.
Lately I discovered Actors in scala and I saw that my old solutions were a kind of "miniactors", much less powerful than scala ones. So my suggestion is to start from there.
Another suggestion is to skip as many problems as possible: for example we use centralised cache (terracotta) instead of keeping maps in memory, using inner class callbacks instead of synchronised methods, sending messages instead of writing shared memory etc.
With scala it's all much easier anyway.
How do you reproduce error conditions and view what is happening
as the application executes?
No real answer here. We have some unit test for concurrency and we have a load test suite to stress the application as much as we can.
How do you visualize the interactions between the different
concurrent parts of the application?
Again no real answer: we design our Metaphor on the whiteboard and we try to make sure there are no conflicts on the architectural side.
For Arch here I mean the Neal Ford's definition: Sw Architecture is everything that will be very hard to change later.
programming leads me to believe you
need a different mindset than you do
with sequential programming.
Maybe but for me it's simply impossible to think in a parallel way, so better design our software in a way that doesn't require parallel thinking and with clear guardrails to avoid crashes between concurrency lanes.
Do people still use Ada -- (it was mostly used in the Defense Department)
It appears that Ada was last updated in 2005 and there's work toward an Ada 2012, so the language itself is still alive and kicking.
As far as use, Ada isn't mandated for use in the Department of Defense anymore. Most of the work that I've seen and done has been in Java, C, and C++, but there's also use of the .NET framework and I've even heard of projects running other JVM languages such as Scala, depending on how the system will be used. There's probably a lot of code out there in Ada, so I wouldn't be surprised if there's a lot of code reuse and maintenance happening. Given the nature of defense projects, it's hard to come up with specific numbers as to its use.
There is a list of Ada projects and users, but it looks like the last update was in June 2008. There might be more recent lists out there, but I couldn't quickly find any.
Are all applications written in Ada "Legacy"?
If you're asking if there is new Ada development, I wouldn't be surprised if new systems are being written from the ground up in Ada. I would suspect there would be too many, but there are probably some out there. However, I would suspect that most of the Ada work out there is maintenance or upgrades on existing systems, not new development.
Does Ada knowledge still sell
Knowledge in anything sells, if you can find someone who is looking for that skill set. Even if you aren't using Ada in development, I've found that knowing a particular language or framework has changed my opinion and how I use other languages or frameworks. I would suspect that knowing Ada would give you an insight into other methods to design and construct software in other languages as well.
Best Answer
The Ada rendezvous concept is based on the CSP rendezvous, so reading up on CSP may be a worthwhile.
An Ada rendezvous appears to provide more than a CSP rendezvous, so what you really lose out on is the ability to easily reason formally about the behaviour.
Incidentally, at university we were actually taught CSP using Occam syntax, since we had been taught Occam in our first year. We were also taught the Z notation along with Miranda (a functional language which was the precursor to Haskell).
Together, these provided a solid grounding in formal reasoning for software systems, both distributed and non-distributed.