Thursday, August 24, 2006
38 Cool Things Eiffel Does
The ISE website contains a puff piece listing a whole bunch of cool ways to use Eiffel.
Some of the bullet points will be familiar to most of us ("Easily add contracts to classes for robust, unbreakable code"). Some of them may be new to some people ("Do multiple and repeated inheritance from .NET classes, just as if they were Eiffel classes", "Contain WinForms components in EiffelVision2 and vice-versa", "Use DBC transparently across COM servers"). Some of them might stretch the imagination a little ("Easily track down bugs at execution without debugging and almost without cost", "Create your business model and then use it directly to implement").
But amongst the 38 "Cool Things" there are sure to be some nifty ways of using Eiffel that you haven't yet explored.
posted by Roger Browne @ 13:53 
Comments:
<< Home
Hi Roger,
For those readers who will humor me, I'll get back around to relating this to the original post "38 Cool Things Eiffel Does."
Delphi developer here lurking for a few days. I've been scoping out my options since it appears that my repeated requests I've made in the Delphi community for non-Windows targets continues to be met with the sound of crickets chirping.
Unless there's a real measurable benefit to moving all my code to another language, Delphi will continue to be my Windows-specific dev tool.
As a developer and business owner who's been in the thick of shrinkwrapped development with high commercial demands for 18 years, mainly using BP in DOS and Delphi in Windows, I thought I might share an outsider's perspective with the Eiffel folks, niche tools developer to niche tools developer. Believe it or not, Delphi is now more of a niche tool than it's ever been.
I started out with a massively successful leased software package in DOS that had a fanatical user base (hence, users play a big role in UI design, a strategy that has always paid off for Apple). In DOS, of course there was no Windows look/feel, and PC's were still novel office desktop fixtures.
Since we spent so much time communicating with our users, the functionality of our software was far and away the justifier for them having a PC on their office desks. Turbo Pascal helped us make this happen, while the OS (DOS) was incidental to the experience. I think this is a very important point. Using TP, it was the functionality that we created that justified the cost of each user in an office owning a PC.
When a usable Windows (95) came into the picture, the novelty of PC's had worn off a bit. Additionally, Windows provided a uniform UI experience, which in a sense ends up devaluing the uniqueness (and user ownership) that you could find with DOS programs, especially heavy data entry programs like the one I worked on.
Borland responds with a beautiful RAD package called Delphi. The new language features, like "try..except" and "try..finally" were just awesome. To this day, and even with the challenges of .NET, Delphi is still arguably the most productive RAD tool for Windows, even though I think the latest VS w/C# is very good.
The problem is that MSFT continues to consolidate an increasing developer brainshare of a very mature market (Windows). The latest attack is .NET, and it's a brilliant move on MSFT's part. I think a lot of .NET really is good stuff, but let's not kid ourselves, as MSFT has more to gain from .NET than we developers do.
So now Delphi is in really big trouble. C# is easy enough to learn, VS is a very good tool, and Delphi is always playing catch-up with .NET. Of course Delphi's new home, as yet to be named Devco, simply will be unable to marshall the resources necessary to compete on an even footing with the VS/C# combination. Additionally, there's a really nice Pascal .net addin (called Chrome) already available from a very smart company called Remobjects, who also produce a brilliant middleware of the same name. Incidentally, Chrome already supports a form of DBC!
Regardless of the past Kylix experience (it was mis-targeted, IMO), Borland/Devco and most of the Delphi community have no interest in supporting a multi-platform solution. The effect is this: 1) especially because of .NET, Delphi is increasingly becoming a "me-too" product, 2) old habits are hard to break, and since Delphi is so capable in this regard, desktop development is apparently still the world most of the Delphi community live in.
I've stated this before on a Delphi board. Generally, it seems that the Delphi community is either happy with this state of affairs as controlled by MSFT, or they can't imagine an alternative reality without sucking the hind teat that MSFT leaves hanging out. Or maybe Devco and the community are just short on good alternative plans.
But the thing is, is that the whole computing industry is undergoing a seachange right now IMO, and with it an opportunity for a dev tool to gain a real foothold. The PC processor has become incredibly powerful, but unexploited, the OS is becoming incidental to the functionality provided. So it's like we're back developing for DOS, where the available functionality justifies the IT infrastucture, and not a specific brand of OS, which to a degree will suffer from the same commoditization that the PC underwent. Add into the mix the prediction which is coming true that Metcalf made back in 1999, that we'd eventually be awash in bandwidth, and we finally have commercial software development, chapter 2; The new platform is the internet itself, finally able to exercise its true collaborative potential, and services delivered via this platform are the new business case for companies to continue investing in IT infrastructure. It's the "Infrastucture in the Cloud" that Udell talks about a lot in Infoworld. Metcalf btw, thought this bandwidth was going to come from FTTH, but it turns out that it will be from WiFi technologies. Watch for WiMAX efforts like the 40 gbit service available from Sprint next year to start to turn our traditional thinking about shrinkwrapped desktop programming on its ear.
Current dev markets are mature or have marginal access to money. Internet services and new usage-specific pricing models are the future, and any dev tool that can help us design and implement the IT infrastructure to support this future is going to get real market share.
Now I'm not just talking about something like developing another salesforce.com here; rather any endpoint should be able to provide or consume services to or from any other endpoint. It's true internet collaboration realized, like podcasting services instead of just music.
The kind of dev tool that helps me get a product to market that provides this functionality is the one that I'd like to work with in the future. The feature list for such a tool will be pretty challenging to fill: Basic necessities will include the ability to generate a rich browser client, properly eating a WSDL file and fully supporting SOAP, security, middleware frameworks, native apps with processor specific optimizations, as opposed to writing .NET servers. More complicated features would include tools to assist wide area design and deployment, application partitioning, and failover.
So back to the starting post about cool stuff that Eiffel can do. Looks like to me they generally focus on productivity gained from using Eiffel, software quality and .NET.
I'm telling you from a bitter Delphi experience that the .NET stuff will do nothing for Eiffel in the long run, but just provide another MSFT hind teat and the ability to say "me too." VS and C# are completely adequate for .NET development, and they'll continue to help MSFT maintain the Windows lockstep that it already has. Besides, as I mentioned, at least one other .NET language already includes DBC.
What I'd like to see on that list of cool things are a remoting middleware framework which has a high-performance proprietary protocol and a soap protocol, Eiffel to javascript ajax support, and either native, highly optimized generation of target executables, or generation of C with helpers for optimization. It seems to me that if Eiffel is the enterprise developers' langugage it's purported to be, then building cloud-based IT infrastructure that is platform-agnostic is it's chance to show the pudding. Additionally, it's a market that MSFT can't control!
MSFT can't control the internet platform, and I guarantee they're painfully aware of this fact of reality. Watch them get desperate with "Windows Live" as time passes, and Google provides more services and buys up more dark fiber.
I know that some of these tools already exist for Eiffel (ex. Goana for middleware) in the form of open source projects, but open source projects just don't display the same rigor and devotion to timelines that products carrying commercial pressures and incentives do. Some company that either resells Eiffel source it has developed for internal use, or a for-profit company like ISE is going to have to take the initiative to make these tools available to the Eiffel community.
Personally, the easiest move I could make is to stick with my Delphi code and move it to something like FreePascal. Those guys have done a wonderful job given the open-source circumstances. But then, a couple of my commercial tools would have to make the move with me, and I'm not sure that that will happen, so that's why I'm also considering alternative strategies, with ISE Eiffel at the top of the list. The Eiffel language appears to be a very easy transition for me, in spite of there not being any "implementation" sections. I've also looked at Ada as very capable of delivering web services, but just even the new 2005 extension keywords look fairly complicated. Eiffel appears to me to be substantially easier to pick up than Ada.
I've looked at ISE's wiki, and seen the list of dev plans for future versions. I appreciate extending the language, but it's extending a language that hardly anybody uses. Maybe Meyer has an academic interest that doesn't consider mundane stuff like SOAP support, and I also get the impression that he runs a very small developer shop which fits his available budget. If that's the case, unless he just wants to serve some academic interest with this project, he needs to find somebody with some commercial application vision, get that person to write a business plan to grow a new product, and raise some venture that will help his shop expand its work unit capacity.
James
jksmith@dxmtechnologies.com
For those readers who will humor me, I'll get back around to relating this to the original post "38 Cool Things Eiffel Does."
Delphi developer here lurking for a few days. I've been scoping out my options since it appears that my repeated requests I've made in the Delphi community for non-Windows targets continues to be met with the sound of crickets chirping.
Unless there's a real measurable benefit to moving all my code to another language, Delphi will continue to be my Windows-specific dev tool.
As a developer and business owner who's been in the thick of shrinkwrapped development with high commercial demands for 18 years, mainly using BP in DOS and Delphi in Windows, I thought I might share an outsider's perspective with the Eiffel folks, niche tools developer to niche tools developer. Believe it or not, Delphi is now more of a niche tool than it's ever been.
I started out with a massively successful leased software package in DOS that had a fanatical user base (hence, users play a big role in UI design, a strategy that has always paid off for Apple). In DOS, of course there was no Windows look/feel, and PC's were still novel office desktop fixtures.
Since we spent so much time communicating with our users, the functionality of our software was far and away the justifier for them having a PC on their office desks. Turbo Pascal helped us make this happen, while the OS (DOS) was incidental to the experience. I think this is a very important point. Using TP, it was the functionality that we created that justified the cost of each user in an office owning a PC.
When a usable Windows (95) came into the picture, the novelty of PC's had worn off a bit. Additionally, Windows provided a uniform UI experience, which in a sense ends up devaluing the uniqueness (and user ownership) that you could find with DOS programs, especially heavy data entry programs like the one I worked on.
Borland responds with a beautiful RAD package called Delphi. The new language features, like "try..except" and "try..finally" were just awesome. To this day, and even with the challenges of .NET, Delphi is still arguably the most productive RAD tool for Windows, even though I think the latest VS w/C# is very good.
The problem is that MSFT continues to consolidate an increasing developer brainshare of a very mature market (Windows). The latest attack is .NET, and it's a brilliant move on MSFT's part. I think a lot of .NET really is good stuff, but let's not kid ourselves, as MSFT has more to gain from .NET than we developers do.
So now Delphi is in really big trouble. C# is easy enough to learn, VS is a very good tool, and Delphi is always playing catch-up with .NET. Of course Delphi's new home, as yet to be named Devco, simply will be unable to marshall the resources necessary to compete on an even footing with the VS/C# combination. Additionally, there's a really nice Pascal .net addin (called Chrome) already available from a very smart company called Remobjects, who also produce a brilliant middleware of the same name. Incidentally, Chrome already supports a form of DBC!
Regardless of the past Kylix experience (it was mis-targeted, IMO), Borland/Devco and most of the Delphi community have no interest in supporting a multi-platform solution. The effect is this: 1) especially because of .NET, Delphi is increasingly becoming a "me-too" product, 2) old habits are hard to break, and since Delphi is so capable in this regard, desktop development is apparently still the world most of the Delphi community live in.
I've stated this before on a Delphi board. Generally, it seems that the Delphi community is either happy with this state of affairs as controlled by MSFT, or they can't imagine an alternative reality without sucking the hind teat that MSFT leaves hanging out. Or maybe Devco and the community are just short on good alternative plans.
But the thing is, is that the whole computing industry is undergoing a seachange right now IMO, and with it an opportunity for a dev tool to gain a real foothold. The PC processor has become incredibly powerful, but unexploited, the OS is becoming incidental to the functionality provided. So it's like we're back developing for DOS, where the available functionality justifies the IT infrastucture, and not a specific brand of OS, which to a degree will suffer from the same commoditization that the PC underwent. Add into the mix the prediction which is coming true that Metcalf made back in 1999, that we'd eventually be awash in bandwidth, and we finally have commercial software development, chapter 2; The new platform is the internet itself, finally able to exercise its true collaborative potential, and services delivered via this platform are the new business case for companies to continue investing in IT infrastructure. It's the "Infrastucture in the Cloud" that Udell talks about a lot in Infoworld. Metcalf btw, thought this bandwidth was going to come from FTTH, but it turns out that it will be from WiFi technologies. Watch for WiMAX efforts like the 40 gbit service available from Sprint next year to start to turn our traditional thinking about shrinkwrapped desktop programming on its ear.
Current dev markets are mature or have marginal access to money. Internet services and new usage-specific pricing models are the future, and any dev tool that can help us design and implement the IT infrastructure to support this future is going to get real market share.
Now I'm not just talking about something like developing another salesforce.com here; rather any endpoint should be able to provide or consume services to or from any other endpoint. It's true internet collaboration realized, like podcasting services instead of just music.
The kind of dev tool that helps me get a product to market that provides this functionality is the one that I'd like to work with in the future. The feature list for such a tool will be pretty challenging to fill: Basic necessities will include the ability to generate a rich browser client, properly eating a WSDL file and fully supporting SOAP, security, middleware frameworks, native apps with processor specific optimizations, as opposed to writing .NET servers. More complicated features would include tools to assist wide area design and deployment, application partitioning, and failover.
So back to the starting post about cool stuff that Eiffel can do. Looks like to me they generally focus on productivity gained from using Eiffel, software quality and .NET.
I'm telling you from a bitter Delphi experience that the .NET stuff will do nothing for Eiffel in the long run, but just provide another MSFT hind teat and the ability to say "me too." VS and C# are completely adequate for .NET development, and they'll continue to help MSFT maintain the Windows lockstep that it already has. Besides, as I mentioned, at least one other .NET language already includes DBC.
What I'd like to see on that list of cool things are a remoting middleware framework which has a high-performance proprietary protocol and a soap protocol, Eiffel to javascript ajax support, and either native, highly optimized generation of target executables, or generation of C with helpers for optimization. It seems to me that if Eiffel is the enterprise developers' langugage it's purported to be, then building cloud-based IT infrastructure that is platform-agnostic is it's chance to show the pudding. Additionally, it's a market that MSFT can't control!
MSFT can't control the internet platform, and I guarantee they're painfully aware of this fact of reality. Watch them get desperate with "Windows Live" as time passes, and Google provides more services and buys up more dark fiber.
I know that some of these tools already exist for Eiffel (ex. Goana for middleware) in the form of open source projects, but open source projects just don't display the same rigor and devotion to timelines that products carrying commercial pressures and incentives do. Some company that either resells Eiffel source it has developed for internal use, or a for-profit company like ISE is going to have to take the initiative to make these tools available to the Eiffel community.
Personally, the easiest move I could make is to stick with my Delphi code and move it to something like FreePascal. Those guys have done a wonderful job given the open-source circumstances. But then, a couple of my commercial tools would have to make the move with me, and I'm not sure that that will happen, so that's why I'm also considering alternative strategies, with ISE Eiffel at the top of the list. The Eiffel language appears to be a very easy transition for me, in spite of there not being any "implementation" sections. I've also looked at Ada as very capable of delivering web services, but just even the new 2005 extension keywords look fairly complicated. Eiffel appears to me to be substantially easier to pick up than Ada.
I've looked at ISE's wiki, and seen the list of dev plans for future versions. I appreciate extending the language, but it's extending a language that hardly anybody uses. Maybe Meyer has an academic interest that doesn't consider mundane stuff like SOAP support, and I also get the impression that he runs a very small developer shop which fits his available budget. If that's the case, unless he just wants to serve some academic interest with this project, he needs to find somebody with some commercial application vision, get that person to write a business plan to grow a new product, and raise some venture that will help his shop expand its work unit capacity.
James
jksmith@dxmtechnologies.com
# posted by 
: 12 September, 2006 06:59
: 12 September, 2006 06:59
Hi James,
Thanks for your insightful post. There are plenty of Eiffel users who have Delphi experience; it's certainly a relatively easy bridge to cross.
Ten years ago I wrote an HTML 2.0 web browser twice - once using Delphi and once using Eiffel. Then Microsoft announced that they were developing a browser to give away for free so that was the end of that project! Anyway, I wrote it up, including a comparison of the Eiffel and Delphi approaches. It's very dated now, but you may still find it interesting.
Regarding Goanna, you are right that it's not ready for commercial prime time, but I don't think it's an impossible target.
Don't underestimate Bertrand Meyer's future chances. He has both an academic interest and a commercial interest in ISE Eiffel, and has a good solid base of large commercial/industrial/defense customers.
That's why Eiffel has good support for technologies like COM and CORBA. In turn, SOAP and AJAX will be well-supported (although not as soon as we would like, of course).
There's also other glueware available, like eiflex which is a side product being spun off from a commercial Eiffel project.
I agree with you that language extension is not what Eiffel needs - but it's happening to EiffelStudio anyway so we just need to live with it.
Much more important, in my opinion, would be better support for generating and using runtime-linkable components. Eiffel is gradually retreating from its "always compile the whole world" approach - initially with EiffelStudio for .NET - and I look forward to a time when we can drop third-party components into an Eiffel GUI application designer (such as EiffelBuild) as easily as we can do with Delphi.
Regards,
Roger Browne
Thanks for your insightful post. There are plenty of Eiffel users who have Delphi experience; it's certainly a relatively easy bridge to cross.
Ten years ago I wrote an HTML 2.0 web browser twice - once using Delphi and once using Eiffel. Then Microsoft announced that they were developing a browser to give away for free so that was the end of that project! Anyway, I wrote it up, including a comparison of the Eiffel and Delphi approaches. It's very dated now, but you may still find it interesting.
Regarding Goanna, you are right that it's not ready for commercial prime time, but I don't think it's an impossible target.
Don't underestimate Bertrand Meyer's future chances. He has both an academic interest and a commercial interest in ISE Eiffel, and has a good solid base of large commercial/industrial/defense customers.
That's why Eiffel has good support for technologies like COM and CORBA. In turn, SOAP and AJAX will be well-supported (although not as soon as we would like, of course).
There's also other glueware available, like eiflex which is a side product being spun off from a commercial Eiffel project.
I agree with you that language extension is not what Eiffel needs - but it's happening to EiffelStudio anyway so we just need to live with it.
Much more important, in my opinion, would be better support for generating and using runtime-linkable components. Eiffel is gradually retreating from its "always compile the whole world" approach - initially with EiffelStudio for .NET - and I look forward to a time when we can drop third-party components into an Eiffel GUI application designer (such as EiffelBuild) as easily as we can do with Delphi.
Regards,
Roger Browne
Hi Roger,
I did take a look at your web browser project. Very nice experience, and I'd suggest that the niche for a specialty browser is larger than you think, especially if you added javascript interpretation. Im sure that adds a whole new level of complexity, but the niche I'm referring to is the one that IE has inadvertently provided: A safe browser that doesn't leave artifacts laying around. MSFT apparently has no incentive to provide this functionality.
What I did as part of the security/privacy suite I've developed is write a Delphi wrapper around the IE com object ( a rather buggy beast) which automatically destroys the cached artifacts when you close it, and also manages its own favorites and recent history to encrypted store.
>In turn, SOAP and AJAX will be well-supported (although not as soon as we would like, of course).
For sure. I wonder what Meyer would say regarding modifying his current dev schedule if such a project was capitalized for him. Could he produce the goods in a competitive timeframe?
>There's also other glueware available, like eiflex which is a side product being spun off from a commercial Eiffel project.
Thanks for that link. I checked it out, and also found the 2ab stuff, which looks very interesting, and oddly enough those guys are right down the road from me.
>- initially with EiffelStudio for .NET - and I look forward to a time when we can drop third-party components into an Eiffel GUI application designer (such as EiffelBuild) as easily as we can do with Delphi.
I appreciate that, and have enjoyed that kind of functionality in Delphi for years. Here's my counterpoint:
1) Even though we like this functionality, I'd be more interested in applying Eiffel to problems that may not be as easy to solve in other languages or dev environments, which happen to already be very good at component based development. IOW, the tough problem that hasn't been dealt with effectively on a grand scale by any one dev tool: building out large-scale IT infrastructure,I'd be interested to try to use Eiffel to solve that problem. I can pay lots of people a few bucks an hour to do gui design cheaper than I can do it myself -- that problem has already been solved.
2) If the components are not well-designed with Eiffel (as with .net), the total value of using Eiffel for large system development is negated, and (esp. with .net) Eiffel becomes nothing more than a language choice among many. My prediction: The issue of true software quality is going to become a major theme because of security concerns that accompany developing large-scale infrastructure for the internet platform. So much so, that developers will have to be accountable for their work even the most trivial consumer markets. You know SparkAda tries to address this issue by proving quality. The only problem is that once the resulting work is finally ready for market, it still has to run on Windows -- lipstick for the pig.
Maybe I'm offbase here, but if you can't have the OS written in Eiffel as well, then at least have as much as the user mode application as possible written in Eiffel. Lots of native Eiffel components that would provide some parity with the Delphi world would be great, though. You can find a native component for just about any task in Delphi.
James
I did take a look at your web browser project. Very nice experience, and I'd suggest that the niche for a specialty browser is larger than you think, especially if you added javascript interpretation. Im sure that adds a whole new level of complexity, but the niche I'm referring to is the one that IE has inadvertently provided: A safe browser that doesn't leave artifacts laying around. MSFT apparently has no incentive to provide this functionality.
What I did as part of the security/privacy suite I've developed is write a Delphi wrapper around the IE com object ( a rather buggy beast) which automatically destroys the cached artifacts when you close it, and also manages its own favorites and recent history to encrypted store.
>In turn, SOAP and AJAX will be well-supported (although not as soon as we would like, of course).
For sure. I wonder what Meyer would say regarding modifying his current dev schedule if such a project was capitalized for him. Could he produce the goods in a competitive timeframe?
>There's also other glueware available, like eiflex which is a side product being spun off from a commercial Eiffel project.
Thanks for that link. I checked it out, and also found the 2ab stuff, which looks very interesting, and oddly enough those guys are right down the road from me.
>- initially with EiffelStudio for .NET - and I look forward to a time when we can drop third-party components into an Eiffel GUI application designer (such as EiffelBuild) as easily as we can do with Delphi.
I appreciate that, and have enjoyed that kind of functionality in Delphi for years. Here's my counterpoint:
1) Even though we like this functionality, I'd be more interested in applying Eiffel to problems that may not be as easy to solve in other languages or dev environments, which happen to already be very good at component based development. IOW, the tough problem that hasn't been dealt with effectively on a grand scale by any one dev tool: building out large-scale IT infrastructure,I'd be interested to try to use Eiffel to solve that problem. I can pay lots of people a few bucks an hour to do gui design cheaper than I can do it myself -- that problem has already been solved.
2) If the components are not well-designed with Eiffel (as with .net), the total value of using Eiffel for large system development is negated, and (esp. with .net) Eiffel becomes nothing more than a language choice among many. My prediction: The issue of true software quality is going to become a major theme because of security concerns that accompany developing large-scale infrastructure for the internet platform. So much so, that developers will have to be accountable for their work even the most trivial consumer markets. You know SparkAda tries to address this issue by proving quality. The only problem is that once the resulting work is finally ready for market, it still has to run on Windows -- lipstick for the pig.
Maybe I'm offbase here, but if you can't have the OS written in Eiffel as well, then at least have as much as the user mode application as possible written in Eiffel. Lots of native Eiffel components that would provide some parity with the Delphi world would be great, though. You can find a native component for just about any task in Delphi.
James
# posted by : 14 September, 2006 07:01
: 14 September, 2006 07:01
Hi Peter,
I'm showing my ignorance here about the full import of what DbC is. You're right, Chrome refers to their structure as "class contracts." Not exactly the same thing: class contracts
Some additional interesting and fairly recent discussion on DbC at Joel's site:
Joel on Software
James
I'm showing my ignorance here about the full import of what DbC is. You're right, Chrome refers to their structure as "class contracts." Not exactly the same thing: class contracts
Some additional interesting and fairly recent discussion on DbC at Joel's site:
Joel on Software
James
# posted by : 14 September, 2006 07:18
: 14 September, 2006 07:18
Oops, I guess just copy and paste if you like. I think this this blog does some interpreting if the link doesn't have a www prepended.
http://discuss.joelonsoftware.com/default.asp?joel.3.109769.14
James
http://discuss.joelonsoftware.com/default.asp?joel.3.109769.14
James
# posted by : 14 September, 2006 07:23
: 14 September, 2006 07:23
> I wonder what Meyer would say regarding
> modifying his current dev schedule if
> such a project was capitalized for him.
> Could he produce the goods in a
> competitive timeframe?
I'm sure he could. ISE has the resources and the skills for this. ISE's work on embedded versions of Eiffel, their work on COM and CORBA, their work on .NET, their interface with object databases: much of this development happened because it was "capitalized" for them (for example, Microsoft funded the original research work on Eiffel for .NET).
Also, thanks for the Joel link - I was interested to read about the Carmen language.
Regards,
Roger Browne
Post a Comment
> modifying his current dev schedule if
> such a project was capitalized for him.
> Could he produce the goods in a
> competitive timeframe?
I'm sure he could. ISE has the resources and the skills for this. ISE's work on embedded versions of Eiffel, their work on COM and CORBA, their work on .NET, their interface with object databases: much of this development happened because it was "capitalized" for them (for example, Microsoft funded the original research work on Eiffel for .NET).
Also, thanks for the Joel link - I was interested to read about the Carmen language.
Regards,
Roger Browne
<< Home
