Survey: Is LotusScript a Legacy Language?

In the comments to my post I wished I'd not posted about LotusScript last week, somebody wrote:

Quit trying to sell customers programs written in BASIC. You might as well be sending them documentation written with crayons.

While I agree in essence that it's doing customers no real long-term favours writing code in LotusScript, the choice over what to use (if there's a choice at all!) is rarely a simple one.

A few days later I posted another LotusScript-based entry. I expected no interest in it, but was pleasantly surprised how much interest there was. Makes me wonder if LotusScript really is a relic of a dead language.

Time for a survey.

Cast Your Vote

Is LotusScript Still Relevant?


    • avatar
    • Shean P McManus
    • Wed 6 Feb 2013 07:33 AM

    I'm a classic Notes developer who has been working in xPages for the past year. That being said, I do have a ton of LS in my applications that while they may be considered "legacy" are still running useful production code. Just yesterday I wrote a quick script to report on some duplicate data in an application. Quick and easy it was the right tool for that job. We all have power tools that can drive in a screw but sometimes a old fashioned screwdriver is the quicker and easier tool for the job.

  1. In my job I have investigated a number of Domino server crashes. In the majority of them where the crash has originated from code within an application (as opposed to 3rd party .dll based crashes) the fault has lain with the Java code.

    The problem stems from the Java versions. Something you seem to have come across in the past as well.

    Personally I would say that if you need to interact with applications outside Domino (manipulating graphics, communication to other websites/servers, etc.) then use Java otherwise stick with LotusScript. You can still have object oriented structure without the risk of servers crashing around your ears.

      • avatar
      • Jake Howlett
      • Wed 6 Feb 2013 07:56 AM

      "..if you need to interact with applications outside Domino (manipulating graphics, communication to other websites/servers, etc.) then use Java otherwise stick with LotusScript"

      That's pretty much exactly how I approach it.

    • avatar
    • Wayne
    • Wed 6 Feb 2013 08:24 AM

    I'm not writing code to "sell", I'm building internal apps to help with work process and replacing "spreadsheet" applications. As such, there are plenty of examples, and LS features that will cover the majority of what I need to do, plus, as crappy as it is, the Lotus Script debugger is my friend.

    I'm learning Java, slowly, mostly because I have an interest in composite apps and it would be nice to integrate some of those great open source projects and libraries, but the Java ecosystem has it's own overheads, and not having a debugger in the Designer did not help either.

    Sometimes "legacy" is another time for "it's still working"

    1. Java does have a debugger in designer, at least for agents and xpages, I haven't done any Composite Apps so I'm not sure about those, but I have a feeling there is a way to connect the debugger to them.

  2. When I'm calling code from XPages or writing managed beans I write Java. If I'm writing a scheduled agent or a migration / fixup agent, I use LotusScript. Even though I'm getting more proficient in Java, I find LotusScript quicker to write and easier to get right.

    Having said that, I do find that since using Java and managed beans I'm more willing to use custom classes in LotusScript.

      • avatar
      • Jake Howlett
      • Wed 6 Feb 2013 09:51 AM

      Same here. It wasn't until I ventured in to C# and Java that I grew the balls to write my own classes.

  3. LotusScript is still a useful tool sometimes, but there's no denying that it's just a poor language. Java isn't perfect, but it's better and it lets you be a more-productive programmer. I'll be happy when I leave LotusScript behind forever.

  4. I don't like the term legacy, I prefer "Classic". I like classic because that's what it is. Wing Commander was a "Classic" game. It still works, but it hasn't aged well compared to some new games. If you're working with the Notes Client the LotusScript is still very relevant. It's your bread and butter and always will be for the Notes Client.

    If you're working in XPages then LotusScript is a lot less relevant, but still has uses. Like an aging sports hero it's not the key player that it once was.

    In XPages you should be using Server Side JavaScript to start. That's the "LotusScript" of Xpages. But it's so much better then LotusScript ever could or will be. You should try to avoid calling a LotusScript agent when you save an XPages doc. It's doable if you need it but it's a mistake to try and use LotusScript with XPages. Possibly the one exception is if you have a LOT of logic in Script Libraries that you can't convert to SSJS or Java right away.

    But here's the thing, do NOT stop learning with SSJS. You want your final destination to be Java. Java sucked in Notes Client. You could only use it in Agents. So few people learned to use that. There was no incentive to use Java in Client apps. XPages is different. You can use Java everywhere! This is not to say that you need to use Java to build an XPages application. You don't. But Java and these Managed Beans is a really really good place to put your logic. Wouldn't it be nice to have a LotusScript custom Object that could live between changing forms? Just be Global? Well that's what Java Beans are in XPages. It's a really good and powerful way to work.

    Even in the XPages world LotusScript is still used for scheduled agents. But that might actually not be needed at some point now that we have DOTS - which appear to be much faster and more powerful then agents.

  5. There's a lot to be said for constancy. Most of the problems I've encountered with Domino - especially the newer Java based Notes Client, have been due to Java. Lotus Script has it's gotcha's but they are pretty well documented, thanks to those like you Jake who keep such information online.

    As Dragon indicates, the rather constant change in Java versions causes a lot of problems. When you adopt a third party frame work, you adopt all of the problems it has today and all of the problems it will have tomorrow. I suspect this is why many long time developers create their own frameworks - as you shared with your Document classes the other day. If it's your job and reputation on the line, you become risk averse and take in hand the tools which are least likely to embarrass you.

    That said, my last project was powered in the main by LotusScript but had some Java, and mostly ran on my own tag library system (build in LotusScript with Java implemented where performance bottlenecks were occurring with LS implementations of Base64 encoding, URL decoding / Encoding and web POST / GET requests). However - my next project is pure Java, JSP, Javascript as I'm working on an application that runs in Websphere Portal Server. I'm inheriting not only all of the Portal server and Websphere application server baggage and issues, but those of the developers who have been modifying it for my client before me and those who have departed that I am taking over for. So in this case, I have to use Java and take the problems that come with all this baggage in stride.

    So for those of us who can't be choosy, use the tools available and /or required to the best of your ability and worry not about the age of the technology. COBAL, I will note, is still in serious and reliable use - 30 years on.

    • avatar
    • Brian Miller
    • Wed 6 Feb 2013 09:57 AM

    Keep in mind that Java itself is now on the downswing. This is part of the reason why you're seeing so much Javascript on the server side: Node.js, and etc. People are desperate for an enterprise solution that isn't Java.

  6. While I mostly maintain Notes databases, and occasionally do new ones, I still love LotusScript.

    It gets the job done, like it has for the past (close to) 20 years. I don't see any reason whatsoever to switch to something else when writing Notes (Client) applications.

    Of course, when doing Domino development, for browser clients, I use JavaScript in the front end. Tried XPages, but found it's not my cup of tea.

    My advice: as long as you feel comfortable with any language, stick with it. Don't switch because 'they' tell you you have to. Basic is just another language, no religion!

  7. I can't comment on Brian's comment about Java in the enterprise but I have started to use Node.js on a new project and I have to say its pretty damn good.

    I had a free choice on what technology stack to use and for my requirements a highly scale able and free server technology which allows me to write the whole of my application in javascript is quite a win.

    Theres something about writing your logic in sublime text 2 - hitting save and having your local node instance auto restart and the browser page auto refresh - all within a few ms, brings a smile to my face.

      • avatar
      • Jake Howlett
      • Wed 6 Feb 2013 11:12 AM

      Must play with node.js...

      Hide the rest of this thread

      1. Jake, any time spent with Node.JS yet? If so, how did you find it? I like the node concept, but have serious concerns over an interpreted javascript server language vs. a (psuedo) compiled lang like java. Node is being 'sold' on non-blocking performance, which sounds 'fair' in principle, but in practice? Can a single-threaded ie: running on a single-core interpreted server really perform better?

        Love to hear from anybody who can offer benchmarks and a bit of insight on this...!

  8. One of the reasons that some people choose Java is that "It's a lot easier to find a Java programmer than it is to find a LotusScript programmer." Well, I think we all know the fallacy here, but I'll say it anyhow: if you find a LotusScript programmer, s/he knows Lotus; but if you find a Java programmer, odds are s/he doesn't. Unfortunately, decisions aren't always made rationally.

    The truth is that LotusScript is an adequate language for most tasks, and it's safer than Java even in the hands of the most talented Java developers. But Java offers access to a far richer set of classes, tools, and generic talent than LotusScript ever did or can ever hope to. For any project that has a lot of tentacles and is expected to have a very long life, finding resources from the small subset of Java programmers who do know Lotus is the best approach.

    • avatar
    • Harald Reisinger
    • Wed 6 Feb 2013 02:44 PM

    It is not the language that makes the code, it is the programmer behind.

    There are many good and bad examples in both Java and LotusScript. I've seen Java-Agents with hundreds of codelines in the main method, as well as niceley structured OOP-LotusScript code. Additionally, if you count in Formula-Language it gets even more funnier.

    My answer to Jakes question is: it depends ... :D

    Personally I like the superior Java-IDE, so I tend to write more Java-Code / Managed-Beans. SSJS is also nice, but IBM - why this horrible Code-Editor ....

    • avatar
    • Mike McP
    • Wed 6 Feb 2013 02:49 PM

    Since I don't sell code, the language I choose fits my business needs. I've used JAVA in Notes agents when needed well before Xpages was even a thing. Much like "Social", I'm dabbling in Xpages, but letting it mature, then will see if it meets my needs.

    Russell Maher has an interesting post today that shows part of the xpages dilemma. He has a new pictorial showing the tools recommended to write Xpages code (DOJO, JQuery, Tomcat, etc). That's fine and dandy, but Notes has built a foundation on quick development for almost any user. That's a niche that is still largely unserved by other development platforms. We previously had a half dozen folks developing apps at the company I'm at now, because it was that easy. Now, nobody dares try to write an Xpage...their first 404 and they're left clueless.

    If I'm learning additional techs just to keep developing on a locked-in IBM platform, I really need to sit down and take a hard look at the alternatives to see what advantages IBM has over the plethora of alternatives. I'm not saying there are no advantages, but it's something I need to look at.

  9. I find myself using Java as soon as there is a back-end-only application - scheduled agents, that kind of thing.

    Apart from obvious cases where Java is the only possibilty (network, complex regexes) I enjoy the superior IDE and the possibility to do Test Based Development thanks to the awesome JUnit. I tried for a while to use something similar with Lotusscript but found it to be too much of a hassle.

    Java is good in that it forces me to write OO, but I find it annoyingly verbose Button button = new Button(), anyone? and some aspects just make me cringe - the whole int/Integer/autoboxing nonsense just seems soooo unnecessary, and honestly I haven't really had the use to do more than simple, one-level inheritance (i.e. genericPerson vs HappyPerson, SadPerson, etc)

    Arguably, as well, I think the quality onus we have vis-a-vis clients should not be a question of language but one of professionalism: in other words, making sure that you are delivering code that will be easy to read and to maintain in the future. And, once you have accepted this as the main point, it's things like structure, architecture, and documentation which are important, not the actual language.

    Many client applications I am maintaining have been done terribly sloppily, and a lot of my job is making these old things clean again - removing redundancies, making a better separation between business logic and presentation (which is a fancy way of saying 'getting rid of code squirreled away in buttons on the form', and starting using classes.

    Lotusscript (especially since the new editor came in which enabled you to properly edit classes) enables you to do program almost as well and cleanly as any other OO (although the lack of extensibility of the base classes is annoying, as are the occasional holes such as not being able to create an empty NotesDocumentCollection)

    I do admint to getting in a flutter when thinking that I am an expert about a dying subject and will find myself useless in a couple of years but then I always tell myself that there are a number of skills I have (which you also have) which are more important: i.e. customer skills, knowing how to structure a program, knowing how to test, those things.

    For me the far bigger threat is that Notes Development is still something where a single person can develop a whole application single-handedly, and I am sweating to think of an altenative technology where that is also the case. Alternative technologies seem to me to be so complex that one can really only start with a small group of persons. In my limited visibility that certainly seems to be the case with Websphere and Sharepoint. Potentially .NET is better. I would welcome a discussion on this.

    1. "Button button = new Button()" - I hate this shit so much.

    2. A massive, enormous DITTO !!!

      Take a look at 'groovy' - A lot of that hideous syntax is gone and it runs on the JVM.

      I don't (yet) know how to integrate groovy with domino/xpages/dots but that could be very interesting: all the power of java, all the simplicity of lotusScript.

      Don't we all just wish that someone, somewhere will consolidate all these divergent technologies and give us the tools we really want, in one integrated package? It used to be Domino, but these days its sort of Domino, plus a dozen extras lashed together to get anything usable.

      I'm both thrilled at the possibilities and depressed at the rate of change and sheer size of the task to build apps these days.

      We must be mad to put up with it!!

    • avatar
    • Jan Van Puyvelde
    • Thu 7 Feb 2013 04:38 AM

    >> not being able to create an empty NotesDocumentCollection

    Wasn't that fixed? If not, there are workarounds (as you most probably know).

      • avatar
      • Jake Howlett
      • Thu 7 Feb 2013 04:40 AM

      In the past I think I've done this to get an empty one:

      database.GetAllProfileDocuments("foo") *

      * or whatever the method is actually called.

      Show the rest of this thread

  10. I wouldn't worry about what other people comment - some people are just pillocks or want to make an impression. Perhaps they thought they were being funny? I've always enjoyed your Blogs even if I don't always understand them. After all you can't cater to all abilities in every Post. I am trying to get to grips with Lotusscript but it is an interest thing rather than a job-related thing so you can keep them coming as they are usefuul as examples that I can learn from.

    • avatar
    • joel david
    • Thu 28 Feb 2013 08:55 AM

    Lotus Script is only used in Lotus Notes applications, and it works only in Lotus Notes. If someone expects to hire lotus notes developers they should expect them to maintain lotus notes apps that use lotus script. Traditional Java developers will never work in lotus notes, thats for sure. Only some Lotus Notes developers try to use Java out of their own interest.

    It doesn't really matter if lotus script is legacy. If it is, then lotus notes is legacy too.

    • avatar
    • Phil Jones
    • Fri 1 Nov 2013 07:01 AM

    I also don't sell code, but create and maintain internal applications. I use LS, possibly because I've never learnt Java, but probably because I sort of think in LS.

    I also use @Formula a fair bit, but I'm proud to say I haven't used "Evaluate" for yonks! :-)

    I'm currently writing LotusScript to create PDF quotation documents in Chinese from an internal Notes form completed in English. It works, it's fast, and it's reliable.

Your Comments


Let's Get Social

About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content