Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:Oh the pain... (Score 1) 166

There was no structure. There is no "database" the code _is_ the database. I learned enough MUMPS in order to understand what I was looking at and what I could see was a system (I use the term loosely) that was made up of a disparate bunch of arrays with no conventions, arbitrarily duplicated and messy with no design or plan in sight. I'm quite comfortable with object stores and I learn fast, love data and I revel new challenges. In the project in question we'd already successfully and happily integrated around 20 legacy systems written in all sorts of different languages and using all sorts of data storage. I can honestly say, I've NEVER seen a bigger heap of crap than that MUMPS system. As it happened, I wasn't the poor sod who was tasked with the actual integration, just the "smart" person sent to see if it was possible. Based on what I saw, my advice to management was to ditch it and re-write the app as the overall requirements were small compared to the morass of crap an integrator would have to deal with. Last I heard, the company had had three or four failed attempts to integrate this product and eventually it got killed off completely.

Comment Oh the pain... (Score 5, Interesting) 166

I was unlucky enough to have to advise how best to integrate a cobbled-together creaking MUMPS system into a more modern healthcare environment where the business wanted to "use SQL" to write reports against the data in the MUMPS system... of course the ancients who wrote the MUMPS system had done so with a complete disregard for maintenance and extensibility. NOTHING in the system was well thought out... in fact it looked a lot like a bunch of programming novices had just added a crap-ton of data in attribute/value pairs in no particular structure over a period spanning many years with each individual change being in complete isolation because the authors did not understand what had gone on before. It was also sadly really easy to copy/paste vast tracts of code along with the persistent storage bit so guess what the novices I mentioned earlier did? Yup, they copied and pasted a bunch. Now while this distasteful in any language, consider how much this hurts when it's in effect your actual data storage you're copying and pasting along with the code Furthermore... the authors had used every shorthand short-cut in the book because they hated typing (and the reader apparently). I can honestly say I'd rather debug befunge in my head than work with anything remotely related to MUMPS, M or Cache every again. From what I saw, the system was a write-once/read-never data soup that had no place in the GP practice management software that had been written in it. The system held fairly small amounts of data in bloody idiotic structures that were impossible to read without writing more MUMPS. All the business was trying to do with it was print a few letters and government forms... something ANY SQL database along with a report writer would have handled in a much simpler, cheaper and more maintainable manner. *shudder*

Comment Re:North Pole (Score 1) 496

I think you'll find that the previous poster didn't specify accurate measurements in miles, but rather "approximate" miles. I therefore also used an approximation of "3 and a bit" being "approximately 2 minus approximately 1" multiplied by PI. This was my point, his numbers were wrong. You'd have to start closer than two miles away from the pole to end up with a circumnavigation of a mile. With all that in mind, you sir can kiss my arse for your insulting tone and lack of good humour.

Comment Re:North Pole (Score 1) 496

if you walk from a position 2 miles away from the south pole in a southerly direction for one mile so that you are approximately 1 mile from the pole, then the distance "around the world" as you put it will be nearer three miles than one sir because a circle around the pole with a one mile radius will be 3 and a bit miles in circumference.

Comment Wow this was a waste of paper... (Score 1) 486

The research tells us that repeatedly concatenating strings together is a bad thing... WE ALREADY KNOW THIS!!! good grief, who taught these guys to code? The title of their paper "When In-Memory Computing is Slower than Heavy Disk Usage" implies heavy disk access where none exists. They actually go on to point out that it's the OS doing magic things that helps out. i.e. it's the OS using RAM to buffer the disk that keeps your app speedy. So erm... memory being used instead of disk then... the exact opposite of their claims

COMPASS [for the CDC-6000 series] is the sort of assembler one expects from a corporation whose president codes in octal. -- J.N. Gray