I was worried about the programmer skill issue when ISS bought Network ICE. My
code was top-to-bottom radically asynchronous in a language (C) that wasn't
really built for asynchronous programming. The question was: when ISS took over
the code, could their programmers handle it? The answer was 'yes'. Once they
got over their initial discomfort (such as wanting to wrap everything in a C++
pure virtual interface class), they really got into it, and even made
improvements I hadn't considered. The basic issue is practice, practice,
practice. Once a programmer practices it, the paradigm becomes natural, and
debugging it isn't a problem.
Or, you can exploit the fact that is now a lot of stuff out there (e.g
"Stackless Python") that wraps the problem, giving you what appears to be a
synchronous interface on top, but is really asynchronous underneath. One good
example is the work Azul has put into their JVM for massively multicore x86
servers. It allows you to write what appear to be synchronous threads but which
are fully asynchronous underneath, providing massive scalability that would
otherwise take a hundred systems.
Azul is a good demonstration of a simple fact: we've largely solved the problem
of synchronous programming, now we are working on multi-core programming. In
the past, if you used a blocking socket or select(), you were doing it wrong.
Now, if you use a pthread_mutex(), you are doing it wrong. By "doing it wrong",
I mean "massive retraining of programmers to make them unlearn what they were
taught in college".
_______________________________________________
Dailydave mailing list
[email protected]
https://lists.immunityinc.com/mailman/listinfo/dailydave
