First, the story has been already discussed on technocrat.net day's ago (well, with 5 comments or so not really "discussed" as such:))
Second, I have to run to have lunch now and then boys... I'm eager to wrestle over my master's subject with the whole/. crowde... Oh, the sanity:)
Anyway, more to the point: it's not really AI, man. (At least nowadays.) Just some wonderfully pure math represented in (the most cases) painfully obfuscated, say, ML code >:\ (oh functionals, how I love thee... let me count the ways... uhm... zero? Ahemm.)
All of what you said is true, but that's only the "workhorse" aspect of using DB2.
On the other hand, one should not forget that all members (ok, all known by me) of the whole IBM software offering jungle are ready to be used with DB2 as relational DBMS backing (if such thing is needed). Taking Tivoli, for example: it's DB2 ready out of the box (if you want Oracle... Well, how about some config script decyphering in a temp directory instead of the nice n' shiny config GUI?).
Well, the same company, so it's not so astonishing:); the point is, if you build your whole software infrastructure from IBM products, integration effort (= cost) will be minimal. And they do have the software palette to make you happy:) And in the case when not, they have vendor-specific integration solutions for the big players. Surely you need a big organization for the IBM-only way to pay off, but hey, the Big Blue nowadays does not care about your next door nerd. Money is in the corporational full-coverage service sector (heh... no, I'm not an IBM sales rep, just a wannabe:)), let the chinese manufacture those cheapo PC-s.
Yep, exactly the same thing came to my mind when I saw the parent:) Nevertheless I would like to cite a more formal definition, too:
An Open System is a system consisting of cooperating a) SW b) HW and c) people, which
- serves the desired service,
- its interface specifications are 1) fully and well defined, 2) publicly accessible and 3) maintained on ground of common agreement and
- its implementation conforms the specification.
Now, because this thingy above has been translated by me, speaker of a tiny little language from that tiny little language into English, there's a defintion by the glorious DoD, too, which is actually in proper English (all citations taken from course material in my mother tongue, so sorry, no links):
"A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered components to be utilized across a wide range of systems with minimal changes, to interoperate with other components on local and remote systems, and to interact with users in a style that facilitates portability."
You all know what Open Source is about - as it can be seen Open Systems is a very different (in terms of actual software used in the system surely overlapping) area. Buzzwords like Enterprise Application Integration (EAI), ebXML, the Web Services and WS-* mess have all strong roots in this initiative (well, better philosophy, or even better natural need) pushed by tiny companies as the Big Blue itself (or herself? Ehh, a proper language has explicit genders for nouns:))
Anyway, one more comment. There are comments about about DCE being a dead technology and opening it up too late. Let's name the market leader distributed object technology (as the technology most fitting producing middle-sized, complicated, semi-loosely coupled systems) - it's DCOM. (If anybody mentions Java RMI... please, just don't mention it, I'm fed up with that.) CORBA is dead, as... dead. (insert obligatory comment about asbesthos suit here) The other integration middleware environments are for other design cases. DCOM is built on DCE. So it is still nice to see this move.
As I am no Economist as such this is only my sincere opinion deduced from personal belief and experience, but the idea of governemnts taking their hands off international acquisitions is at least scary for me.
See, a government operates for the bigger benefit of the people by whom it has been elected (in theory, at least). Big US Company buys out French company possibly to eliminate competition - jobs, national pride, and the sum value produced by the nation are hurt. Intervention by state on many-many levels of the economy has a loooong history - in that case, it protects against negative foreign influence.
Now I appreciate the idea of free trade - on a microeconomical level It Just Works. But when it's about uneven odds (Microsoft trying to take over my garage company, for example:)) or foreign influence, we elected the government to step right in and say "no".
You know Lee Iacocca, the topmanager? He wrote a nice book about his life in the 80's (?). He has a rather interesting rant about exactly that problem - in his time, the US government did not protect the american auto industry from japanese cars while the japanese did this with ridiculous import taxes. All of this because "free trade".
So yes, there are cases when I'm happy that the government intervenes - God knows that it should do it more frequently in my country (which is not the US, mind you). As it is now the Germans own our collective as... backwards parts. But that's our trouble, certainly:)
Funny. I actually have real-world experience, four years of which was at Rational
Yep, that's the field where I can't compete. Actually I think that Rose (the newer versions, too) is terribly far from the holy grail of an easy-to-use, consistent code/model generating environment, but it's still the most mature "solution" on the market (uhm, too much IBM propaganda material digested, sorry about that).
See, I should have made clear that the parts about "not knowing what it is" was not specifically about you while it is true that it could be interpreted that way. (After rereading my post that part was at least rude - I beg your pardon.) It's more sort of a pavlovian trigger for me - I study at a university where the unit-diameter student, although not capable to pass most of the more theoretical courses (algorithm theory, data security and suchlike) for the first go, regularly makes fun of those who respect and try to work with more formal methods. And my treshold on UML-bashing has been way far exceeded by this/. conversation.
Now, about fleshing out my system to the smallest details two things come to my mind. First, there are possible cases where I have to flesh out my system to the smallest details. Again, I don't have work experience, but the techniques and tools I saw in my embedded & real time systems course actually work (UML or not - the main thing is modeling and formal analysis) and in that field one has some serious constraints on the system to be developed. So serious, that it is actually worth to use formal modeling and checking that model.
Second, finding the correct level of abstraction is certainly always desirable. We actually have evaluated this issue for the quantitative performance analysis of applications and found that hence modeling to the level where execution times can be computed from the model may be sometimes possible it is simply a brain dead idea (and there are still serious projects on that issue... well. They know. I don't want to do it.) But if we model to the desired level of granularity, automatically generate instrumented code skeleton (and yes, you don't morph your code to the level where the model becomes out of sync), measure under some workload and backannotate the results to the model you can do some pretty analysis on the UML model. Just a usage of UML, where we avoid the "fleshing out" of the system and still get useful results.
Uhm... the third of those two things. Nowadays the tooling for general purpose UML-based development is somewhat childish compared to what the possibilities of a model based approach are (still, I think XDE is a great tool - but it could be so much better. Personally what I can't stand and comes from Rational is the Rational Unified Process. But that's a whole different issue.) For general purpose systems model templating (design patterns) and generating more and more code from that model can really speed up development (as I am a wet behind the ears rookie this is only my extrapolation from my experiences with code generation tools).
You need to change the design every time you turn around, and wrestling with updating diagrams and round-trip modeling/coding tools is madenningly tedious and slow Let me tell you something Sir, as long you haven't worked with Tivoli you don't know anything about wrestling...:)
Anyway, I go back to configure that 10g instance I have here instead of pointless UML-advocacy at 2:56AM. Your sarcasm was well deserved, thanks for the reply and practitioners point of view.
And what if you use only 10% of it's "capacity" and only in "sketch mode"? My point is, people are ranting here in the style "boo, only the kindergarten-level part of that bloated piece of evil smelling stuff is of any use" while missing the point that UML as a spec is only a set of visual modeling languages - which diagrams you use, in what phases of development with what sort of tooling depends on many factors. (For example to use more "advanced" modeling techniques provided by UML - hierarchical statecharts z.B. - you need people who actually comprehend what you can achieve with UML in your given problem domain with your tooling. Code monkey + 1 week UML course of God knows what quality + MSPaint.exe is definitely not the way to go in an UML-based dev process.)
The "out of date doc" question: round trip engineering. See Rational XDE. (OK, you will need a Cray on that one:(, but that babe has some serious code and model generating capabilites. And I don't work for IBM.)
I am certainly biased as I am still a student (no RL experience) and we use UML from a somewhat special point of view - annotating and and analyzing for nonfunctional properties of a system - but having reevaluted my stance with UML for many times (killer -> crap -> useful in high ceremony, big scale development only -> see, I can compute actually meaningful stuff on that diagram -> with model transformation and code generation you become simply more productive than with hand programming) I must say that those who now discard UML as it is will have big, manga-style eyes when the code hand-written by them now will be automatically generated from formal models with the help of model transformation repositories in ten years. Note that small scale and truly low level programming is safe from that.
Anyway, sorry for the rant. As I said, I am biased, have too much free time (lookie, I post on/.!:)), can't speak proper English (not a native speaker), I am from academia and fed up with People Bashing UML Without Knowing What It Really Is.
Slashdot Mirror
First, the story has been already discussed on technocrat.net day's ago (well, with 5 comments or so not really "discussed" as such :))
Second, I have to run to have lunch now and then boys... I'm eager to wrestle over my master's subject with the whole /. crowde... Oh, the sanity :)
Anyway, more to the point: it's not really AI, man. (At least nowadays.) Just some wonderfully pure math represented in (the most cases) painfully obfuscated, say, ML code >:\ (oh functionals, how I love thee... let me count the ways... uhm... zero? Ahemm.)
On the other hand, one should not forget that all members (ok, all known by me) of the whole IBM software offering jungle are ready to be used with DB2 as relational DBMS backing (if such thing is needed). Taking Tivoli, for example: it's DB2 ready out of the box (if you want Oracle... Well, how about some config script decyphering in a temp directory instead of the nice n' shiny config GUI?).
Well, the same company, so it's not so astonishing :); the point is, if you build your whole software infrastructure from IBM products, integration effort (= cost) will be minimal. And they do have the software palette to make you happy :) And in the case when not, they have vendor-specific integration solutions for the big players. Surely you need a big organization for the IBM-only way to pay off, but hey, the Big Blue nowadays does not care about your next door nerd. Money is in the corporational full-coverage service sector (heh... no, I'm not an IBM sales rep, just a wannabe :)), let the chinese manufacture those cheapo PC-s.
Yep, exactly the same thing came to my mind when I saw the parent :) Nevertheless I would like to cite a more formal definition, too:
An Open System is a system consisting of cooperating a) SW b) HW and c) people, which
- serves the desired service,
- its interface specifications are 1) fully and well defined, 2) publicly accessible and 3) maintained on ground of common agreement and
- its implementation conforms the specification.
Now, because this thingy above has been translated by me, speaker of a tiny little language from that tiny little language into English, there's a defintion by the glorious DoD, too, which is actually in proper English (all citations taken from course material in my mother tongue, so sorry, no links):
"A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered components to be utilized across a wide range of systems with minimal changes, to interoperate with other components on local and remote systems, and to interact with users in a style that facilitates portability."
You all know what Open Source is about - as it can be seen Open Systems is a very different (in terms of actual software used in the system surely overlapping) area. Buzzwords like Enterprise Application Integration (EAI), ebXML, the Web Services and WS-* mess have all strong roots in this initiative (well, better philosophy, or even better natural need) pushed by tiny companies as the Big Blue itself (or herself? Ehh, a proper language has explicit genders for nouns :))
Anyway, one more comment. There are comments about about DCE being a dead technology and opening it up too late. Let's name the market leader distributed object technology (as the technology most fitting producing middle-sized, complicated, semi-loosely coupled systems) - it's DCOM. (If anybody mentions Java RMI... please, just don't mention it, I'm fed up with that.) CORBA is dead, as... dead. (insert obligatory comment about asbesthos suit here) The other integration middleware environments are for other design cases. DCOM is built on DCE. So it is still nice to see this move.
See, a government operates for the bigger benefit of the people by whom it has been elected (in theory, at least). Big US Company buys out French company possibly to eliminate competition - jobs, national pride, and the sum value produced by the nation are hurt. Intervention by state on many-many levels of the economy has a loooong history - in that case, it protects against negative foreign influence.
Now I appreciate the idea of free trade - on a microeconomical level It Just Works. But when it's about uneven odds (Microsoft trying to take over my garage company, for example :)) or foreign influence, we elected the government to step right in and say "no".
You know Lee Iacocca, the topmanager? He wrote a nice book about his life in the 80's (?). He has a rather interesting rant about exactly that problem - in his time, the US government did not protect the american auto industry from japanese cars while the japanese did this with ridiculous import taxes. All of this because "free trade".
So yes, there are cases when I'm happy that the government intervenes - God knows that it should do it more frequently in my country (which is not the US, mind you). As it is now the Germans own our collective as... backwards parts. But that's our trouble, certainly :)
Anyway, this was only my opinion.
Yep, that's the field where I can't compete. Actually I think that Rose (the newer versions, too) is terribly far from the holy grail of an easy-to-use, consistent code/model generating environment, but it's still the most mature "solution" on the market (uhm, too much IBM propaganda material digested, sorry about that).
See, I should have made clear that the parts about "not knowing what it is" was not specifically about you while it is true that it could be interpreted that way. (After rereading my post that part was at least rude - I beg your pardon.) It's more sort of a pavlovian trigger for me - I study at a university where the unit-diameter student, although not capable to pass most of the more theoretical courses (algorithm theory, data security and suchlike) for the first go, regularly makes fun of those who respect and try to work with more formal methods. And my treshold on UML-bashing has been way far exceeded by this /. conversation.
Now, about fleshing out my system to the smallest details two things come to my mind. First, there are possible cases where I have to flesh out my system to the smallest details. Again, I don't have work experience, but the techniques and tools I saw in my embedded & real time systems course actually work (UML or not - the main thing is modeling and formal analysis) and in that field one has some serious constraints on the system to be developed. So serious, that it is actually worth to use formal modeling and checking that model.
Second, finding the correct level of abstraction is certainly always desirable. We actually have evaluated this issue for the quantitative performance analysis of applications and found that hence modeling to the level where execution times can be computed from the model may be sometimes possible it is simply a brain dead idea (and there are still serious projects on that issue... well. They know. I don't want to do it.) But if we model to the desired level of granularity, automatically generate instrumented code skeleton (and yes, you don't morph your code to the level where the model becomes out of sync), measure under some workload and backannotate the results to the model you can do some pretty analysis on the UML model. Just a usage of UML, where we avoid the "fleshing out" of the system and still get useful results.
Uhm... the third of those two things. Nowadays the tooling for general purpose UML-based development is somewhat childish compared to what the possibilities of a model based approach are (still, I think XDE is a great tool - but it could be so much better. Personally what I can't stand and comes from Rational is the Rational Unified Process. But that's a whole different issue.) For general purpose systems model templating (design patterns) and generating more and more code from that model can really speed up development (as I am a wet behind the ears rookie this is only my extrapolation from my experiences with code generation tools).
You need to change the design every time you turn around, and wrestling with updating diagrams and round-trip modeling/coding tools is madenningly tedious and slow Let me tell you something Sir, as long you haven't worked with Tivoli you don't know anything about wrestling... :)
Anyway, I go back to configure that 10g instance I have here instead of pointless UML-advocacy at 2:56AM. Your sarcasm was well deserved, thanks for the reply and practitioners point of view.
And what if you use only 10% of it's "capacity" and only in "sketch mode"? My point is, people are ranting here in the style "boo, only the kindergarten-level part of that bloated piece of evil smelling stuff is of any use" while missing the point that UML as a spec is only a set of visual modeling languages - which diagrams you use, in what phases of development with what sort of tooling depends on many factors. (For example to use more "advanced" modeling techniques provided by UML - hierarchical statecharts z.B. - you need people who actually comprehend what you can achieve with UML in your given problem domain with your tooling. Code monkey + 1 week UML course of God knows what quality + MSPaint.exe is definitely not the way to go in an UML-based dev process.) The "out of date doc" question: round trip engineering. See Rational XDE. (OK, you will need a Cray on that one :(, but that babe has some serious code and model generating capabilites. And I don't work for IBM.)
I am certainly biased as I am still a student (no RL experience) and we use UML from a somewhat special point of view - annotating and and analyzing for nonfunctional properties of a system - but having reevaluted my stance with UML for many times (killer -> crap -> useful in high ceremony, big scale development only -> see, I can compute actually meaningful stuff on that diagram -> with model transformation and code generation you become simply more productive than with hand programming) I must say that those who now discard UML as it is will have big, manga-style eyes when the code hand-written by them now will be automatically generated from formal models with the help of model transformation repositories in ten years. Note that small scale and truly low level programming is safe from that.
Anyway, sorry for the rant. As I said, I am biased, have too much free time (lookie, I post on /.! :)), can't speak proper English (not a native speaker), I am from academia and fed up with People Bashing UML Without Knowing What It Really Is.