My reading of the article, was that the author seems to be in search of a new paradigm, that moves beyond what he sees as the limitations of "fp-like" languages as they exist today. His point appears to be that Zig provides the benefits of "fp-like" languages that exist today, while avoiding at least some of the downsides.
And he does admit you may have to squint, to appreciate the fp capabilities provided by Zig.
It is worth noting that some rather "enlightened" type system features are common in other imperative languages, not particularly novel ides in Zig.
For example Swift enums, while in some ways clunky, can do a decent job both as newtypes and as sum types (unlike Java enums, which are a fixed collection of instances of the same class).
The Chameleon Ultra V2.0 open source project [1] can be configured to "Reader-to-HID" which should give you what you want. You can build your own, or buy one of many pre-built options [2]
Does northern Canada have the soil required to take advantage of a longer growing season? Not the Canadian Shield areas, which is a huge part of the north, because there is little soil and mostly rock. There are pockets of interior plains and lowlands, but they will mostly become swamps and bogs when the permafrost thaws.
But that isn't evidence that the method works. If you're a native tribe, that has an ancient traditional rain dance, it is invoked whenever there is a drought. Sometimes it rains shortly after the dance is performed. But if it doesn't rain, it's not proof that you danced poorly, it's evidence that you didn't understand the situation fully or properly. The instructions or "wisdom" you relied on, didn't actually capture something useful.
My evidence is that I was on a team that was not overly controlled by management and had clever people in it without any instant attitudes of rejection so they adapted to it. We produced updates bi-weekly and we had a huge backlog of stupid features which we were never going to get round to - we were able to get the important things done and it was one of the best feelings I've ever had about work.
Since then I've been on teams with any number of pathologies. From developers it is sometimes the desired to be special - those ones who want to work on their bit of the code and not let anyone else touch it. From managers it's things like forcing the way stories are split so that they're always too large and can never fit into a sprint - because they think that everything must be a "user visible change". Management types also sit in retrospectives and use them to crap on everyone. Product managers demand features which they don't know will really interest customers and are inflexible about them - they want "everything" just in case and that delays the work and deletes any chance of a feedback loop.
The good agile feeling came from being able to have control and be successful. When it's messed up, you're out of control and cannot avert disasters. Whatever method you want to call it, I think we need to feel we're in control enough to succeed.
What is the chance that you've perfectly captured every aspect of the situation that led to success? Versus, what is the chance that you were lucky enough to be in situations where a multitude of factors, both appreciated and unappreciated, combined to lead to success?
There are a million possible reasons for failure, but here is a very easy one: It doesn't matter how good you feel about the development process, if the company has the wrong objective. You will still end up being frustrated, and failing. Of course this will have all sorts of pathological and uncomfortable ramifications.
So while it is easy to say, "just act this way and you'll have success". You're not actually appreciating all the hidden elements that allow any hope of acting that way. You've been lucky enough to be in situations where it happened to work (ie. the rain dance made rain), but that does not mean it's actually representative, or that the prescription actually captures the critical information needed to ensure success for other people. Instead, you've described a rain dance.
You're right - there isn't one way to do things or one way that always works. There are issues that are outside a team's control, for example, that make it an impossible struggle. If you're rigidly forced to do something and cannot adapt then you're ... not really agile. But you have to understand why you're doing what you're doing and keep adjusting to see what works for you.
#1 IMO is that if the company you're in is non-agile in its general attitude, which is influenced by its own customers, then everything is geared against you.
That isn't to say that something like Kanban might not be usable or better than no plan at all but certainly scrum is not some universal solution.
It would be very helpful to deeply understand the truth behind this management failing. The actual players involved, and their thinking. Was it truly a blind spot? Or was it mistaken priorities? I mean, this situation has been so obvious and tragic, that I can't help feeling like there is some unknown story-behind-the-story. We'll probably never really know, but if we could, I wouldn't spend quite as much time wearing a tinfoil hat.
My guess is it’s just incompetence. Imagine you’re in charge of ROCm and your boss asks you how it’s going. Do you say good things about your team and progress? Do you highlight the successes and say how you can do all the major things CUDA can? I think many people would. Or do you say to your boss “the project I’m in charge of is a total disaster and we are a joke in the industry”? That’s a hard thing to say.
Intel was never famous for good GPUs, and they are basically the only ones still trying to make something out of OpenCL, with most of the tooling going beyond what Khronos offers.
one API is much more than a plain old SYCL distribution, and still.
I'd argue Intel fell is large part because of Intel's own complacency and incompetence. If Intel had taken AMD seriously, they'd probably still be a serious competitor today.
if you asked AMD execs they'd probably say they never had the money to build out a software team like NVIDIA's. that might only be part of the answer. the rest would be things like lack of vision, "can't turn a tanker on a dime", etc.
CUDA was built during the time AMD was focusing every resource on becoming competitive in the CPU market again. Today they dominate the CPU industry - but CUDA was first to market and therefore there's a ton of inertia behind it. Even if ROCm gets very good, it'll still struggle to overcome the vast amount of support (read "moat") CUDA enjoys.
True. After all Nvidia hasn't built tensorflow or PyTorch. That stuff was bound to be built on the first somewhat viable platform. Rocm is probably far ahead of where cuda was back then, but the goal moved.
Has to be lack of vision. I refuse to believe it's impossible to _do_, but it sounds like it's impossible to _specify_ within AMD. Like they're genuinely incapable of working out what the solution might look like.
Nobody is asking AMD to rebuild the entire NVidia ecosystem. Most people just want to run GPGPU code or ML code on AMD GPUs without the entire computer crashing on them.
according to public information NVIDIA started working on CUDA in 2004, that was before AMD made the ATI acquisition.
my suspicion is that back then ATI and NVIDIA had very different orientations. neither AMD nor ATI were ever really that serious about software. so in that sense i guess it was a match made in heaven.
so you have a cultural problem, which is bad enough, then you add in the lean years AMD spent in survival mode. forget growing software team, they had to cling on to fewer people just to get through.
now they're playing catch-up in a cutthroat market that's moving at light speed compared to 20 years ago.
we're talking about a major fumble here so it's easy to lose context and misunderstand things were a little more complex than they appeared.
Yes. If you called from your cell phone while on foot or in your car, the drone can find your exact location and hover over you until help arrives, quicker than if EMS has to search you out themselves.
How so? I ask as a paramedic of 14 years, now retired.
If EMS has to "search you out" so does the drone.
At least in my County, we actually get very good triangulation info from 911. It was very rare that Dispatch told us they only had Level 2(IIRC) location info (which might be to several hundred feet).
FAR more common was people who actually told us the -wrong- location. Car accidents that were several miles up the road from their location. Saying Blah St SE when they meant Blah Rd NE, etc.
Drones don't solve for that problem. They're going to the wrong location, too.
> If EMS has to "search you out" so does the drone.
The point is that the drone is fast enough to arrive first, and do the searching so that you don't have to. It's just one of many possible scenarios.
I totally understand the argument that this might not be the most effective use of money, but I honestly don't understand the lack of appreciation for the number of places this could be used effectively.
Modern fire departments (including my own) are already using drones, and have found that the best use for them is not "how quickly can we find someone", but thermal imaging from above on structure fires.
> and do the searching so that you don't have to
The searching that we did just isn't really solved by drones (and I love them, some of my best photography is from a drone). It's things like "obscured house numbers on a street", "ambiguous address", not "person lost in a forest". Now if you want to talk about the use of drones for SAR? Absolutely. But for the vast majority of 911 "attempt to locate", getting there quickly is rarely the issue. We can get there quickly and still spend minutes figuring out that you're actually living on a flag property (where your home is behind another, but you share a driveway).
Yeah, I'm sure they wouldn't be helpful in every call. But the EMT user above talked about sometimes a caller giving the wrong location of a car accident. That's a clear case where a drone quickly on site could warn that crews need to be diverted elsewhere. But if it is just the occasional case where they'd be helpful, that makes them even less economically attractive.
As for fire services, in my city there is always a lead SUV vehicle (I think a captain or supervisor) who is a few blocks ahead of the actual heavy trucks. Presumably to get someone on site as quickly as possible; which made me believe that a drone could assist in that role. But I accept what you say, that there are too many limitations for it to help much, even if it can arrive quicker.
I want to see who is in a location. I get a plant to call 911, which triggers Flock drones in the general area and scans the faces of everyone it can find. I get that info from Flock.
There are always security concerns and exploits. Some crazy gamers call 911 swat attacks on people; that doesn't mean that the police shouldn't have guns, or that 911 should be turned off.
Yes, the drones should be secure. Yes there should be measures to make sure that they're not abused. But none of that takes away from anything i've said, which is ONLY to point out the situations where they could be useful. And people seem to be having a very negative visceral reaction to even considering the possibility.
Also, i'm not recommending or supporting Flock, just the concept of drone use in general.
Obviously I don't know the specifics of your city, but in general there are a lot of scenarios where it's valuable to get to a scene very quickly (no traffic, etc.) and obtain reconnaissance. Especially violent scenes, or it could even be a drunk driver who is still on the move, or a stolen car where the perpetrators are likely to flee on foot if stopped.
I'm sure you can come up with a lot more ideas using your imagination.
One of the best reasons is that a very large % of calls can be cleared without anyone actually going to the scene. Many cities using drones as first responders now report that they clear ~30% of calls with just a drone. This is great for small cities/towns that struggle to recruit officers and have had ballooning labor costs for police in order to get people to work there. Its also great philosophically if you want police to be involved less, because it dramatically lowers the amount of time they are going to scenes
There's more than one definition of missile. Florida criminal code's just one place where a drone could be considered a "missile".
Florida criminal code:
"790.19 Shooting into or throwing deadly missiles into dwellings, public or private buildings, occupied or not occupied; vessels, aircraft, buses, railroad cars, streetcars, or other vehicles.—Whoever, wantonly or maliciously, shoots at, within, or into, or throws any missile or hurls or projects a stone or other hard substance which would produce death or great bodily harm, at, within, or in any public or private building, occupied or unoccupied, or public or private bus or any train, locomotive, railway car, caboose, cable railway car, street railway car, monorail car, or vehicle of any kind which is being used or occupied by any person, or any boat, vessel, ship, or barge lying in or plying the waters of this state, or aircraft flying through the airspace of this state shall be guilty of a felony of the second degree, punishable as provided in s. 775.082, s. 775.083, or s. 775.084."
It was probably true at some point, then malicious people learned how to fake stupidity and they outnumber actual stupid people, and they learned how to recruit stupid people to their causes.
It's a decent rule for when one of your close friends breaks your favorite mug. Not so much for complete strangers, not to mention faceless mega-corporations, making choices to fuck you over.
In the same way, so many current cameras (mostly phones) that do automatic post-processing of images, up to and including AI, is going to lessen their future archeological value.
I'm reminded of Samsung's "AI moon" debacle and how divided people were over it. At the end of the day, any photos with so many unknown variables wouldn't suffice for scientific purposes.
