obligatory reference: https://thedailywtf.com/articles/a_case_of_the_mumps

Well, try to run C++, C# or Java on a PDP-7 or PDP-9.

In 1976, the year of the first standard, massive hospitals with thousands of patients run on MUMPS, on PDP machines with 8K to 24K of core memory and many concurrent users.

I don't think anyone is really blaming MUMPS for the limitations it had to work with 1970s tech. The story was more about how terrible it is to work with in the 2000s and the surprising fact that it's still in use today in certain niches.

My project and the referenced primer are about the 1976 standard.

But many MUMPS based systems are still in operation and maintenance today; and not many significant systems in IT reach a 50 year lifetime.

A modern JavaScript, PHP or Python system (languages with similar limitations for large-scale software engineering as MUMPS) written five years ago hardly works today because dependencies significantly changed or are no longer available. In 50 years (or even in 10) it will be astronomically expensive to keep a current Node.js system alive. But you still can run an unmodified 1985 MUMPS system on a current InterSystems IRIS server.

The main problem with critical MUMPS systems today is less technical, but mostly staff shortage. The same applies to COBOL, or Ada, or even Java.

> A modern JavaScript, PHP or Python system written five years ago hardly works today because dependencies significantly changed

thats why the best practices are version locking and containers. your dependencies cant change from under you when its pinned to a specific hash. the only way it can break is if npm or pypi shuts down and nobody including you has an archive which is extremely unlikely.

and you can run a oci image in 50 years unmodified unless linux stops development decides to break userspace and theres no working translation layer for the next system. even if it becomes obsolete the spec is still there and someone will build a "docker on future runtime X" if they need it.

What about running that same codebase on open source versions of mumps such as GT.M or Yottadb?

This article is terrible and I hate that people always bring it up whenever MUMPS is mentioned here.

MUMPS is easy to read, understand and maintain when written well.

These examples (and the Wikipedia ones) are from code written when hospitals needed to run their whole EMR with extreme storage constraints, so more terse code was necessary to fit more on the disk. Of course they aren’t readable by modern standards.

The problem with MUMPS (and RPG) is that there's so much legacy code written in the old style that you have to learn to read and write it anyway.

Dude, chill.

That article is humor, not an essay on the merits of MUMPS.

It was entertaining to read for me back in the day, especially as my first programming job was on a COBOL system from the 80s. That in the mid 2000s.

A while ago I made an interactive demonstration of how encoding with factoradic works https://ilcavero.github.io/ seems like I found someone else who thought it was a fun thing to demo

I made this recently to demo the concepts of Lehmer codes and factoradic number system. Built using scalajs and laminar.

full economic collapse happened in Venezuela and it didn't loosen the authoritarian grip

Or Cuba, PRNK, ...

In my organization AppDynamics' reputation couldn't be worse, they could never deliver on their promises even after months of consultancy, never ending back and forth with support to fix what ended up being a network issue on their side, in the case of my team they caused 2 P1 production incidents with their buggy agents. And that's without mentioning their slow UI. Wouldn't recommend this to anyone, we hacked together in a few weeks a solution with graphite/grafana that runs circles around it. Perhaps they have more value for client facing systems because otherwise I cannot understand how they are still in business.

akka/erlang actors are not equivalent to go routines, a closer concurrency mechanism would be futures/tasks

See .NET Core implementation with tasks :)

Count me in as somebody with taste that knows something about film and finds this movie a waste of talent. The real Kubrick underrated masterworks are paths of glory and the killing.

looks like oh-my-zsh

I was looking on doing the same but ended up doing some hackish bash script, as in:

byobu new-session -d; byobu split-window -d; byobu split-window -dh; byobu

Getting it to run a command automatically on each panel got too complicated so I settled on that. (byobu is a preconfigured tmux from ubuntu)

this one of the many examples of the anti-intellectualism that is so pervasive in the software development scene. Are the inflexible, detail-prescripting methodologies he describes any good? of course not, but I haven't seen a single seriously used methodology be like that in real life unless it fell on the hands of negligent/incompetent management and/or engineers.

You are lucky if you've never seen a methodology misused or misapplied. I have seen it many times, in my own work experience and in the failed projects I've taken over.

I'm not sure how you got the idea that I'm anti-intellectual. My intention was to express my own opinions and experience and start a discussion. I wasn't trying to wave anything away.

There's a difference between enterprise IT and other environments. For example, if you are a government tax department, your agenda is driven by legislative changes, and you want a fairly rigid process to ensure that things are done accurately and correctly.

How else do you characterize an industry that seems content to re-learn lessons of the past over and over?

1) Industries don't learn; people do. We have a lot of turnover and growth in this industry, so a lot of new people. 2) Although there are high points of genius we may never reach again (Turing, etc), we are making progress. Software today can do things hardly imagined a few decades ago. 3) Part of how we make progress is to try "unlearning" things; throw out conventional wisdom and try something "crazy". Maybe it will fail the same way as before, or maybe this time it will work. Maybe the constraints that produced the conventional wisdom have changed. 4) People problems will always be hard, in every industry. Productivity is a people problem.

I am against a general ignorance of where the industry's been, which manifests as a refusal to learn basic software engineering concepts that are laid out in a book like the Mythical Man Month. Seems like every new medium (such as the web) starts with masses rallying around a figurehead who proclaims "this time it's different! We don't need any of that engineering stuff!" A few years later, they do.

This trend of anti-intellectualism is worrying. I doubt it's new -- Dijkstra had similar sentiments -- but the worst part is the developers who seem to enjoy being ignorant.

It seems like almost all professions have a body of knowledge. Software Engineering doesn't.

Imagine getting open heart surgery, your chest is open, and doctors start arguing over the best methodology to do it.

This is not a fair analogy. Open heart surgery is a repetitive and well-defined procedure with clear goals and context. Software Engineering is a complex and creative endeavour where individual talent makes a big difference. There is no methodology that will help a mediocre writer produce a great novel. It takes skill and talent.

This is exactly why software engineering needs to professionalize.

I don't see developers always having more leverage than their business counterparts. Really, I'd love to see developers wholly accountable to their peers, along with some sort of entrance exam. I think the world at large would take developers a bit more seriously.

It does, and it has for quite some time: http://www.computer.org/portal/web/swebok

OMG. I just hope you are being sarcastic.

That's everything we are complaining about right there on the index.

No sarcasm intended. You don't have to agree with SEI or IEEE, but the complaint was that there wasn't an organized body of knowledge. My response was to show that there is.

I'd be interested in knowing what you find so objectionable about SWEBOK.

Actually, there are surprisingly large and persistent differences between hospitals in their complication rates for various surgeries. It is fueling a debate about how to evaluate them and how to promote the methodologies of the more effective places. Not really all that different from the software industry.