The Truth as I See It: Part 1
This post is part one in a series.
Choice of programming language is always a hot topic in the Yellowverse. Precisely because we have so many options available to us, language zealotry can be the stuff of endless debate. As we look forward to the next evolutions in Notes/Domino, there will be even more choices, some of which will completely and forever change the way applications should be built.
Personally, I've always been confused by arguments over language choice. Usually some pragmatist will step in and say something like "you should use the best language for the job at hand," and I inevitably find myself thinking "isn't the definition of 'best' precisely what's at issue here?" After all, how do you decide what's "best?" You need a measuring stick to evaluate all the subtle differences between behavior of various languages in context. A quip like "for each language according to its abilities, to each project according to its needs" doesn't really help us understand how to weigh those abilities and needs. (Incidentally, that's the same underlying problem with "from each according to his abilities, to each according to his needs.")
So what should our measuring stick be? That is, as developers, what should be our main priorities when evaluating one language (or platform or framework or toolset) over another?
Most developers set their priority to the most obvious option: productivity. People prefer to code to what they already know, because it means they can see immediate results. If you can write something in 2 days with Lotusscript, but would need 2 weeks to do it in Java, then your decision is likely to be based on whether you're willing to take an extra 8 days to get your result.
Other possible priorities include: performance, standardization, portability, availability, simplicity, popularity, usability, longevity, stability, and plain ol' laziness. Believe it or not, I think every one of these is a great criteria for evaluating available options. Languages and toolsets can dictate a lot about...
whether the software will scale
whether or not it meets industry standards
whether it runs on a variety of systems
whether it can run in your desired context
whether it involves a lot of code or a little
whether you can find people who are skilled with it
whether it creates a positive user experience
whether it will still work in 5 or 10 years
whether it's likely to fail in unanticipated circumstances
whether you have to work hard to get your result
In the 17 years I've been doing software development and systems design, I've decided that my number one priority is: maintainability. This probably flies in the face of what readers here would think. I have a history of showing demonstrations and tutorials that have a lot of detailed steps to follow. Given that I've spoken at Lotusphere 4 times on user interface design, one might think that I would hold the resulting experience of the software as the most important issue. That's not the case. It's more like 2nd or 3rd on the list.
For me, nothing is more important than having someone else be able to open up the code, go "ah, okay... that's how this works" and be able to make adjustments to meet future requirements while keeping the fundamental design in place. That's one of the reasons all the Lotusscript I write these days is in OO. (And make no mistake, writing object Lotusscript is pretty much writing in a different language than writing procedural Lotusscript.) I have always had positive feedback from other developers that working with a class base I created is a lot like simply working with the native product classes. Well-designed contracts for your classes make it very easy for them to be understood and used by other people.
Domino. unfortunately, has a long history of being a hack-tastic platform when it comes to maintainability. Many basic concepts of code reuse, abstraction and consistently fly out the window on the platform. You can't pick just one language, or one dev standard, or one abstraction model. That's one of the reasons it's hard for people to get into Domino development from scratch. You use Java in an agent, but not in a view event. You can use Lotusscript in a view event, but not in a view column. You can use @Formula in a view column, but not in an onKeyPress event. You can use Javascript in an onKeyPress event, but not in an agent.
Over the coming weeks, I plan to post a series of articles on writing maintainable code. And I'm going to combine this with another series I've been meaning to do on emergent technologies on the Notes/Domino platform -- specifically Xpages and Expeditor -- by talking about how these new capabilities provide us with new dangers and new opportunities to create solutions that last.
I hope you'll tune in and participate.
Comments
Posted by Andrew Pollack At 09:14:31 PM On 07/20/2008 |
Posted by Rob McDonagh At 09:16:10 PM On 07/20/2008 |
I'll freely admit: very little. A few smaller things here and there, but nothing even remotely on the scale of what I've done in Domino.
Does that change my ability to evaluate whether a given piece of code on THIS platform is an unmaintainable mess? Please rest assured, I intend to give copious examples of what I'm talking about.
I even intend to use an approach of yours as a negative example.
Posted by Nathan T. Freeman At 09:40:46 PM On 07/20/2008 |
See, any platform has its hidden code, its backword hacks, and its oddball workarounds.
Visual Studio can be a nightmare in terms of figuring out where the code is that does what you want. That's pretty much all objects (not quite, but nearly) and yet the class structure it pre-builds for you and the IDE lend themselves to tucking bits of code right on the UI.
Javascript can be notoriously bad for it. Perl? Gack, its like reading regex. Anything built on the J2EE platforms?
The real issue is that people want to compare "Domino" as a development platform when in fact its closer to a operating system. It has services (smtp, indexing, caching, memory management, hardware isolation, directory services, etc..) and it has file storage, network access, and so on. You build within it. If you step back and squint a little, its fairly easy to see a comparison of a "DOMINO" server with a "Linux" server (if you include the packages in the linux drop).
Agents == Shell Scripts
Documents == Files
SMTP == SMTP
NAB == (various directory and user systems availabe in linux)
ACLS == File Rights
You can go on and on and on that way. So yeah, you can bury a lot of code in wierd places in Domino. But don't compare it with Java -- that doesn't even have a data storage mechanism of its own. Its hardly comperablel. You can compare Lotusscript with Java or C ---but in fact its closer to Javascript.
I think if you open the requirement wide enough to include all of the things a Domino server provides -- or if you narrow your scope to include just the scripting languages that are a fair comparison, you'll find Domino code comes out quite favorably.
Posted by Andrew Pollack At 11:17:49 PM On 07/20/2008 |
IMHO the biggest barriers to developers learning the N/D platform is (1) you HAVE to learn multiple languages to be able to build a fully-capable app and (2) they are "new" languages for most:
@Formula - a must, obviously, if for no other reason than views. Since views are your main lookup mechanism into DB data (and view are UI mechanisims in many cases as well) you've simply got to know them. @Formulas rock in many ways. They're ultra-terse (arguably as good as cutting-edge languages like Ruby in that regard). But it's not OO and code reuse gets clunky quick.
LotusScript - Most of your Notes-client UI hooks only work with this language. Better learn it if you want to write Notes client code.
If you're only developing for the web, you can ditch the LS requirement and replace it with Java (or Javascript in many cases once 8.5 is out).
Posted by Erik Brooks At 01:04:02 PM On 07/21/2008 |
Its not domino specific. I've seen no bigger Java project, which does not suffer major parts, that have serious maintainability issues, though its exactly understanding of design patterns and those frameworks like spring that really have a huge potential in supporting this maintainability thing.
And: Self-written Multi-Threading stuff did cause difficult to track issues in 3 out of 3 projects that were having such. And in 3 out of 3 cases there has been allways a developer who declared self-written multi-threading stuff as actually being simple, "once you have grasped the concept". Its clearly not.
Java/J2EE/EE5 has a potential to make code that tackles complex problems more maintainable. Of course not automatically. It requires experience and awareness of maintainability issues from developers/architects.
The main reasons for maintainability problem in Domino projects are from my experience:
a) history -> projects from 98/99/00 often use really smart (without irony) hacks, that are difficult to reverse engineer today, because they are not needed anyway as there are simpler ways to tackle the problem.
b) the many Admins and noobs recruted for some software development adventures. Experienced Domino developers do nearly allways think a lot about maitainability. Ocasional developers can't for obvious reasons. Still to many responsibles for software project management are not aware of the subjects importance and complexity.
Posted by axel At 06:43:24 AM On 07/21/2008 |
The only way you can have choice at all is to learn and understand multiple languages. Otherwise the world gets broken down to "this one language I know, and all these others I don't know". In that case, the one you know will always win.
Posted by Julian Robichaux At 09:05:19 AM On 07/21/2008 |
Looking forward to the next post Mr Balls!
Posted by Tony Palmer At 09:37:24 PM On 07/20/2008 |
Looking forward to the series.
Posted by Dan Sickles At 10:00:56 PM On 07/20/2008 |
Posted by Rob McDonagh At 09:32:35 PM On 07/20/2008 |
Posted by Nathan T. Freeman At 07:09:43 AM On 07/21/2008 |
Posted by Alan Lepofsky At 01:52:20 PM On 07/25/2008 |