So, I can't debug for shiat, but I've chosen to become a computer science major...

I apparently either can't apply the same logic in "the stove hurts, so I won't press my hand down on one" to daily life, or I just hate myself more than I'll ever hate anything else. The latter is a justifiable conclusion in any case.

Ahhh yes, the joys of wrestling with compilers. You're on the front porch of Computer Science Club at the moment. Once they let you in the door, you'll being into theory like algorithm analysis.... No more debugging lines of code, but a whole lotta calculus II....

99 little bugs in the code
99 little bugs in the code
take one down, patch it around...

127 little bugs in the code...

_________________

Haha! Sounds like my 9 to 5..... It's never a dull moment in the world of MUMPS programming.

Here was the last "line" of code that I wrote in the course of my day. This was what we refer to as a "One-Liner" or, a "one line FOR loop".

F I=1:0 Q:'$O(^AUPNPAT("D",I)) S J=I S I=$O(^AUPNPAT("D",I)) S X=$O(^AUPNPAT("D",J,0)) I X S Y=$O(^AUPNPAT("D",J,X)) I (Y)&&(X'=Y) S COUNT=COUNT+1 W "DUPLICATE FOUND. MRN '"_J_"' IS HELD BY '"_$P(^DPT(X,0),U,1)_"' AND '"_$P(^DPT(Y,0),U,1)_"'",

I basically wrote it to prove a point.

... What black language is this?

That is the Dark Speech of Massachusetts General Hospital Utility Multi-Programming System or MUMPS for short. It is a language that found its beginnings at the Massachusetts General Hospital and has faded in and out since then. Lately it's seen a renaissance by InterSystems, and is currently the most prevalent language and database schema for Health Information and Financial Systems (banks, Ameritrade, etc). I could go into more specifics... But typing chapters on my OnePlus isn't what I would define as a "good time." If you can smell what I'm cooking.....

The above code was handcrafted by yours truly to look for instances of duplicate MRN (Medical Record Numbers) across all patients within the database. It found 2500!! I was working with the Radiology Supervisor at a hospital and we were running into issues with PowerScribe for dictations, due to duplicate MRNs. She talked to the Medical Records Supervisor who said something to the effect of "you need to export the entire patient list and then import it into Excel and sort and blah blah blah...." When the Radiology Sup called me to ask if I saw that reply I was like "hold on.... I'm almost done..."

Export to Excel my bum!

I'll stick with Perl and Java, thank you.

_________________

I remember when I was first learning this language, I was working on an elaborate set of VBS scripts that wrote to and pulled drive mapping data from unused fields in Active Directory. After about three weeks of that, I sat down to write some MUMPS code and couldn't even remember how to compile the darn thing...I was so lost, the only thing I could think of was VBScript and C (not C++, I was thinking writeln, not c.out)...

MUMPS is like Haitian Creole of programming language .

I like that a lot of the more popular languages are C-like. If you know the syntax of one, you can pick up the syntax of another pretty easily.

There are the outliers though... like FORTRAN. *shudders*

_________________

Yep, there is definitely a comfort in working with the C-style languages; C, PHP, NWScript and then you have the more obscure languages like Cobol, Fortran, MUMPS, LISP, and so on.

Wait a minute.... Write and Writeln were statements in PASCAL, werent they? Shoot... We need a meta-language that combines the syntax and intricacies of all languages, then I wouldn't have to try to remember how to handle whichever language is pit in front of me at that moment.....

...and call it Babel! (Microsoft will rename it to B#, of course).

The compiler would be insane.

_________________

The most complicated thing I've coded recently is a Star Trek star system generator. Yes, really.

A friend of mine convinced me to help her with it... so I had to teach myself PHP in an afternoon. Luckily(?), the most I really did was make sure the math was coded properly and worked. She did all the web interfacing, etc.

Here's a piece of it, simply generating mass, density, gravity, and radius for different planetary classes:

_________________

Very very cool! What's the application for?

It reminds me of the old TradeWars 2002 game from (way) back in the day. Ever play that one?

I had once upon a time ran a BBS, and that game, of course, was added first and foremost. When you first initialized the game, it would procedurally build a random galaxy which was essentially sectors that were linked together. So every TW2002 game was different. On top of that, I believe the players could build planets, but I can't recall 100% if that is the case.

I miss the old BBS days. Those were good times, yes'er'ee...

Ah yes BBS days. I remember wasting many, many hours on ISCABBS.

The script above is basically for a Star Trek RP game. We call it a "sim", but it's more or less collaborative fanfiction. (Though with unique characters and etc.) When there's need for a planetary system either as a function of plot, or for a character background, we can hit a button and generate one.

Never did play Tradewars; I didn't get into that type of game until WAY late. Played a few MUDs and the like in the late 90s.

_________________

I've got one word for ya, two phonemes:

Fido...Net...!

FidoNet was like the pony express compared to the internet, but it was awesome having access to these message groups from around the world and to able to see it move from one BBS to another, usually once per day when one BBS calls another and does a data transfer. Purely magical to my little teenage heart...



Oh yes, I believe that you've mentioned this before. Very cool. Always nice to be able to whip a planet outta your pocket on demand! :-O



Never really got into the MUDS personally. That's quite remarkable when I think of that, given my extensive history and or inventory of first and second edition AD&D crap. I've still managed to hold onto all of that, even though I lost my entire hardcover book collection to a leaky shed and a tote full of mold. Death Gate, Shanara, Covenant, etc. No Tolkien....again, surprising. But I've atoned for that tragedy already...

I loved me some Death Gate!

Dude, I have boxes of AD&D stuff. 1st Ed stuff from my father-in-law, too. He played with his Army buddies in the late 70s. Quite a bit Forgotten Realms, Dragon Mountain, Underdark box set, and literally a tote full of modules.

MUDs were different, from what I remember... I never really saw a connection to D&D, except just as another way to RP/Adventure. Though I must confess, I didn't do a lot in the way of MUDing anyway... at the time, Talkers were more my speed.

_________________

Phew! What a day....what a day.

Spent the morning teaching the self some basic winsock programming with the goal being to write a TCP/IP interface into a MUMPS box so that I can create Windows applications that can access that data. In that endeavor, I was successful.

The rest of the day was spent WTF'ing over what happens to those packets once they make it into the database. I've gone back and forth over what to do once I can get data into and out of the system. At first I figured I would use the existing XWB framework (RPC and M2M Brokers) developed by the VA in the 90's, since it works and has a lot of features. However, those were developed to target Delphi API's, so I may spend more time recreating the wheel there so that I can utilize it in C++. So the other option is create my own broker, from the ground up. It'll be the YAM Broker (Yet Another MUMPS Broker), utilizing YAMB for a namespace. The problem there is that I may spend a lot of time recreating the wheel in regards to packet and data manipulation. So there is the dilemma.

A few more steps before I can start work on my PACS....

And I really don't want to use the BMX brokers. Writing SQL calls to access a MUMPS DB is beyond ridiculous and shows how little the application developers that I am working with actually know. "Eww...I don't want to learn MUMPS...I was to use SQL and VB to develop enterprise level healthcare applications.... " Flipping pansies, can't even statically link a library to an executable. Ugh..I hate knowing more than the clowns that get paid 4x my wage yet couldn't code a "Hello World" if it wasn't drag and drop.....

Beer. Must.....find....beer....



.....and pizza!

10 Print "Hello World!"
20 Goto 10

_________________

f i=99:-1:1 w !,i," bottle",$S(i=1:"",1:"s"), " of beer on the wall, ",i," bottle",$S(i=1:"",1:"s")," of beer.",!,"Take one down, pass it around, ", i-1," bottle",$S(i=2:"",1:"s")," of beer on the wall.",!


That's my "status" message on Lync (@ work)

Made awesome progress today! I came up with another idea this morning for interfacing into this system. Create a client and a server application. The server executable of course would reside on a MUMPS server. Client and server obviously communicate, and then there is a command in MUMPS that can be run to execute and external command on the host, including the ability to pass arguments and return values to the code. Simply loop this and check for incoming messages every x number of seconds. Take the message as input into the MUMPS code, and pass the return values back. I've written this code to do a byte-wise compare of two files....

Then I got to work, and tried one of the existing methods and made some mad progress. I managed to successfully connect, pass the system login message, and authenticate with my credentials into the server. There I stopped because the encryption isn't adding up, so until I can decode that piece, there I stay.

However, now that I really hash out my first idea, that really seems to be a lot cleaner and may be much easier to implement. Using TCP in and out of this system is ugly at best, and requires a lot of mapping of decimal to octal and weird format of characters in specific sequences. There also seems to be a lot of arbitrary numbers that don't seem to make much sense.

I almost forgot, in order to make part deux happen today, I ended up writing a quick application to basically listen for incoming connections and display all data. Pretty cool. I'll need that ability when I really get elbows deep into HL7 programming, which isn't far off. I'll be writing an interface real soon and saving $30,000 which is what they would have paid a contractor to do it.

Actual development is awesome. Dealing with people that say "it doesn't work" isn't.

O.o *boggles*

I could recognize some of that. I'm just a lowly hobbyist over here.

_________________

ZEPP;; WOC/ZAM. ;;19 NOV 2015
;;ENTRY POINT FOR ZEPP'S BASIC LOOP
10
;
W "HELLO WORLD",!

20
;
D 10

Nonsense. "Professionals" are just paid hobbyists. The irony in your quote is, well, ironic. Most of what deal with now, MUMPS, DICOM, , HL7, and 90% of the code in the whole darn system was created by "non-computer" people. It was all developed and conceived by doctors originally. And the funny thing is that, especially with DICOM, it mimics most fundamental of communication handshakes and protocols. I believe the former was created without prior knowledge of the latter. And when I'm talking about DICOM, I mean the transport protocol not the file format (ambiguity can be a pain)

Well, I know my skill level is nowhere near yours; I'd probably take one look at what you're doing and...



I mean, I've done file handlers, I've manipulated data... but once you get into specific protocols/resources, then it's beyond me.

_________________