Beyond The Yellow Bubble

Peter, your Lotusscript skills will transition reasonably to Xpages. And it's not like agents are going away any time soon.

When Xpages are supported in the client, there's no particular reason to think you're going to get one thing versus another except that the paradigms will be extremely similar to Xpages for web clients. Except "server-side Javascript" will really be backend executed scripts before they're rendered. The "server" in that case will be the Notes client on the local machine, somewhat similar to DOLS.

I know you're very embedded in Lotusscript OO, so let me ask you a question: why aren't you writing all the same code in Java instead? Is there a reason besides syntax? Because if you're writing LS in OO, then the syntax differences are trivial.

Nathan,

I don't know Peter's reason, but mine is quite simple: There are no front-end classes for Java!

If they were, I would switch to Java(nearly) immediatly, because IMHO Java is the superior language:
overloading methods, concurrent programming, infinite number of libraries/APIs, etc.

Thomas

My distinct preference would be to program a Notes applications in as few languages as possible. But where is IBM heading? LotusScript, Java, or now JavaScript? If IBM are going to invest in the JavaScript language and make it possible to do everything I can do in LotusScript and Java I am probably going to want to go down that path.

Why not Java? LotusScript came first and has always met my needs. Plus I have and IDE and debugger that works fairly well and an object model that allows me to invoke LotusScript from almost any event. PLUS most of the people I work with also use LotusScript.

Applications written in Notes 1 still run... they just look like applications written in Notes 1. IBM almost never gets rid of anything, but they do allow certain things to stagnate. So, as far as having "the choice of staying with what we know", I'd say that's fairly likely. For example, when LotusScript arrived in R4, they didn't get rid of Formula (and, more than a decade later, still haven't), but there have been far more advancements in LotusScript since then than there have been in Formula... but they still occasionally add useful features to it (i.e. all the new iterative functions added in R6).

So if I had to make a wild guess, it'd be that future versions will include more noticeable and frequent enhancements to support for Java and JavaScript than for LotusScript and Formula, but that the latter will still occasionally get new features. Anything else would be a departure from the way that they've approached forward compatibility thus far.

@Thomas - That's an excellent reason to stay with Lotusscript and would be an excellent reason to switch.

@Peter - The Lotusscript IDE in Designer is notably superior to the Java IDE in Designer. BUT the Java IDE in Eclipse is vastly superior to the Lotusscript IDE in Designer. This will largely remain the case even after we get the new LS editor, since the Java editor and compiler allow for some impressive flexibility in warning and error control, along with code templating.

Please understand, I have written more Lotusscript in the last 10 years than I care to consider. I *dream* in Lotusscript. But since I've transitioned out of writing procedural LS almost 100% (I'll still dash off some straight line code in an Agent now and then,) Java just ends up being more and more appealing.

If you're wondering about the appeal, I have just two words for you: optional parameters. :-)

The functional stuff is what makes javascript rock. I assume that class-based OO is forthcoming as Javascript 2 (ECMAScript 4) is implemented but first class functions, anonymous functions and closures are the powerful stuff. Java will only be getting some of this in the next major version.

Java optional parameters? Lotusscript doesn't have them but python is the optional/named/default parameter ninja master ;-)

Once the javascript engine is running client side, the Eclipse/Expeditor APIs should be available, perhaps with a high level wrapper to handle threading and reduce the cruft. Seems that that would be a great time for IBM to implement the Notes UI objects too...I just don't see them doing it for any remaining native UI in reparented Eclipse windows.

This conversation is starting to chafe my NDA. :-)

Dan, I would encourage you to test first-class functions and anonymous functions in the server-side Javascript context in 8.5. I believe the Xpages servlet engine completely contains the interpreter, which is how they can include all that extra syntax that's non-standard JS, such as @functions and Lotusscript object references. Because of this, I'm not entirely sure to what extent the more advanced Javascript features are available, since ultimately, whatever you script in there is actually executed by Java.

So, if you put @DbLookup(@DbName, "View", "key", 3) in the Xpages script editor, that gets parsed and what ends up actually running on the server is a View.getAllEntriesByKey() in the Java servlet. I've seen the source code for this -- Philippe and I sat together and found a bug in it. (It wouldn't return multiple matches for the same value in an array result -- effectively performing an @Unique every time.)

Anyway, so since all the script code you enter is actually parsed and executed by Java, rather than an actual Javascript package on the server, we should probably all be cautious about assumptions on the exact execution of that Javascript, prior to testing it.

@Tim "IBM almost never gets rid of anything, but they do allow certain things to stagnate".... 100% RIGHT and that's what worries me perhaps more than anything.

@Language - I can do some things really well as these run very fast. Still many places where this is the only alternative (e.g. field validation). The language is not really being extended, but it is often what starts most novices down the Notes development path.

LotusScript - Grew as a language in Notes 4 & Notes 5 but have has largely stagnated since. I still can't program half the form events in LS. Many things remain locked behind the API. And it has fallen behind other languages for OOP support. This seems to be the language where most Notes developers gather.

Java - Still does not have the same methods/properties/classses as LotusScript nor does it have a strong following amongst Notes developers.

JavaScript - No OOP. The support for DOM and @Languages still very patch at this stage. Outside of X-Pages native support of JavaScript (especially for Notes client) is patchy.

DXL - It is still not possible to export and import a some components of a Notes database as XML.

CSS - There is still only a few aspects of Notes applications which can be styles via style sheets.

So what are the chances with an increased emphasis on JavaScript that IBM are ever going to do one thing well (in Notes)? I expect IBM will try to play catchup with JavaScript during 2008/2009 at the expense of everything else leaving developers with no single programming language able to do anything especially well. I would settle for "best of breed" (or close to it) with one programming language rather than having to deal with half-baked solutions in several programming languages/technologies. Without this, it is very hard to make the case that Notes is a strategic application development environment.

Just our of curiosity. You are really writing all your code in the Declarations section?
At least that seems to be the consequence for OO Lotusscript development. I am not a developer so please excuse me if I get something wrong here.

I'm NDA free. No Chafing here. Permission to speak freely ;)

I do get that the javascript is executed on the JVM. It's the same as Rhino (javascript), Jython, JRuby, Scala etc. They all also have server side web frameworks. This is common and I'm familiar with the Rhino and Jython implementations. I Use Jython every day as an interactive shell for the JVM including the Domino APIs.

The special syntax is there because IBM wrote the javascript engine so they can add any non standard syntax they like. I hope they don't plan on extending non standard syntax. The @Functions would be just fine without the @. : @Functions were in that other product that shall not be named three years ago...I think just to lure Domino developers with something familiar. It smells too much of proprietary. "Just hire javascript programmers". I hope that's the case...Frankenscript programmers will be harder to find.

Executed by java means executed by the JVM as bytecode, same as any other JVM language. The script is interpreted or compiled (Rhino has both options) ultimately as bytecode though the interpreter may have it's own intermediate code. Since XPages javascript can call Java classes directly, again like other JVM languages, the @Functions can just call any Java API like the example you gave. The javascript language itself is most likely compiled to bytecode. Implementing language features not supported by java is not a problem...bytecode is the target language (the assembler if you will). You are not constrained by the Java language. Unlike the @Functions, and javascript functions calling JAVA APIS in general, java source never comes into play. The apparent ability to mix javascript and java source, not just API calls, is something I'll have to look into. Is it just tight integration like Groovy or is it more like javascript as an internal DSL, or did I misread that?

I'll get an 8.5 server going this weekend and check some specific features but I expect that all the javascript language features will be there for the supported version *whatever that may be*. I know they have some of the proposed JS2 features like optional type declarations. And what about the cool XPath references, are they still there? Looks like July 4 is XPages day for me.

I don't think you need to worry about LS going away if only for the need to keep Notes & Domino backward compatible which IBM have done a pretty good job of.

Come to think about it, didn't this new functionality come about as the result of IBM buying out someone? If this is the case, IBM didn't even choose the language, and there was zero chance it was going to be in LotusScript initially.

I've been writing LotusScript for about 10 years and when it comes to anything more than simple pieces of code I prefer to write in classes. And when that happens I will occasionally get annoyed at how LS doesn't allow you to write like a proper OO language and then I usually switch to java. You're right, LS is essential if you are writing apps for the Notes client and i suspect that will never change. But only being able to write LS effectively locks you into always writing Notes client apps which may not be so bad if that's what you like.

For me, learning java was tough to begin but was so worth it. Javascript is almost trivially easy and is an essential language for developers today so is also worth knowing. Also especially with the use of one of the numerous JS libraries springing up everywhere you can now write web apps with much richer (and less restrictive) interfaces than you can easily achieve via the Notes client - and without needing to be able to write very much JS at all! If you have all 3 of these languages then you can pretty much choose whichever language is best for a given situation which is pretty great.

@Henning, yes this does mean writing a lot of code in Declarations section of LotusScript library. That is part of the reason for the .Domino Framework - to cut down on the amount of new code that needs to be written in this section. It is also the reason why a lot of Notes developers are desperate for the new eclipse designer to provide a LotusScript editor that allows navigation through classes, methods, and properties.