By physically heating a chip and causing random bit-flipping, a Princeton University student managed to get his attack code to run 70% of the time. Apparently, this would be a legitimate assault against smartcards and other “untamperable” computing apparati.
I think we should look at the problem the other way around. OO was a great paradigm for in-process, in-memory software development, but it really doesn’t map well to an enterprise (viz orchestrated, out-of-process, distributed) application….I think we should be looking at a transition to new implementation tools. And I think that, on the whole, that’s exactly what we *are* doing. Especially with things like the WS- standards, the appearance of loosely-typed languages again, etc.
Half-full or half-empty, Matthew agrees that there’s a tension between OOP (absolutely the dominant teaching paradigm) and enterprise-worthy design (absolutely the market direction). This is a big deal: software development does shift in the face of such tensions (OOP, strong typing, structured programming: all gained industry dominance not because of theory, but because of just such tensions between need and productivity). I can’t see how dynamic / loosely-typed languages are a step forward, as I think large dynamically typed systems are very hard to understand for anyone but the original writer (although second-generation test-driven frameworks like Fit would certanily help).
For those of us who are interested in programming languages as such, it’s a very interesting time. My gut tells me that something else is going to emerge, something more declarative, with implicit parallelism, and multi-representational (by which, I mean that source code can be represented in both visual and textual means. [Does this contradict my previous statement that UML As Programming Language is a bad idea? Very well then, I contradict myself — I contain multitudes.]).
For awhile, I thought Aspect-Oriented Programming was going to be a big deal, but it doesn’t seem to be taking hold. Then there’s Intentional Programming from Charles Simonyi and Gregor Kiczales (did anyone blog the demo at Software Development?). Personally, I think there’s huge potential in dataflow, but my theory is that programming paradigm shifts are contingency-driven, not theory-driven, so it’s a matter of something “catching fire.”
John Beimler writes "I’d like to wire in a Bayesian classifier too, and
see if that helps me get the items I like to the top [of my news
Yes. That’s a good idea.
"…I came up with three primary classifications for thinking about
the UML: UmlAsSketch <http://martinfowler.com/bliki/UmlAsSketch.html> ,
UmlAsBlueprint <http://martinfowler.com/bliki/UmlAsBlueprint.html> , and
<http://martinfowler.com/bliki/UmlAsProgrammingLanguage.html> ….one of the problems that I, and some others, are having with UML 2 is because there are many changes that have been introduced to increase its precision – changes that are primarily to make it more
suitable for UmlAsBlueprint and UmlAsProgrammingLanguage. But
these changes increase the bulk of the UML – and thus make it harder for
those of who prefer UmlAsSketch…." via [Martin Fowler’s Bliki
Martin’s right, but he’s being too polite. The only people who want UML to become a programming language are in the trade. In the real world, the only way that UML is accepted is as a sketch. Martin probably knows this better than anyone, as his book UML Distilled (http://www.amazon.com/exec/obidos/ASIN/0321193687/thinkinginnet-20) has deservedly sold roughly a bazillion more copies than the UML Reference Manual (http://www.amazon.com/exec/obidos/ASIN/020130998X/thinkinginnet-20)
“Here’s a question I pose to blogspace: Is the .NET Framework a platform or just better plumbing for the underlying platform?“ via [Harry Pierson’s DevHawk Weblog]
Although I think it makes sense to refer to it as “a platform” in most situations, in the context of this question, I definitely think it’s “just better plumbing.” One of the major things that strikes one moving to .NET from Java is how ridiculous it seems (in retrospect) to discourage access to the underlying platform, where a great deal of interesting innovation happens. It’s very, very easy to be dramatically wrong about the abstractions and evolution of a technology / algorithm in the early days: if, at the platform level, you sanctify an abstraction or specify a path for evolution too early, you may very well regret it someday. If you fret about never making such mistakes, you end up with bureaucratic nightmares like the JCP, where the slightest interesting innovation is stuck in committee for years.
“….I don’t want behavior in my entity objects – I want to put that into stateless control objects.…” via
[Harry Pierson’s DevHawk Weblog]
After double-checking to make sure Harry’s isn’t a J2EE blog, I’ve got to ask: Is this structure (stateless session / control objects, stateful entity objects without behavior) accepted by all as the universal route towards scalability? Because, if so, it points to an “object-scaling impedance mismatch” as real as the “object-relational impedance mismatch.” Objects are distinguished from other constructs by having state, behavior, and identity, and the only reason for having these characteristics is because associating all three is supposed to make programming easier. If enterprise programming requires stateless control things and behaviorless entity things, then the programming language should directly support those things and make it difficult to violate that structure. J2EE is a step towards that, but it’s layered on top of an object-oriented syntax, leading to confusion. If there is an “enterprise programming” paradigm, it should be refactored from OOP syntax, not simply “patched” on top.
If you’re a fan of test-driven development, you’re likely to be a fan of functional programming. One of the mindsets of test-driven development is that if something is hard to test, it may be an indication of poor design. The natural upshot is that in a test-driven system, objects tend to hold less state and methods tend to be fully described by the value of their input parameters and the value of their output.
Which might make F# the perfect test-case for something I’ve been thinking about for a long time, a test-driven language tutorial.