Wednesday, March 03, 2004

Jon Udell: Component builders and solution builders http://weblog.infoworld.com/udell/categories/infoworld/2004/03/03.html#a932 Jon discusses (and points to) the why's and how's of typed vs. typeless languages. As a database guy, I think it's important to mention that typed languages have at least one and sometimes two more relational mapping disconnects than typeless languages (objects/classes + types). If the bulk of what you're trying to do involved getting important stuff into and out of a database, which has limited but useful typing capabilities, it can be confusing and counterproductive to add a second incompatible type system on top (which handles NULLs differently) in addition to ORM. When you're doing a lot of database coding, with sizes spanning both tiny and respectable, it feels much easier to use a tool that scales down to avoiding these disconnects. Scripting languages that don't force a type system on you gel much better with this narrow set of use cases ( which still comprise most of the coding that businesses need IMHO. ) Propylon's Sean McGrath extends this observation to rigid hierarchies vs. XML, and mentions duck typing, which I'm not sure I understand, but I probably use a lot anyway. :-) 5:47:37 PM      comment []  trackback []

Ripped from the inbox: In search of a component framework I thought I'd post this to the blog to see if anyone could contribute: Alec wrote: A friend of mine has been asking me some questions about aspects of technology that I don't keep up on very well, and I suspect you might have a good answer for this off the top of your head. When I worked at ***, we converted our system so that it was OM-based. We have various user interface programs that were COM clients, and our translation engine is a COM component. We actually created a few translation engine for different language pairs, so that the UIs could connect to whichever engine the user wanted to use. This was all done on a single machine, never distributed, and they never switched over to .NET. The whole application is C++. Now, the client wants to port to Linux. I doubt the client has thought about the component implications of this. My opinion is that the easiest thing at this point would be to migrate to a COM-like component system that works on Linux. Does such a thing exist and does it work? What would be the best thing, however, would be to migrate over to a component system that works on both Windows and Linux, so that the source code would be more easily portable. Does that exist? For cross platform component systems, your choices are Java, Corba, and .NET (sort of). Other ones exist ( Mozilla's XPCOM ), but either don't have much marketplace traction or are not cross platform (KParts, Bonobo). .NET has an open source version written by Novell called mono, that while lagging the windows version is supposed to work okay. It should work for wrapping up and exposing portable C++ code, much better than Java for sure (wrapping/exposing C libraries portably it's why the mono project was launched). Corba is very mature but is even more overhead than Java, so that's probably not too great an option. If you don't have to run in-process, however, you could use the trendy new Corba-lite, SOAP, and then just bundle in a lightweight standalone httpd listener. Network overhead of a local corba or soap daemon process is probably not a dealbreaker for a translation engine, but if other folks are OEM'ing it that might be a problem. I'm actually going to a mono developer meeting - it's this friday (and saturday). Your friend might want to think about attending, then he can talk to mono's authors in person. http://primates.ximian.com/~miguel/MonoMeet.html mono has some potential legal or patent issues that might be a gotcha someday, but if that doesn't bother you (it doesn't seem to bother novell), then it's probably your best bet. 4:24:24 PM      comment []  trackback []