Thinking about my previous post where I alluded to a potential for there being Ruby support in a future version of Gen, I stumbled upon a possible way forward for Gen to be an even bigger tool than it actually is …..
Since the new versions of Gen are going to be Eclipse-based i.e. based on a freely available framework – which sort of builds upon the current developer trend for adapting frameworks for use with plug-ins, what if there were a published “Gen Generator” API into which 3rd party generators could be produced?
 This would reduce the time to market for new languages and frameworks to be supported, whilst still giving CA the chance to market the tool and the superb encyclopedias for code repositories.
Look at the success tools like GuardIEN have had – no-one uses the native Gen tools anymore to migrate and control versions – nearly all the big sites use GuardIEN – but this has not reduced CA’s marketing collateral in terms of selling Gen licenses !
If publishing an API for the generators, or a plugin-style architecture could be considered, then many more languages and frameworks could be supported by development teams (either in the freeware, or open source or commercial spaces) as well as by CA themselves.
Potential candidates for generators could be Ruby, other .NET languages that appear, Python (possibly for smaller systems). Additionally, generators for different platforms (still C, COBOL etc etc) could be produced in this way.
Of course, there will still be support issues to consider, but potentially if a good generator for, say, C on a MacOS platform were to be developed, or possibly a Symbian OS target, then it could be adopted by CA as a de-facto and supported.
I suppose what I am saying is that by splitting the product up into the developer interface and a back-end generator, the people that build generators could be used as “incubators” to add to the target platforms later on when the generators are formally adopted …..
This could only strengthen the “write once, deploy many” argument that IS Gen !
August 13, 2007 at 9:57 pm |
Interesting ideas; traditionally platforms have always been the place to play, whether that be the mainframe, windows or an environment like Java. The advantage to CA of an approach like this would obviously be to maximise R&D around Gen without actually having to put in any money. As you say, maximising the ecosystem would only serve to sell more licenses for the core platform (i.e. gen).
There are text templating engines for Java and .Net that do the sorts of things that you describe (for example have a look at the DSL tookit in visual studio) and so it’s not that fanciful.
I guess the biggest question is why? At the end of the day the benefits of a tool like Gen are that you don’t need to worry about the implementation language because you are buying into a framework that delivers outputs efficiently (through code generation) in place of flexibility (through being able to code however you like). In that context it would seem more valuable to me for CA to concentrate on playing nicely with everyone else through extending their platform to natively support web services than it is to support dynamic languages like Ruby (particularly given that they are opposite ways of delivering the same goal; Gen attempts to allow rapid development and change through higher level modelling whilst Ruby does it via scripting and dynamism. If you believe you have dynamism through modelling, though, why take the performance and security hit of generating to a scripting language for deployment?)
August 13, 2007 at 10:16 pm |
I suppose that I used Ruby as an example – albeit a particularly bad one !
What I was trying to get across is that should new environments and platforms become available, then an already established ecosystem is possibly the way to maximise awareness and movement within a product line.
Whilst I agree with Ian in that Gen’s beauty is that it does isolate you from some of the main problems with deploying traditional software systems is the understanding of the hardware and software environments into which that deployment is to take place, Gen needs to evolve, and if that evolution means that it must support new langauages, frameworks or even paradigms, then is CA the best and quickest means to do that ?
What I was getting at, is that I dont believe that Java has got where it is because Sun was particularly good at promoting it – it got where it was because there was a body of developers that supported it.
Apple played things close to its chest and MacOS isnt the big player it could have been because of this.
I’m also taking the argument that if Gen hadn’t embraced .Net and Java (in the same way that it could embrace “the next big thing” then it wouldn’t be true to its word and the “write once, use many” mantra would have been broken.
And, YES – I DO believe that we have dynamism though modelling!!!!
September 12, 2007 at 2:13 pm |
other facts:
and not only becouse of RoR, also because of XP, agile, behavior driven development and pair programming.
1. we have now 4 active ruby on rails projects in our company & by our customers, it is exciting to see, how my employees are working and how quickly RoR projects are going to production. I mean, RoR could by the next “big thing”
2. when already ibm is there: http://www.alphaworks.ibm.com/tech/db2onrails ca should starting to think about it….
3. using Gen generated web services in RoR enviroment is easy…
September 12, 2007 at 11:29 pm |
When you say 4 active RoR projects – presumably they are “raw” Ruby. I’m considering whether Gen needs to support other deployment languages, or has the time for “other” languages finished now that standards-based interactions are available e.g. WS-I ?
I really dont know which way to go now – should we be pressing for CA to support new languages and frameworks as my post suggest, or should we be pressing for CA to support new standards, or both?
It seems to me that if standards-based interfaces are here to stay, what is the point of developing support for new languages, if we can simply interact with the tried and tested ones with standardised mechanisms…….mmmm….dilemma !!!!