On Monday, January 28, 2013 11:57:11 PM UTC, Marcel wrote:
>
>
> I think Eric's idea for writing a Mumps interpreter isn't a bad idea. I 
> looked over the wikipedia pages for this language and it doesn't seem very 
> complex at all. I don't have an intimate understanding of the language but 
> it seems possible to write a source-to-source transformation into JS as a 
> weekend project. Seems like this would drastically reduce the complexity of 
> your infrastructure, and you get all the speed and research that went into 
> v8. 
>

Actually I'd not recommend that much time is spent doing this, for several 
reasons:

1) The quality of Mumps language coding in most legacy healthcare 
applications leaves quite a bit to be desired!  I've discussed the reasons 
for this in one of my postings:

http://robtweed.wordpress.com/2012/10/21/a-case-of-the-mumps/

One of my goals is to improve the quality of coding in Mumps-based 
healthcare applications.  That isn't going to happen if the dreadful 
patterns of the past are proliferated by automated code conversion - I'd 
really not like to see crap Javascript coming out of this exercise!

2) Mumps shares something else in common with Javascript: it has good 
parts, but an awful lot of terrible parts.  Whilst a modern developer can 
stick to the good parts of the Mumps language and write respectable code, 
in the past this hasn't been the case.  So, in converting legacy code, 
you're going to come across the challenge of converting some language 
constructs that are at best weird, and at worst downright crazy.  I'm 
thinking of such things as "naked global references", wanton use of 
indirection for global names and subscripts, the baffling $truth variable, 
and even the dreaded GoTo command....and that's before you have to figure 
out how to deal with the poor (often non-existent) discipline of legacy 
Mumps developers when it comes to variable scoping.

All this crazy Mumps stuff (and I can assure you there's lots more!) will 
just drive you nuts and waste a lot of time that will be best expended in a 
controlled replacement of existing Mumps code.  Abstraction of existing 
Mumps code using the ability to invoke Mumps functions from within 
Javascript is, in my opinion, the way to go - bury that nasty old Mumps 
legacy stuff inside Javascript calls and let it wither on the vine over 
time.

Rob

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to