It also looks like it has some improvements for dealing with `null` from Java code. (When I last used it I rarely had to deal with null (mostly dealt with Nil, None, Nothing, and Unit) but I guess NPEs are still possible and the new system can help catch them.)
If you're going to "refresh" a codebase you probably want it to be on the current version of things. Old dependencies rot, like it or not. I don't think there's any timeframe for Scala 2 EOL yet, but new development is happening in 3.
Why not though the upgrade process from 2.13 to 3 is pretty smooth. And you get all the new language features. I can think of a few that I actually like. I’ll just mention enums because it’s a good example.
In the 70's a Brazilian programmer told me his method was to make his best guess how long something would take, double it, then promise that amount plus-or-minus 50%.
Evoking a vibe is what artists try to do. Visually enticing buyers of your product is what graphic designers do. Either use a designer or copy from the millions of expertly designed sites that already exist. You'll have to change it all anyway in a decade or two when styles and fashions change.
You're right. Rather than trying to stand out in a unique way, it's better to look like something already trusted and established. Thanks for the insight!
"Splitting the universe of intellectual tasks" would be a gigantic job. Various AI implementations already fail at so many tasks it seems reasonable for skeptics to claim the AI is not yet thinking, and the burden is on the implementers to fix that.
> "Splitting the universe of intellectual tasks" would be a gigantic job
What I mean is a theory that allows you to categorize any given task according to whether it requires "thinking" or not, not literally cataloging all conceivable tasks.
The US, broadly speaking, does not make a distinction between step-over and step-through two wheeled motor vehicles in any category.
Again, broadly speaking, over 30mph is a motorcycle, under 30mph is a moped (unless it's an ebike with pedal assist, but only in some states). It's complicated.
You used to see a lot of scooters (step-through motorcycles or mopeds) in California college towns but ebikes have decimated that market.
It's a lot more reasonable to use a motorcycle or scooter as your main form of transport when the max speed you are likely to encounter on the roads is 40MPH. In the US you will be sharing freeways with people going 80+MPH in SUVs daily.
As someone who always avoids four-wheeled cages if possible, I can say highways are more or less safe if you have a fast enough motorcycle, compared to slow lane filtering with big vehicles on the road. Tiny spaces, poor visibility, and things that crush you on a slighest mistake is a dangerous combination.
If you look at the "motorcycling countries" (SEA, India/Pakistan, Africa, Latin America, etc.), most terrible accidents happen because trucks share the road with an army of scooters. I've been to a few of them on a motorcycle and it's a nightmare. For the same reason, big cities in China introduced dedicated scooter lanes separated by concrete barriers.
Legally, they’re all motorcycle. Unless they’re mopeds (50cc, speed limited).
But colloquially, if it’s a step-through, it’s called a scooter. Most of which have a CVT transmission, where most motorcycles have a 6-speed manual (toe shift) transmission.
I'm amazed that city, county, state, and federal tech projects never want to clone best-of-show systems instead of starting from scratch. City needs a web site? Clone the best one you can find amongst the tens of thousands of cities already doing that. County jail needs tracking of inmate transports? Clone the best one you can find amongst the thousands of counties already doing that. State needs a sales tax system? Clone whatever other state system is the best. VA needs a system for hospital records? Don't develop from scratch, start by cloning the best system you can find amongst the thousands of existing hospital networks, and customize from there.
That's what they did. If you read the article, it discussed the whole program as being a change from an in house developed system, to an off the shelf system.
> The program launched in 2018 to replace the aging computer system used across VA’s health care network, which serves more than 9 million veterans, with an off-the-shelf product that could handle many of the same tasks: organizing important information including appointments, referrals, prescriptions and patient histories.
> David Shulkin, the secretary at the time, announced that VA would negotiate a contract to buy the records system from Cerner without competitive bidding.
VA leaders said they selected the program because the Pentagon already had purchased a similar Cerner system for the military’s more than 700 hospitals and clinics.
VistA is an old system, and it's definitely "aging." But the thing is that it actually works really, really well. For instance, it kills a remarkably low number of people, which is one of the benchmarks I personally value in an EHR.
One of the interesting things about this is that, from my perspective, VistA's sort of a mesh of servers rather than the hierarchy we might expect from a federal system. Perhaps that's because of the complex interplay between federal and state and local laws. But anyway, there's probably a "station" for VistA near you that serves your area, and that's very similar (though not identical) to the "station" in the next neighboring area/metropolis/state/whatever.
But weirdly it seemed like the plan to roll this out was to replace all of the functionality at a given VistA station, rather than to do a strangler fig sort of thing and work on supplanting VistA's functionality in a specific functional area (whether locally or nationally). I don't know if that's because of the aforementioned complexity of laws, or the complexity of how the system(s) is/are administered, or other reasons that would elude me.
VistA EHR works reasonably well for end users but the problem is that the underlying platform is kind of a dead end. There's no practical technical path to keep it moving forward with major new enhancements (some of which are legally mandated for compliance). Hardly any developers have the platform skills, no one wants to learn (career suicide in most cases), and modern tools don't support it. It's a shame but that's the reality.
I don't disagree at all (disclaimer: I don't work on VistA, but systems that communicate with VistA... close enough that the "career suicide" phrase hits a little close to home).
I think the bigger problem is that we're not meaningfully grappling with the reality of what it takes to replace legacy government systems.
Another grain of sand on the beach of things that we're completely unequipped to deal with, I guess.
A lot of government procurement is bound by strict "competitive bidding" laws that seek to give everyome and their grandmother a fair shake at the contract, in the name of avoiding graft, corruption, and bribery.
This has led to somewhat of an arms race where government workers desperately collaborate with contractors to find a way to sidestep or subvert the bid process and other contractors aggressively seek to inspect and enforce the process.
Developing in-house governmental talent, institutional knowledge, and capacity is of course strictly off the table, as it would reduce opportunities for private profit in basic government services.
My first question was: why?
reply