First of all, there is no doubt that the followers of the Notes/Domino platform are very passionate about the platform, where it is and where it is going. This is a good thing. We saw evidence of this at Lotusphere as well. That being said I think that the discussion in the thread on Eds blog has probably ventured somewhat off-topic into a discussion on development platforms and a discussion on strongly vs. loosely typed programming languages. Probably a discussion best left in another forum… 🙂
Worse though is the fact that some just refuse to accept the change that is inevitable in this industry. The move to Java, or another new programming language, in the future is inevitable. However no one, certainly not myself, dispute the fact that LotusScript is the de facto programming language of the Notes/Domino platform. We all know IBM makes mistakes once in a while but I certainly do not think they would saw of the branch they are sitting on by deprecating the LotusScript language. As I wrote in the original post: “LotusScript will probably be supported from now to the demise of the platform.”
I think Ed explains it very well and clearly in one of his comments (@61) to the discussion thread:
"So yes, the userbase wants to keep Lotuscript as the default language. And to be clear, Lotuscript doesn't go away, change, or deprecate in the Notes "Hannover" release. And some of the ideas here on how to extend the value of a Lotuscript skillset are interesting and make sense. But a view of the larger IT market indicates that the need to incorporate other languages -- AND development tools -- with the Notes environment of today is an even better bet."
Please note here that not deprecating LotusScript is in no way the same as extending it and having the LotusScript API provide the same level of functionality that I think the Java and JavaScript API will provide in the Hannover+ timeframe. LotusScript will survive as a Notes/Domino language but Java and JavaScript will, even though adoption seems to be painfully slow, become the new Lingua franca of the IBM World.
We, as the ever-passionate Notes/Domino community, have to overcome our fear of change and accept that application development has, and continues to move away, from the proprietary, all-in-one-NSF, single-platform development style that has been prevalent for so many years. This doesn’t mean that you have to move away from this type of development and a lot of applications will continue to benefit from the RAD (oops – I said it!) environment of Notes/Domino.
It is just that the majority of new applications being developed, or existing ones getting a tune-up, needs to look outside the Notes/Domino platform for information. Whether this be a simple lookup in a RDBMS, a call to a web service or a series of complicated calls to an ERP system doesn’t really matter. The can of worms is open and to think that the complexities of system integration will disappear in the foreseeable future is just mad. Having a non-proprietary programming language with widespread industry adoption makes this kind of system integration a lot easier and the benefits should be clear. For one we can avoid the proliferance of custom LSX modules wrapping C/C++ API code to provide access to system X, Y and Z.
The shift towards composite applications, including the kind you can build in Hannover, will be all about system integration – this is why Java adoption is a necessity. Not for the traditional kind of applications but for the new stuff.
Instead of bitching and moaning I think we, as a community, should be thrilled and instead focus on the fact that IBM has seen this shift coming, and that Notes/Domino with the Hannover client is embracing the future and providing the tooling to leverage existing investments in other platforms. Lets embrace the future not hide away from it refusing to accept the change that is coming.
The need as a developer to skill-up by embracing Java might seem unjust and a burden but the alternative would be even worse. You, and the customer you serve (whether the customer be internal or external), would be left behind with a dead, proprietary, used-to-be-great platform. Instead you are getting a heads-up while there is time.
Happy coding… 🙂
lekkimworld.com 
Personally I’m excited at the prospect of these changes. All I ask is for a role in which I work with this good stuff — it’s not necessarily the individual developer who is resistant to all this!
LikeLike
First: Good call to take this discussion elswhere sice it went off topic.
About this moving to Java talk. I really don’t get this. It’s like apples and oranges to me. You make it sound, and I’ve heard this before and it annoys me, as if Notes/Domino developers are conservative and reluctant to pick up new ideas. I do not agree.
Java is a structured language with some OO support like Lotus Script, Pascal or Visual Basic. And I really really don’t mind programming in Java and I think most Domino developers agree on this. It is *no* big deal. The problem however with Java in Domino is that it is not very well implemented into Domino and that it is significantly slower that Lotus Script.
This is not about language. It is about platforms.
As I understand Hannover the “thing” is *not* that Java will be better intergrated into Domino, but that Domino will be a component of new Workplace applications. I e you can access Dominos object model through Eclipse/Java and access/use Domino functionality when building applications.
Well pardon me, but that does not sound overly appealing. Why?
First: There are a bttld of Notes/Domino applications here that will not go away. Many of these are old and need rewrites or refactoring (to use a more modern word). I like to do this gradually because I’ve found that it works best. It also gives the customer many small slaps instead of one big punch, so to speak. When some part of the application needs changes because of new business demands, then that part is also refoctored if needed. To take one big leap and move all the logic and UI to some other platform and let the data reside in Domnio, is just silly to me. You could just move the storage of data away from Domino aswell then. And if customers want to pay for that. Fine. Thing is that they wont if they dont have to. And I don’t think they have to, and they trust me on that.
Second: As for interpolation, I don’t feel left out at all in Domino. I can access RMDBs, use middleware, publish and consume webservices, so I really see no need to venture outside Domino for this.
Third: If we start building Workplace composite applications in Eclipse then we will have some apps/components inside Domino and some residing outside, and that would be unpratical. A big advantage of Domino is that applications have the same basic structure and athentication model no matter how “crazy” the deloper that built it was. And all the stuff is inside one nice hefty NFS ball.
The Hannover/Eclipse thing seems more and more to me like Domnio licence money spent on other things than making Domino better, and that annoys me a bit.
I can see IBMs take on this however. They need to sell products. And hey, Notes/Domino is just two products. Very resonable priced as well. Webspehere and Workplace products (phew! :-). There are some nice price tags on that stuff. For IBM that is…
Regards /Patrix
LikeLike
Eclipse is an interesting environment on its own, Domino has traditional we_dont_have_thats like transactions and the deeper the Java integration in Domino the better I can use openSource frameworks and tools I use all the time.
The discussion is about eclipse integration and I never paid much money for Eclipse.
LikeLike
Axel: Corporate J2EE IBM centric development is not done in Eclipse. It is done in “Rational Web Developer for WebSphere Software” aka “Websphere Application Developer” aka “Visual Age” (they rename it every second year and the name gets longer each time :-). The price for that is one grand per seat for 12 months. Totally in par with the priceline in Websphere.
Of course you *could* use Eclipse+Apache+other free stuff. But corporate IT don’t work that way. They buy the package IBM tells them to buy.
LikeLike
This corporate developer doesn’t use RAD ;o)
I code in MyEclipse & deploy to Tomcat (local dev. environment) and WAS 5.1 for staging and production.
It’s one thing to buy Websphere for your server farms, quite another to buy the associated development tools for all your coders.
LikeLike
Ben: Good for you. I hope more corps will follow.
Here it is very absurd. I did some calculations and found out that a Websphere application costs about 20 to 50 TIMES more than a Domino application with the pricing we have. And that is only based on hard costs (Databases etc). Not “Domino is more RAD hence cheaper”.
The customers pay for their own IT-maintenance and frankly don’t give a f. if there’s J2EE or Domino under that application. The IT-governance people does not approve of Notes/Domino however since it is not J2EE, and only J2EE grok (we all now that story right :-). But as said, they don’t pay the bills.
LikeLike
Patrix: A lot of organisations are using JBoss or Tomcat for production sites.
Though I am WAS Dev Enterprise certified, I prefer the leaner approach a lot.
LikeLike
For me the huge barrier to entry to Java has been the attitude of the Java developer community. If they would actually document what to do with the tools, explain how all the pieces fit together, and take some time to build a community instead of an ivory tower, it would go a long way toward wider acceptance. I download Eclipse about every quarter and when I try to do anything with it I realize why I deleted it the last time.
My problem with using Java from Notes/Domino is that, as Patrix said, it just isn’t well integrated. Sure you can use Java in a few places, but it’s difficult, tedious, and you pretty much have to use external tools unless you’re a Java guru already.
Once Domino gets better integration with Java I’ll use it. Until then I really don’t have the time to try to force a square peg into a round hole. I’m not opposed to Java at all, I just need it to be a bit easier to work with.
LikeLike