"Modern" Software Framework?
in [OOP]
|
Prev: Design by Contract vs Law of Demeter : Preconditions
Next: New England Patriot jerseys for men,worldwide express, paypal payment
From: kjin101 on 23 Aug 2007 14:10 ap...(a)student.open.ac.uk wrote: > On 18 Aug, 03:37, "Phlip" <phlip...(a)yahoo.com> wrote: > > CORBA's main problem is it grew under a broken "request for proposals" > > model. The stakeholding committees chartered their proposal system to > > discourage and inhibit reference implementations for new feature requests. > > This simple but horrific mistake allowed client companies to compete with > > each other by submitting elaborate requests, allowing the CORBA > > specification to clutter up with endless cruft. > > > I predict that CORBA as we know it will not last another few years, and that > > something else will take its spot. Maybe a simplified version of the > > ACE-TAO-CIAO framework(s). > > I agree that CORBA is the worst example of committee-itus that the > world has ever seen. The C++ language binding is horrific and IMO will > never ever be fixed. But the binding for java is ok and I think CORBA > works quite well with java. Also despite the poor language bindings in > other languages the fact that there are other language binding makes > CORBA a good way to interface to legacy systems (with java on the > frontend of course). IMO. So I think its got a good for several years > yet. > The C++ binding is out-of-date but not that horrific and is an insignificant reason in CORBA's failure (or fall). Even if CORBA had a perfect C++ binding, it would still as miserable as it today. The major technique problem of CORBA is not its some how out-of-date language mappings, not the data aligment in CDR encoding, not the unnatural OBV, the chatty OTS, the braindead AMI, FT, etc. etc., but the lack of a simple, light while still superb component assembly, deployment and configure model/framework that canceals complexities in building CORBA server, and/or publish/subscribe (either event/ notification or data distributation), secured, and/or transactional (as well as persistent, fault tolerant, etc.) applications. Regards, Ke
From: Alexei Polkhanov on 23 Aug 2007 16:27 On Aug 22, 7:38 pm, "Phlip" <phlip...(a)yahoo.com> wrote: > > > Ironically I would excuse someone with little knowledge about Software > > Development, but for someone who knows cool words like "CORBA and C++" > > you should at least be aware of what User Requirements are and thing > > that go in there and things that NOT. It even more amazing that most > > people who participated in this thread did not even noticed that :-) > > Why, that's almost like saying that long-term requirements should not be > planned, up-front, as technical details! > Nope, that is not "technical details" that is "suggesting design in requirements" - which is a NO-NO. Phrase that sounds like "Multi- platform (Linux, Windows, + Real-time platforms TBD)" should never appear in requirements document because it is not a requirement. It is not only most common and most dangerous mistake made during requirement specification it is the most costly mistake as well. Requirement should only say what system should do for and with what constraints. So for example you should not say "System should be multi- platform" - that only the software engineer who will design the system can decide if it should be multi-platform or single platform, should it be real time embedded system written in C++ or 100 line program written in interpreted BASIC. As soon as it serves the purpose and satisfies all end-user requirements. Requirements should not say if software need to be a part of it. If you have requirements for the oven which only need to control temperature +- 1C and have timer - are you sure it needs software? Would it be cheaper and more practical without it? So again - design, parts of it or any suggestions to possible design decisions should be avoided in requirements specifications at all costs. Some my favorite references on requirements: [1] Software Requirements: Objects, Functions and States, Second Edition [FACSIMILE] (Paperback) by Alan M. Davis (Author) [2] Software Requirements, Second Edition (Paperback) by Karl E. Wiegers (Author) > -- > Phlip > http://www.oreilly.com/catalog/9780596510657/ > "Test Driven Ajax (on Rails)" > assert_xpath, assert_javascript, & assert_ajax Ajax on rails ... as for me I like filet mignon on charred onions and zucchini with balsamic vinegar sauce. Sorry just kidding ;-) Alexei.
From: David Lightstone on 23 Aug 2007 20:54 "Phlip" <phlipcpp(a)yahoo.com> wrote in message news:HYqdnZy5KY0EEFbbnZ2dnUVZ_ramnZ2d(a)adelphia.com... > Markus Elfring wrote: > >>> There's a couple of years detailed design yet to go. >> >> Would you like to look at recent design methodologies to avoid any >> pitfalls? >> http://en.wikipedia.org/wiki/Agile_software_development > > You total process zealot! Don't you know that one size doesn't fit all, > and that many great _heroic_ projects have been delivered, on time and > under budget, with pure Waterfall??! > > -- Huh, Are you not the official "Use Agile first" troll? > Phlip > >
From: Michi Henning on 23 Aug 2007 23:41 kjin101(a)gmail.com wrote: > > The C++ binding is out-of-date but not that horrific and is an > insignificant reason in CORBA's failure (or fall). Even if CORBA had a > perfect C++ binding, it would still as miserable as it today. I tend to agree. It's death by a thousand wounds. All the little bits that are wrong in minor ways (and sometimes major ways) add up to a considerable amount of pain. I believe that, had this pain not been experienced by users, the current SOA/WS/SOAP/XML craze would never have happened. Talk about jumping from the frying pan into the fire... Cheers, Michi.
From: S Perryman on 24 Aug 2007 04:19
"Michi Henning" <michi(a)zeroc.com> wrote in message news:YAszi.19436$tp3.99946(a)nasal.pacific.net.au... > kjin101(a)gmail.com wrote: >> The C++ binding is out-of-date but not that horrific and is an >> insignificant reason in CORBA's failure (or fall). Even if CORBA had a >> perfect C++ binding, it would still as miserable as it today. > I tend to agree. It's death by a thousand wounds. All the little bits > that are wrong in minor ways (and sometimes major ways) add up to a > considerable amount of pain. Yes, it is quite interesting how all the parties in the OMG managed to mess up CORBA, when the ANSA platform (a pre-cursor to CORBA, and a large input into the OMG/ODP stds) as far back as *1990* already had : - C/Objective-C/C++ IDL code generators - Full Trader capability (including federation) - Inter-working with Lisp/CLOS envs Regards, Steven Perryman |