In Swedens capital region they failed with this too. It's dominated by a system that is largely quite well polished but has some scaling issues that has lead to down times. The region decided to develop their own in cooperation with other regions, but instead of just hiring two-three developers and putting them in a room inside some small hospital, they decided to make a Grand Political Project out of it.
Billions of Swedish crowns later, having written ZERO lines of code, they quietly cancelled the entire thing. This enormous boondoggle didn't even make the news because the waste was all man-hours and consultancy, and not a building or something the media found sexy.
I think a big problem is that politicians need Grand Political Projects to get reelected, but that's not how you build software. Or make meaningful small incremental improvements to science, infrastructure, schools, etc. The incentives are wrong...
The UK government tried this, wasted 12.4 billion pounds over 10 years, and ultimately wrote most the project off. The dream of an EHR is just deceptively tricky, so many smart, well-funded, well-connected teams have tried and failed.
I have a friend that has worked on this project for over a very long time and the issue is not that the UK tried to implement EHR records from scratch but rather that GPs (General Practitioner, think local doctors surgeries) had mostly all implemented EHR systems already. The issue is that these systems are created by several (6-8 if memory serves) different private companies and the UK Government can't force the GP to change or adopt a standard system.
The different GP EHR systems record patient information in their own ways. Think of a database entry for chemo medication, one EHR provider having a db column labeled "Drug X" with the patient entry listed as "Yes" with separate columns for dosage, frequency etc. Another will list the drug, dosage and frequency in the same field. Even if they have the same column e.g. frequency, different EHR's may list "5d" or "5 Days". There are also spelling errors, doctor's personal shorthand abbreviations etc.
The problem is that the UK interoperability system has is to implement a safe translation layer that will allow records to be transmitted between these systems that doesn't kill anyone. The astonishing amount of different types of information that are used and all the oversight needed to ensure that information is accurately transferred has made this project way more costly and time consuming that originally thought.
There is, of course, waste and profiteering, both internally to the Government project (huge contract salaries) and also with the private EHR companies (overruns and re-builds are all handsomely paid for).
> The issue is that these systems are created by several (6-8 if memory serves) different private companies and the UK Government can't force the GP to change or adopt a standard system.
Yeah, the UK healthcare system is only mostly nationalized.
I do think these IT issues could be fixed, but only if there was someone at Cabinet level who knew what operations management was, which we're unlikely to get in the forseeable future.
Following the sources listed there, "wrote most of the project off" seems like an overstatement.
> The MPA found that there have been substantial achievements which are now firmly established, such as the Spine, N3 Network, NHSmail, Choose and Book, Secondary Uses Service and Picture Archiving and Communications Service. Their delivery accounts for around two thirds of the £6.4bn money spent so far and they will continue to provide vital support to the NHS. However, the review reported the National Programme for IT has not and cannot deliver to its original intent.
Of the rest of the £12.4bn,
£3.4bn is "expenditure by local NHS
organisations, for example on local IT and
training and ensuring compliance of local
systems with Programme delivered systems", which probably isn't entirely wasted either.
This is a joke. We want to have this but its like everything in germany if its about something digital. Its a fucking mess. Everyone can read it. Most doctors dont use it and even many insurance dont use it... its a fucking mess
Ok, but it’s digitalized, I didn’t say it was good. You can now directly go to an Apotheke with your insurance card and get your medication, even the prescription is digitalized.
Again, this can't be worse than private industry—that profit margin will guarantee this. I guarantee there is some other disease to blame for the waste—probably politicians of some sort invested in industry.
Of course, this does demand citizens give a shit, which seems hopeless at this point.
There is (or was) a public competitor. VistA was largely developed by the federal government. Some organizations still use it and it's available for free, but independent reviews have generally rated it as worse than the private industry products.
I have to wonder how independent those reviews are when medical staff consistently rate it higher than commercial products, the system has won multiple awards, and when the VA tried to implement a commercial replacement it failed.
Vista is public domain, so there’s no money in it and no-one to take management out for expensive lunches.
Interestingly the linked article seems to be singing praises of VistA, though it's unclear whether the author has actually used the system themselves. They link to an unsourced article with that claims it tops reviews, but clicking through to the various related articles seems to have a consistent theme of people not liking VistA all that much.
Again, I don't see how a private industry per se could even possibly be worse given the demand for a profit margin. Your beef is with some other aspect of this process.
the same higher-level forces shape the public project's fate into certain doom that led to hospitals buying the absolutely shittiest tech.
because there's no clear signal (in the private sector there's some drive for sales, market share, profit), only made-up hyperpoliticized bullshit requirements and maybe some barely coherent vision.
as long as there's not a clear technocratic organization with sufficient independence and competence these projects are rudderless yellow duckies on the sea of tragisocial medicine mismanagement madness.
no party involved really has enough resources to deliver something nice. it's like high speed rail in the UK or the US. as a public project it's already stillborn, because it's too expensive to do it right (or if it would get the right amount of funding it immediately attracts unlimited scope creep, and the usual vultures show up, it becomes a typical everything bagel project, solve EMR but also education and childcare and whatnot), and to do it efficiently it would require draconian standardization and heroic amount of data migration work.
and on top it gets over promised and under staffed and so on
I believe the Estonian government has long had at least a basic EHR that they use across their public and private medical facilities that is part of their larger e-government system
Private industry is already worse than the older system of keeping notes with pen and paper. (Source: my mother operated her own medical practice and applied for a government subsidy to switch over to electronic medical records, then complained about how it reduced the functioning of her practice.)
Is it? There's trade-offs of course with everything. There's certainly many aspects in which a medical practice only using pen and paper is worse. How about transferring records to other institutions? Or taking your work home with you? Do you want to lug boxes of records home which may get lost (HIPAA breach) so that you can finish up your notes at home? What about making copies for a patients right to access? What about auditing changes or access to the record to enforce data security, integrity, and compliance?
What's the timeline of evaluation of reducing the functioning of her practice? If it was just a recent change then I would expect growing pains. I have many close personal relationships with healthcare workers and when their electronic health record system is down, having to use pen and paper leads to drastically worse functioning within their job. So the same claim but in the opposite direction. The reality is doing something you're not used to is harder.
In what sense is that an answer to "why were they doing that?" The entirety of the answer does nothing but give a name to the policy. "Why" would usually be understood as a question about the reasons behind the policy.
"The government was subsidizing the abandonment of paper medical records because they had a program in place to do that" is something you knew before you asked the question.
I mean, all industries? The profit margin guarantees this. Anyone who has worked in private industry will verify its utter incompetence in the long term.
Can we talk about particular examples? I know for a fact that in my area private train ticket booking app is vastly better than government one. So at least there is an exception.
> At what point should an acquisition be allowed on the sake of something being able to continue to exist and possibly save jobs?
Never? The entire point of private companies is that they take risk on themselves. If we have to bail them out we might as well just nationalize them. See: the entire american airline industry.
> If would likely take significant research effort to even figure out a way to incorporate the new discoveries into these engines.
What? Have you ever used a solver before? The actual APIs exposed to the user are very simple interfaces that should allow swapping out the backend regardless of the complexity. The idea a new algorithm—short of something like "updating the solution to adjust to a change in data"—would not require any sort of research to slot in as an implementation for the existing interface.
the interface is simple, but modern solvers apply a ton of heuristics that often dramatically reduce problem size, so a naive implementation of a better algorithm that isn't hooked deeply into the core of an existing ilp solver is likely to be very slow
Why would the API expose the heuristics to the user? Because an intelligent user can make minor adjustments and turn certain features on/off to sometimes dramatically increase performance depending on the problem.
From what I gather the parent post is saying that it is easy to make a naive implementation of this improvement, but due to naivety of the implementation it will be slower in practice. Hence it is a lot of work (and thus difficult) to actually put this improvement into practice.
The api interface is simple, but the change would impact the code underneath. Since these are branch and bound algorithms, it would really depend on how often the worst runtime complexity case occurred. If it only happened in 2% of use cases, it might not make a huge difference for example.
In this case, ‘stack-based language’ is used as a term of art. In particular, in programming language discourse the typical meaning of ‘stack-based’ is a language which there’s a stack threaded through successive procedure calls, where access to the values on that stack are accessed by popping them off and computing with them, then returning a result via a push. The stack is implicit and there are often no mechanisms to name values or to name particular locations on the stack, requiring all procedures to explicitly shuffle, rotate, pop, and push the stack to access data for computation.
I would say that languages where values are assigned a ‘name’ in the program text are not ‘stack-based’ in the manner implied by the term. So while C and nearly all other programming language have a stack data structure allocated as storage for values used in procedures/functions, they are not ‘stack-based’.
> In this case, ‘stack-based language’ is used as a term of art.
This is a shitty and broken term. Hence my comment.
> is a language which there’s a stack threaded through successive procedure calls, where access to the values on that stack are accessed by popping them off and computing with them, then returning a result via a push.
You're just describing a procedural language that returns values. I suppose you could also describe a procedural language that doesn't return but what would be the point? You're just describing a form of indirect subroutines that revolve around jumps rather than the natural instruction progression. This has been a wildly unpopular method outside of entering a performance loop for many decades. It knows it will never have to exit/unwind the stack/call any kind of destructor or deallocation callback when entering a non-exiting loop.
Ok so why don't people (you!) just say "concatenative" given that other languages are trivially stack-based as well? How is it surprising at all that it's mostly syntax and a mediocre runtime (as the majority of languages can boast) that differentiates your pet language from other languages? Can we just admit that one of these options has a complex syntax and the other has a trivial syntax?
I’m not sure why my comment elicited such a volatile response, but assuming you are just using emphatic language for effect I will respond.
The main point you made that I can not agree with the characterization of other languages being ‘trivially stack-based’. Other languages in the Algol, ML, Lisp families have stacks that are an implementation detail of their function semantics. In those languages the stack is an implicit storage mechanism that merely holds values which are semantically associated with some ‘variable’ in the program syntax. In ‘stack-based languages’ the stack is, most usually, an explicit semantic construct which acts as the only available value for procedures to act on.
If your primary argument is against the term ‘stack-based’ that’s a personal position, but there are semantic differences between Forth and C, where emphasizing the explicitness of the stack in Forth is a viable point of divergence. As to using the term concatenative to describe a language, I have some opinions on that which fall outside the norm, so I tend to not use it to describe any of the ‘popular’ languages usually lumped under that umbrella.
I don’t know if the ‘pet language’ remark was towards me or in general, but it was certainly baseless if directed at my comment. If it is a general statement, I would only say that it is common for a community to settle on some terminology that they like and it’s rarely out-group pressure that forces a change in that language (see the ‘Alan Kay invented the term Object Oriented and it doesn’t describe C++’ argument that occurs frequently on forums like HN).
> In ‘stack-based languages’ the stack is, most usually, an explicit semantic construct which acts as the only available value for procedures to act on.
To the extent this is true, this is also true of all languages that anyone uses these days—C, JVM, Rust, Chez Scheme, GHC, python, ruby, ocaml, blah blah blah. The only difference is the syntax used to manipulate the stack. Acknowledging that syntax is the main difference from other languages seems key to evangelization. The idea of "implicit/explicit" doesn't really make sense. how do you refer to the stack in forth? You don't. How do you refer to the stack in C? You don't. Both operate with respect to the stack without ever referring to it via syntax. In both languages, the stack is invoked by referring to procedures/words.
Look if you want to keep up this fantasy that forth or factor is somehow more stack-oriented than any other languages, go right ahead. But you're going to fundamentally misunderstand why people use the language. It's the syntax! It was always about syntax. The stack is just a necessary implementation detail to deliver this syntax, same as in every other language that people actually use.
Is there a language which is not stack-based? I imagine "concatenative" would be mildly more precise of a description.
Coroutines (which often carry their own stacks) can sort-of dodge stacks—effectively utilizing a sort of bespoke linear typing to avoid this—but I don't know of a language which doesn't have c-like, stack-based procedures or subroutines, which places arguments on the stack and registers and operates mostly with respect to that stack and foreign API calls.
A stack is certainly the most intuitive data-structure with which to implement a lambda calculus.
Really, what Forth and descendent languages seem to emphasize is a sort of a data-oriented execution rather than a symbol-oriented execution—C very much encourages you to name types, function signatures, etc, and the result if you don't is extremely difficult to parse and interpret manually, even if you can implement forth as a subset of C.
Forth emphasizes reasoning about the stack directly as data, seemingly forgoing any assistance outside of syntax. Arguably it forgoes the utility of syntax, too.
True, it's a convenient structure, but the Church–Rosser theorem says that the order of beta reduction of terms in the lambda calculus doesn't matter, so a call stack pattern isn't essential.
Conceptually, I would say other languages are variable-based. The key feature of a stack is that you can only access the top element, whereas other languages allow you to name multiple things and access them simultaneously (effectively reaching down the stack to elements not directly accessible). This is implemented with a stack-like structure, but sometimes also using registers. I wouldn't call these languages stack-based because the stack is more of an implementation detail than a defining feature of the language.
For isntance, in C:
int x(int a) {
int b = a >> 1;
int c = a + 34;
f(b);
return c;
}
You can still access the variable "b" in the call to "f" without having to get rid of the value in "c". Before "f" is called, the stack will likely be incremented by two integers worth of space at once, instead of adding the variables one at a time. Then once the block terminates, all variables relating to it are discarded simultaneously.
> Conceptually, I would say other languages are variable-based.
This seems less meaningful than "syntax-based" . Certainly, a "variable" is not a fundamental I deal with on a daily basis in c-based languages—there are necessary exceptions cause by the limitations of the language, of course, like accumulator symbols in a reduction process or state variables in some specific algorithm. Nor do I understand any utility such a concept bings to the table—in fact, this concept brings mostly pain I'd like to forget and forbid from future projects. I refer to "symbols", not "variables".
Regardless, variables are commonly implemented with a stack and are not trivial concepts to differentiate from the equivalent usage of a stack.
Perhaps I should argue for a "syntax-oriented" language instead.
I understand that procedural languages often have variables, but any method of programming that blesses this code as "good" typically doesn't bless the usage of variables outside of looping-with-an-accumulator, state machines, or some other formal usage. I certainly wouldn't emphasize this as any positive characteristic of the language given that its unique attribute is the ability to cause bugs by interacting with it incorrectly (god forbid you have a "pointer variable"—the most curse-upon-humanity type if such a concept were to ever exist)
I write compilers. I don't know why anyone would willing make the mistake of creating the concept of "variables" again.
By "variable" I mean a name with a value attached. It doesn't necessarily have to mutate. Forth doesn't let you define these within procedures. Values are communicated implicitly on the stack in Forth, where other languages give them names and then use the names to say where the value goes. From a compiler perspective, you could think of this as the difference between JVM bytecode and LLVM IR.
> "within" vs "not within" seems like a distraction.
It is a quite significant difference. A name bound at global scope exists with only one value. A name bound at function scope can be instantiated with different values depending on what the function is called with, and can hold multiple values at the same time if the function makes a recursive call to itself.
> I just don't see the distinction you're drawing as meaningful.
Yes, most languages are Turing-complete, so there isn't technically a difference between them. You are welcome to think the difference between Forth and other languages is not meaningful.
For completeness, there are languages that do not require stacks to implement (nor any workarounds that in practice emulate a stack). If you do not support explicit recursion, you don't need one. All variables can be statically allocated and only a single return address needs to be stored for each function, so you do not need a stack for return addresses either.
The most famous example is FORTRAN, until 1990 when they added RECURSIVE directive.
Yes, you are correct. My friend made this post so I didn't have control over the exact wording. That being said, in concatenative programming, the stack is public and, in my case, is virtual.
That's wonderful! Full endorsement of the support of rsync.net.
I sincerely doubt most tools will be supported by most providers (by usage), however, and I question the evaluation of tools by this metric. Support is generally a fairly bad metric by which to evaluate tooling—generally speaking, if you care which client is consuming an API someone has done something horrifically wrong.
