One of the leading benefits of ObjectScript is the speed and efficiency it allows for an experienced developer. Let's look at an example of how you can benefit from ObjectScript today.
Suppose you have a class that stores the names of your users. We'll call the class Data.User, and give it a string property Name. Next, we will need a method to create a new user or update an existing one. A naive, simplistic approach might look like this example:
ClassMethod UpdateOrCreateUser(id, name) As %String
{
if ('$data(name)){
quit "Name required"
}
if ($data(id)){
set user = ##class(Data.User).%OpenId(id)
}
else{
set user = ##class(Data.User).%New()
}
if ('user){
quit "User not found"
}
set user.Name = name
set status = user.%Save()
if (status '= 1){
quit "Error saving"
}
else{
quit "User saved"
}
}
The problem with this approach is it's too wordy and drawn out. It takes a lot of time typing the code, the variable names, the curly braces, and when you're done, a trivial piece of code takes up half the screen on your monitor. Luckily, ObjectScript empowers the developers to streamline the process, and cut out the unnecessary fluff. Let's take a look at how an experienced developer can rewrite the messy code to a much cleaner result:
ClassMethod CRUDUser(id, name) As %String
{
q:'$d(name) "Name required"
s x = $s($d(id):##class(Data.User).%OpenId(id),1:##class(Data.User).%New()) i 'x q "User not found"
s x.Name = name q $s(x.%Save()=1:"User saved",1:"Error saving")
}
And that's it! With only three lines of code, look at what ObjectScript can accomplish. You don't need a dual monitor computer setup just to read the code. And because we cut out all the unnecessary wording, you don't even need mouse, or a scroll wheel, or copy/paste functionality, or resizing application windows. If you're comfortable developing powerful applications using nothing more than a monochrome 80 column x 24 line display with a simple keyboard, an 8Mhz processor and a 720KB floppy disk, then you can take full advantage of ObjectScript to maximize your productivity.
Now there might be some newcomers who have trouble reading your optimized code. And when the time comes to adapt the application for new requirements, other developers may find it easier to rewrite the code completely, rather than trying to decypher your hand crafted one-liners. And you might even have difficulty following your own code a few years later! But nothing else comes close to putting so much powerful functionality in so little space!
Disclaimer: As hopefully everyone reading has realized by now, this article is satire. As a courtesy to your fellow developers and coworkers, do not write code that looks like the shortened version full of abbreviations and one-liners. While it may initially save you some typing and mouse clicking, it wastes much more time when someone other than yourself has to maintain and update such code. The condensed code is harder to read and follow, and therefore is a good candidate for write once and throw away later code.
With expanding / compressing code I Studio [ <ctrl>E, <ctrl><shift>E ] this is all history
I will admit - I was taken by how persuasive the tone was and was planning a rebuttal until I got to the last paragraph. Well done Igor :)
Haha!
A good one, thanks, Igor! I also added ObjectScirpt highlighting - it helps in reading.
Personally I find the
q:'$d(name) "Name required"not very unreadable.quit:'$data(name) "Name Required"is better, of course.
But the second one is ... Mostly due to several ##class() stuff.Several ##class can be eliminated, making the code shorter and
readablewritable better:ClassMethod CRUDUser(id, name) As %String { q:'$d(name) "Name required" s x=$classmethod("Data.User",$s($g(id)="":"%New",1:"%OpenId"),$g(id)) q:'x "User not found" s x.Name=name q $s(x.%Save()=1:"User saved",1:"Error saving") }One of my stylistic peeves is that parentheses around an if condition are not necessary, and I prefer to omit them for readability. You'll often need parens for a function call and/or to evaluate operators correctly, so best not to clutter the code with a superfluous pair.
There is at least one case where this encoding style is acceptable - it is a generator method. Just look at the code generated by &sql() or CSP, for example.
No wonder there are two versions for javascript libraries: for the developer and for production (processed by the minimizer).
At first sight it might be very cool to have code for methods in a few lines. It is the way of programming we had in the past times. I can't recommend to use this way of coding, because it makes it very hard to read and understand the logic of code. I grew up with this kind of coding so I am very familiar with this but I am happy that Caché gives me the way to code in a modern style. When I look into my old programs, which consist of this kind of coding, then I always feel to read ugly code. I would like to change it immediately. Forget it to compact the code in one line. Put it into more lines and avoid postconditionals. If-statements are more readable and you don't have to think about what the code will do.
Nice satiric article
Now we have the year 2020 (but I will discard this year from my life because of Covid-19) but our loved COS wasn't in this year nor in the very past years invented.
COS (better, the predecessor, M ) has more then 50 years under his belt, it was created in the late sixties - in a time, where RAM was rare, expensive and therefore it was measured in units of kilobyte!
If I recall correctly, at end of the seventies, we had some customers on a PDP-11/34 with less then 64KB of memory, one or two 2kb partitions and some "big" partitions with 4KB or 6KB, the rest was for disk buffers (512 byte each) and DEC's V4b (which acted as OS, database and language interpreter).
Hence the ability of COS for excessive abbreviations and if you get an old routine, written by an old school programmer (like me) then you will see there (mostly) abbreviated commands, postconditions and (local-/globalvariable, label and routine) names, consisting just a few letters (one to three, maybe four).
Unfortunately, this (abbreviated commands, short names) happens to me in this days too - you know, old habits never die.
There is a wonderful (and at the same time a horrific) example of such a routine: one letter names, everything abbreviated:
https://stackoverflow.com/questions/4151554/need-mumps-sample-code/4430996
clock ;; a digital clock from ;; https://stackoverflow.com/questions/4151554/need-mumps-sample-code/4430996 ;; Q N R,Q,C,D,E,W,B,G,H,S,T,U,V,F,L,P,N,J,A S N=$G(N),Q='N,F=Q+Q,P=F+F,W=$L($T(Q)) S W=$E(W,Q),S='N_+N,W=W-F*S,L=$G(L),R=$C(Q_F_P),R(F)=$C(F+Q_F),R(P)=$C(W-F) W # S T=$E($T(Q+F),F,W\S)_$C(W+S+F) X T S B=$P(T,$C(P_P),F),C=B\(W*W),D=B-(C*W*W)\W F G=S-Q:F:S+F+Q S E=B-(C*W*W+(D*W)),H=$E($T(Q),G),@H=$S(@H<S:'Q,Q:N)_@H,T=C_D_E F A=Q:Q:W\S S J=$E(T,A),C(F)=$S(J>(F+Q)&(J<(S-F)):Q,Q:+N),C(P)=$S(J#F:Q,Q:+N) D .S C(Q)=$S(J<(S-F):+N,Q:Q),C(F+Q)=$S(J>Q&(J<(S-F))&(J'=(P+'L))&(J'=(P)):Q,Q:+N) .S H('L)=L F S H(N?.E)=$O(C(H('$G(N)))) Q:H('+L)=L S F(A,H('L))=C(H(W[(W\S))) F U=Q:Q:P W !,R F V=Q:Q:P+F W $S(F(V,U):'Q,Q:$C(P_(W\S))) W:'(V#F) $C('N_F_F+F) W !!,R(F)_C_R(P)_D_R(P)_E_R(F) X $RE($E($T(Q),Q+F,P+Q))_R(P)_'N W # G:N=L Q+F QIt's not only tricky to read but has an attractive form too
It almost reminds me of a language called APL that I learnt while I was being an Actuary. it was an entirely symbolic language designed to manipulate 2 or 3 dimensional tables for Actuarial Life Tables. I loved it. You could write an entire program in about 10 minutes and then spend 2 weeks explaining what the code means afterwards
Nigel
Oh, dear!
I saw something similar ~'86 running on VAX/VMS (or was it RSX-11/M ?) with some specialised keyboard