Beyond The Yellow Bubble

Over the years I have given a lot of thought to programming languages, especially as they relate to Lotus Notes development.  I blog about it a lot.  Yes Nathan I'm hitting them all over the head with a stick again....  I have expressed my frustration at the lack of development of the LotusScript language that is core to so many Notes applications.  I have wondered about the lack of penetration of Java into the Notes development world.  And lately I have been asking the question why SSJS and do we need yet another programming language in Notes?    So just what is the best programming language for Notes?
:
The Case For LotusScript
Some may view me as something of a LotusScript biggot.  I love the language and what it allows me to do with Notes.  Basic was the first language I ever used.  It was so easy to understand I taught myself by simply reading other people's code and experimenting.  There was a time when LotusScript was more advanced than Microsoft's VBA but now it has fallen lightyears behind VB.Net.  It is popular in Notes because so many people find it (relatively) easy to learn.  It is popular because it can be used almost anywhere inside Notes applications (except View selection formulae, hide-when formulae and a few other spots).  It is popular because so many applications are already built with LotusScript as its core.  And finally with 8.5.1 we have a half-decent editor for LotusScript.
:
The Case For Java
In many ways Java is a superior language to LotusScript.  It provides vastly superior support for Object Oriented Programming.  It comes with an extensive library (framework).  It is also one of the most popular programming languages.  Two of the things that have been attributed to holding back Java in Notes (access to Notes UI classes and a decent editor) have both been provided in 8.5.1.  And yet.....  despite all this I do not expect to see a significant momentum towards Java anytime soon (outside of Eclipse, Expeditor, Plug-In development etc.).
:
The Case For Server Sided JavaScript
This is a completely new language, so why bother given I have all my existing code is in LotusScript, Java, @Commands (or a combination of all three)?  Well for one thing it is presently the only language supported directly by XPages.  There are ways to execute Java code and even more obscure ways to execute LotusScript code but I don't see these being very practical.  So if you wish to develop Xpages you have little choice.  And if you don't wish to develop with XPages you have little chance to use SSJS at the moment either!   One of the key reasons to consider SSJS  is that this seems to be where IBM is investing most of its time and effort on program language development for the forseeable future.  But perhaps the most compelling reason (at least for me) is that when all things are said and done SSJS is probably the best match for Lotus Notes than any of the other programming language choices.
:
Yes you did read that right.  The LotusScript flunkie is actually suggesting SSJS may be a better fit for Notes development than his beloved LotusScript.  I have done a lot of SSJS programming over the past six weeks and the more I use it the more I like it.  I have begun to realize the complexity in using SSJS is not with the SSJS language itself but rather learning to understand the complexities of Xpages. SSJS is not vastly different to LotusScript but it allows me to do things I could only dream about with LS.  There are still areas left for improvement but if IBM are focusing on this language there is more chance these will be fixed than any of the 100+ ideas for LS posted on IdeaJam.
:
One of the key reasons I like JavaScript so much is that it is built on objects (and remember I am an OOP).  Until recently I thought it was a weakness that JavaScript was so loosely typed.  Now this seems to be such an asset.  And this seems to fit in so well with whole Notes concept.  Documents as a collection of fields that may or may not be present in any one document and may or may not be of the same data type in every document.  Documents copied and pasted en-mass from one database to another (when allowed).  Views that may contain a collection of doccuments of different types whose only association may be they share a few fields with the same name (if at all).  And yes, love it or hate it there are none of those foreign key constraints that stop me adding whatever document I want to my database.  And replicas of each database created just about everywhere just in case... In an ordered world of tightly defined tables with fixed columns, column types, key constraints and nullable fields a tightly structured language such as Java makes perfect sense.  And C# with its interfaces, sealed classes, abstract classes, partial classes etc. is well suited to projects with 10+ developers.  In the unstructured world of almost anything goes just get the application out the door as quickly as you can  Mr/Ms. sole developer, multi-tasking Notes programmer -- a language such as SSJS seems to be an almost perfect fit.  And not just for the minority of us who write OOP with Notes.  For procedural programmers we have the nifty ability to invoke many of the @Functions as a standard part of SJS language.  The bous for SSJS is that it shares the basic syntax with JavaScript, the dominant language for Web client programming.  So after a while you get used to placing those braces around all your compound statements and you remember that different casing means a different variable/functions.
:
 To put it simply, there is a reason we have many programming languages.  Each has its own style.  Each its own strengths (and weaknesses).  The style I see in SSJS seems a very natural fit for Notes and a great many (but certainly not all) of the developers who are attracted to Notes.
:
Of course it is not a clear cut as switching from one language to another.  We still have all those legacy apps to maintain.  And there is no sign of SSJS being supported in any of the Notes Classic design elements or even agents real soon.  So that leaves XPages, and the rub with that is for the Notes client, XPages really does not (yet) offer much outside of a glorified embedded browser (I can see the hate mail on this already!)....  But that is today.  IBM have already indicated that they plan to extend XPages to provide Notes client control.  When they do, that opens up the chances of doing some Notes client development with SSJS.  And hopfeully some time soon we will get some sort of clear indication whether or not IBM plan to provide a single programming language that can be used anywhere across the product.  Because as much as I now appreciate SSJS I still see little value in investing too much effort into it outside of Web Client or (possibly) dual client applications.  Until I can build the majority of my apps with XPages alone or SSJS is supported in all the design elements I need, it is difficult to find a compelling reason to consider using two programming languages (plus some @Commands here and there).  So the challenge is very much there for IBM so make some sense with the programming languages it supports.  Can IBM afford to let LotusScript slowly die before it has established a viable alternative?  Do LotusScript and Notes classic design elements need an extension to make them more like SSJS & XPages to tide us over until the transition is complete?  Is it OK that I like hot-dogs without mustard but would still kill for a meat pie with sauce.....
:
Related Posts
Programming Language - Does It Matter?
LotusScript v JavaScript
Does LotusScript Have A Future
LotusScript Revamp (20 Things I'd Like To See)

This may be just Kindergarten but our teacher gave us a pretty lengthy required reading list to work on now and for later when we continue on to first grade..  Apparently those of us intending to focus on developing XPages for the Notes client when 8.5.1 is release have been instructed to use the same reading list until we are told to do otherwise...  Those people who have already done a lot of Web development will probably have a lot of these already.  Notes client developers have a LOT of reading to do...

Kindergarten

1. HTML - XPages provides a number of great controls but there is still a lot missing.  Those gaps will often be plugged with you own HTML.  When debugging XPage output it will be essential to be able to read HTML.  A book that explains the differences in the way modern browsers interpret HTML would be especially useful.  There are many on-line resources that can also be used.
   
2. JavaScript - The native JavaScript language is used extensively to script client events.  This same language also provides the basic syntax for server sided JavaScript (SSJS).  Most of your code is going to be JavaScript based, so a mastery of this language is required.
   
3. Dojo - Dojo is the javascript library (framework) that comes with Domino 8.5 and is used as part of XPages.  Dojo extends the capabilities of JavaScript as a language as well as providing a range of widgets (dijits) that can add even more WOW to your XPage applications.  Unfortunately IBM provide very little documentation about Dojo in the Domino Designer help so a reference book is almost essential to get the most out of this technology.
   
4. CSS - Styling of your applications should largely be achieved through CSS.  This language is an art in itself and something each Notes developer needs to develop a thorough understanding if they wish to make their XPage applications attractive and reduce some of the cross-browser issues.  A text that also explains themes would be beneficial as themes are also supported by XPages.
   
5. Xpages - Only joking!  There are no books to be found on XPages.  The oinline help that comes with Domino Designer will leave you underwelmed.  There are a lot of blogs that give very good coverage on your options for Xpages.  These include Declans life, the universe,and everything Xpage tutorial, The Domino Developers wiki, theXpages wiki, and the Xpages Blog.  And don't miss David Leedy's great Notes At Nine videos.  Lets just hope a book gets written soon as this topic is very large and it is impossible to see have its millions of components can be coeverded in depth by anything less than a 500 Kg reference book.
6. SSJS - I have no idea where you may go to get a good understanding about SSJS.  A good knowledge of JavaScript is a start as well as a good working knowledge of Commands and either the COM or LotusScript product classes (NotesDocument etc).  Tim Tripcony as Lotus911 seems to know about as much about SSJS as anyone, so watch his blog closely for tips etc.
   

1st Grade

1. AJAX: XPages makes use of XJAX technology to facilitate asynchronous calls to the server for things such as partial refreshes.  In your 2nd year of XPage applications you may want to build a better understanding of AJAX to embark on bullding more advanced controls and functionality.
   
2. XML A some stage soon after graduating from kindergarten you are likely to be building applications in which data will be passed between data using XML.  A good working knowledge of XML and related technologies such as XPath and XSLT will be helpful.  Remember, at some stage soon XPages will probably allow you to define data sources that draw data from XML files directly.
   
3. JAVA: It seems to me that every time you have to dive off and do anything advanced with SSJS you end up making calls to Java or using instructions that look a lot like Java.  Having a good working knowledge of Java is going to help you out.  e.g. The process of invoking a Web service seems to rely on using some Java-specific components.
   

Note: No specific text books were prescribed.  It was suggested we use Amazon or similar resources to find popular texts.  In time I may get more specific about resources you may want to consider.  For now just find a reasonably good text on each subject.  Readers please feel free to comment on good choices that are above the pack or especially relevant to Notes/Domino...

For Dojo I can recommend the book - Dojo - The Definitive Guide by Matthew Russell (O'Reilly)

Happy Reading everyone....

Application Development has been essential to the survival and growth of the Notes client.  Prior to Notes 8 its was generally felt (and argued loudly at lotusnotessucks) that the Notes client was a vastly inferior offering to MS Outlook.  Despite this Notes held on and appears to be now gaining market share on Outlook.  This was due in no small part  to the inability of Microsoft to provide an alternative to Notes as a RAD tool for applications.  Microsoft also had Visual Basic and the .Net programming languages but still they couldn't win.

With the release of Notes 8.5 and the introduction of XPages, a new discussion has started within the yellowverse about programming languages.   XPages introduces a new offering in Server-Sided Javascript (SSJS) a new language with a syntax similar to JavaScript but also containing references to the @Formula language and the Product classes commonly used within LotusScript (e.g. NotesDatabase and NotesDocument).  As to be expected people are somewhat divided.  Not surprising given the programming world as a whole has never adopted any one single programming language.  The science of programming languages are continuing to evolve.  Object Oriented programming languages such as Java and the .Net family have been very popular of late and probably are still the #1 and #2 languages.  O'Reilly published an article based upon technical book sales which seems to show C# rising and Java falling   PHP and Python are popular in Web development but these no longer seem to be gaining ground.  C/C++, upon which Notes was originally built, is also losing ground.  Ruby is one of the more modern programming languages that are starting to gain ground.  It also appears that JavaScript is gaining in popularity.  Both Ruby and JavaScript support dynamic data types, a feature being seen as superior to strongly typed languages such as Java and C#.  The growth in popularity of JavaScript may be a good sign for the future adoption and success of SSJS.

And so what about LotusScript?  Well LotusScript I liken to Visual Basic and VB.Net.  Not just because they are BASIC-based programming languages but also because they tend to attract people who could be considered "less sophisticated"programmers.  This is an important group to Notes development because they are responsible for putting so many Notes applications on our Domino servers so quickly making it almost impossible for IT department to replace.   Are these people likely to move to Java? - I doubt it, to SSJS? (well maybe) or stick to LotusScript like they did when we were first offered Workplace? (also possible).  Part of that decision is tied to the design elements that also go into creating a Notes Application.  As things stand at the moment with 8.5.0 there is no doubt in my mind that the novice and intermediate Notes developer will produce a Notes application much faster using Forms, Views, Framesets, Outlines, Pages, and Agents.  An advanced programmer will develop a superior Domino Web application using XPages.  Will they be as productive? (apart from Tim Tripcony -  I am not so sure)  And 8.5.1 does bring XPages to the Notes client....  I posted an idea on ideajam suggesting IBM follow the strategy I believe they may already be following, which is focus all future effort on developing SSJS and retire LotusScript.  Hardly scientific but it didn't exactly receive overwhelming support.  Based upon this and many discussions and discussion threads I have to believe the Notes world is divided. 

I have long lamented the lack of support for LotusScript over the years.  But most of all I would love to see a single programming language I can use everywhere within Notes.  One that allows me to do OOP and one that allows me to be productive.  Has IBM made things better now we have SSJS?  We have @language that was the first language that can only be used in some places but is still the only choice for things like view selections formulae,  field validation on forms etc.  LotusScript is probably the most universaly adopted but not supported on client sided Web applications or within XPages.  Java is still limited where it can be used and has never gained wide-spread adoption.  JavaScript is used with client sided Web applications (including XPages) but is only  of limited value for traditional Note client applications.  And now SSJS which is presently only available for server sided XPages scripts.  That's a pretty clear simple and concise programming model right.  One that should be easy to learn, especially if you are a novice or intermediate Notes developer?

So I would put forward a suggestion....  If we are not careful we may end up making this great product simply too difficult and confusing for people to continue to bother?  The number of people able to master them all and hence go on to do really great things may not be enough to cover for a loss of interest in our yellow underbelly. If we are in fact all part  of an elaborate food-chain we might just see the Notes version of an algae bloom which will not only effect the Notes application development environment but the whole Notes eco system that includes Notes Mail, Sametime, Quickr and Connections.  Yes, its true, people can still program in LotusScript and build applications the old way.  But it is the "old" way and getting older by the day.  If it is not modernized without making it overly complex people will find their way to  newer, easier, technologies.  Technologies like Google Gears and Sharepoint already threaten and there are sure to be other new products coming soon.

So what is needed?...  Well I see two distinct strategies possible.  The first (and my preferred) is modeled on what Microsoft did with .Net.  Develop an intermediate language that drives Notes and make all the above languages compile to this base.  This allows people to chose the language of their preference/experience and also opens the door should a language such as Ruby gain popularity.  The other would be to pick a language that best meets the needs of the Notes "core" and then make it available to ALL design elements (not just Xages).  Both options allow a developer (or development team) to focus on a single programming language requiring less learning, greater productivity, and lower cost development.  But clear direction is needed from IBM.  Without it we will all head off in different directions.  Many people will stick with what they know for as long as they can.  We need something major to shake us all and steer us in a common direction.  That might be a design element like XPages should it ever become powerful enough to do everything the other design elements do (or at least 98%), allows us to do it faster,  is "reasonably" easy to learn, and delivers a superior user experience on a Notes client, Web client, and mobile device.   If I have that I wouldn't care what programming language I am using.  Hey, that's the reason why I am a Notes developer and bleed yellow in the first place!

In a recent blog I documented a new DominoBES class that has been added to the .Domino Framework.  Due to a current limitation with LotusScript , this class had to be written in Java.  After doing some experimentation I found a way of abstracting the Java Implementation of the class by "extending" the Java class with a LotusScript class.  In theory this allows me to not only publish a Java class as a LotusScript class but to extend the Java class with additional methods/properties developed using LotusScript.
Why bother?  For one thing it is typically not a good idea to mix and match programming languages in an application as code maintenance then requires a developer with multiple programming language skills.  For another, at the site where I am making use of this class there are about 30 full-time Notes developers and several hundred part-time Notes "developers", almost none of whom program in Java.  By choice I am developing the .Domino Framework using LotusScript  wherever I can and using Java where it makes sense to do so because the pool of Note LotusScript developers greatly exceeds the pool of Notes Java developers. 
The following is the code that can be found in the latest beta version of the .Domino Framework for extending the DominoBES class. (Note: I believe both the LotusScript and Java classes can have the same name)

Option Public
Option Declare
Uselsx "*javacon"
Use "base.Domino.MailServices.BES.java"
Use "Domino.Applications"

' C L A S S    b a s e   D O M I N O   B E S  ___________________________________________________________________________ C L A S S
'/**
' *  Communication with BES Server
'*
' * @author Peter Presnell
' */
Class baseDominoBES As DominoBaseClass
 
 Private JavaSession   As JAVASESSION
 Private  JavaClass    As JAVACLASS
 Private DominoBESJava As JavaObject
 Private MDSHost    As String
 Private MDSPort    As Integer
 '/**
 ' *  Constructor
 ' */ 
 Sub New(),DominoBaseClass("")
  Dim ApplicationSettings As New DominoApplicationSettings(Nothing)
  
  Set JavaSession = New JAVASESSION()
  Set JavaClass = JavaSession.GetClass("DominoBES")
  Set DominoBESJava = JavaClass.CreateObject()
  
  MDSHost$ = ApplicationSettings.BESServer$
  MDSPort% = ApplicationSettings.BESPort%
  
 End Sub
 '/**
 ' *  Push a browser channel to a Blackberry device.  Displays one of two icons on application menu that link to a designated URL opened in teh BB browser.
 ' *
 ' * @param Email     The email name of the blackberry user
 ' * @param PushURL    The URL to be launched when the icon is selected
 ' * @param UnreadIconURL  URL for the icon to be displayed until the BB user selects the icon
 ' * @param ReadiconURL  URL for the icon to be displayed after te BB user selects the icon
 ' * @param PushID     A unique ID to represent this channel on the BB device
 ' * @param PushTitle    Text displayed along with the icons for the channel
 ' */  
 Sub BrowserChannelPush(Email As String,PushURL As String, UnreadIconURL As String, ReadIconURL As String, PushID As String, PushTitle As String)
  Call DominoBEsJava.browserChannelPush(MDSHost$,MDSPort%,Email$,PushURL$,UnreadIconURL,ReadIconURL,PushID$,PushTitle$)
 End Sub
 
End Class

I am now in the process of extending the .Domino Framerwork to support the publishing of Notes applications on a Blackberry client.  A new DominoBES class has been added as a way of allowing Notes applications to communicate with a Blackberry device via the Blackberry Enterprise Server (BES).  Unlike the rest of the framework, this class has been developed in Java due to the need to send an HTTP POST request.  The first method - browserChannelPush (see below) provides a wrapper for executing a Channel Push, effectively adding an icon to the Blackberry device, which when selected invokes the nominated URL.

One of the things that struck me when I attended my first C# programming class was the fact that the instructor was often switching between code examples written in either c# or VB.Net.  These two languages had evolved in such a way that in many ways they had become the same.  This means programmers in one language can more easily adapt to develop/maintain code in the other.  This started me thinking about the opportunity to write Notes applications in such a way that non-Notes developers could better make the transition to develop/maintain LotusScript code.  The same concept also holds true for java, which is not all that different to C#.  The following are some of the coding practices that can be applied to LotusScript to give them a look/feel more like these other programming languages.
Note: The goal here is coding consistency between programming languages.  These suggestions do absolutely nothing to improve the functional nature of the LotusScript code and actually increases the length of the resulting code. 

Object Oriented Programming:
Java, C#, and VB.Net are all examples of object oriented programming languges.  With LotusScript the use of OOP (e.g. classes) is optional.  If you get into the habbit of using OOP when developing Notes applications via LotusScript the chances are the code will be WAY more understandable to a java or .Net developer.  Note: Without a proper class editor for LotusScript it can be a little more painful to maintain code in classes but the pain does subside after a while and a new eclipse editor for LotusScript is not far away...

Error Handling:
LotusScript does not support the try/catch construct found in many modern programming languages, but it is possible to simulate this by adding a non-functional try label at the start of the code and always using catch as the error handling label.  This results in code block similar to the following:-

Try:
    On Error Goto Catch
    .... (normal code)
    Exit Sub
Catch:
   .... (error handling)
    Exit Sub

This concept can be extended to include the optional finally block used for code to be executed after both normal completion or an error.

Try:
    On Error Goto Catch
    .... (normal code)
    Goto Finally
Catch:
    .... (error handling)
    Resume Finally
Finally:
    .... (final code)
    Exit Sub

If... Then... Else
Both java and c# require conditional expressions be enclosed in parenthesese - with LotusScript this is optional.  For consistency make it habbit to use this optional capability of LotusScript.

If (iDocument Is Nothing) Then
    ...
Else
    ...
End If

Method Calls
When invoking a methods (sub or function) with zero parameters in c# or java it is a requirement to place empty parentheses at the end of the method name - with LotusScript this is optional.  Again, for consistency, make it a habbit to use this optional capability of LotusScript.  The use of parentheses helps to make methods distinct from properties.  Note: LotusScript also requires the somewhat redundant Call statement to be used with methods - but thats another story...
Call UIW.ReloadWindow()

Inheritence
Both java and C# support the this statement as a way of referring to methods/properties of the current class.  With VB.Net and LotusScript the equivalent statement is the me statement.  To refer to a property/method in a base/super class that has been overriden in the current class .. notation is used. While it is only ever necessary to use either statement when the same variable/method/property exists in different scopes, it is often a good idea to use either statement to make it clear wherever a method/property defined elsewhere in the class is being invoked.  This also provides a way to minimize the use of variable names like EmployeeName1 to avoid clashes with property names.
If (Me.EmployeeName$ <> EmployeeName$) Then Me.EmployeeName$ = EmployeeName$

If (baseclass..EmployeeName$ <> EmployeeName$) Then baseclass..EmployeeName$ = EmployeeName$