Sure, we can ignore that specific example, and that software has an effect on the world, and that people have been trained to expect software to be deterministic and accurate.
Or if you want compare vibe coding with any technology, like electricity. Sure, that one person got electrocuted or their house burned down. But it's just so useful, and "somehow civilization continues to function". I guess they should've known better.
I'm personally not comfortable hyping up the benefits whilst ignoring the risks, especially for lay people.
One counter-example is the Horizon IT scandal. Obviously, you didn't say this directly, but "only a few people died/were affected, somehow civilization continues to function" maybe isn't the best argument.
I'm a fan of the RP2040 chip. It's a good trade-off between being simple and capable. There are more powerful chips like the STM32's, but frankly there are too many variants and their data-sheets are nightmarish. And there are simpler chips like the Atmel AVRs, but the tooling sucks. ESP chips are also good, but I haven't kept up with them so can't give much advice.
You'll want a dev board, which has the chip plus some supporting components on it. The Raspberry Pi Pico is a good choice because it's so widely used and well documented.
If you care about Rust, you'll also want to get the Debug Probe. Worth the money.
If you don't care about Rust, any Adafruit dev board should run CircuitPython, have good documentation, and likely some projects you can start with. The reason I don't recommend these for Rust is because many of their dev boards do not "break out"/make available the connections for a debug probe.
Edit: Having a project you want to do is good, but just making an LED blink can be magical, too, especially if you haven't done anything with hardware.
I really like the idea... but I have to admit my first visceral reaction was "I hate this". I think it's because the tone and style is quite infantile/childish. A good experiment nonetheless. Maybe there's a middle ground somewhere?
You aren't wrong on either; Germany's tax law is insanely complex but also many people don't want to change the tax law as they can deduct a million and one things.
Which is why I quoted IIHS and other non-US testing.
> NHTSA standards
Which standards are for e.g. pedestrian safety? The hood ornament thing?
> That's misleading. They don't test for pedestrian safety as part of the normal tests. But they test for it generally
No, it isn't and no they didn't/don't. E.g. GAO report from 2020 [0]:
> NHTSA’s last substantial update of NCAP was in July 2008 (with changes effective for model year 2011 vehicles). This update established additional crash tests and technical standards to protect vehicle occupants, but did not include pedestrian safety tests.
Or from NHTSA itself in 2022 [1], although note this is a "proposal" and "recommendations":
> For the first time ever, NCAP includes technology recommendations not only for drivers and passengers but for road users outside the vehicle, like pedestrians. The proposal [...]. We look forward to reviewing the comments we receive and considering them as we complete this important work.”
They will/might, by adopting Euro NCAP [2]:
> This final decision notice adds a crashworthiness pedestrian protection program to the New Car Assessment Program (NCAP) to evaluate new model year vehicles’ abilities to mitigate pedestrian injuries. Based on its previous research, NHTSA concurs with and adopts most of the European New Car Assessment Programme’s (Euro NCAP) pedestrian crashworthiness assessment methods [...]
> These changes to the New Car Assessment Program are effective for the 2026 model year.
> NHTSA conducts frontal, side and rollover tests because these types account for the majority of crashes on America's roadways.
> IIHS tests evaluate two aspects of safety: crashworthiness — how well a vehicle protects its occupants in a crash — and crash avoidance and mitigation — technology that can prevent a crash or lessen its severity.
> As well as assessing how well cars protect their occupants, Euro NCAP tests how well they protect those vulnerable road users – pedestrians and cyclists – with whom they might collide.
> It is completely normal for staff to have to work 24/7 for critical services.
> Not only is it normal, it is essential and required.
Now you come with the weak "you don't have to take the job" and this gem:
> An employee’s lack of boundaries is not an employer’s fault.
As if there isn't a power imbalance, or employers always disclose everything or chance their mind. But of course, let's blame those entitled employees!
Nice try at guilt-tripping people doing on-call, and doing it for free.
But to parent's points: if you call a plumber or HVAC tech at 3am, you'll pay for the privilege.
And doctors and nurses have shifts/rotas. At some tech places, you are expected to do your day job plus on-call. For no overtime pay. "Salaried" in the US or something like that.
As far as I can tell, the author isn't claiming e.g. all of Usenet or IRC was affected. Only that this issue has been happening to communities for a long time in many different online places.
i was initially confused, why would you want to jump or even convert between the '<' and '>' signs? but from trying it out on that snippet, '%' actually jumps to the nearest bracket and selects(?) the matching one [0].
now, i'm not 100% sure on the exact behaviour, but e.g. even a cursory test in sublime shows it will highlight the start and end brackets if i'm inside the if-expression and you can "expand selection to brackets".
Maybe it's a bit disingenuous to claim that's your primary goal when you've gone to the trouble of designing a logo and adding "testimonials" to your README.
And Kenneth Reitz isn't "just another developer". He's well known, and isn't shy to mention his `requests` library ("uses the actual Requests you know and love").
Cynically, you might say the "just for learning" phrase is a great way of avoiding comparisons to existing frameworks initially. The thing is, it could compare favorably. For one thing, Flask and Falcon support/have to support (?) old Python versions - Falcon even says they support Python 2.6, which is ridiculous (EDIT: doesn't seem to be true from the tox file, but the website still claims it does). All that compatibility stuff provides zero value for new projects.
Background tasks are a great idea. Being a bit opinionated isn't necessarily a bad thing either; Flask would benefit hugely if they recommend people use app factories and blueprints from day 1. It adds almost no overhead, but makes building the application out much, much easier in the future.
> We're not talking about a general open source project with a potentially large userbase. So what you're essentially advocating is that we have to wait till a few hundred people serendipitously have enough time to dedicate to their hobby of writing control software for medical devices. And after that they have to validate the code, test it and ensure its correctness.
Not at all. A start would be a proof of concept device with barely working software. Maybe even not that, maybe the first PoC uses an oscilloscope for visualising the data. Then someone takes e.g. a Beagleboard and dumps the data via USB into a small Python script. V2 might add a bit of a colour map with matplotlib, maybe a GUI or just live updating Jupyter notebook. That's a start.
Why does everybody assume you'd want to replace the medical devices? Did we even read the same article? The authors even say that
> "[c]reating any device for medical purposes can be incredibly expensive, but this ignores all the other uses that ultrasounds can have in education, imaging, sports training and just for fun".
Except for sports training, do we need medical certification or perfect accuracy? No. So why is it so hard to believe that one person couldn't knock something together in a weekend if the transducers were available? You know, for fun, out of curiosity?
> developing that software is expensive and someone needs to pay for it.
or, you know, someone donates some of their time to write it. that's usually how OS works.
think about how much research the person writing the article has done. if you could buy a $25 transducer off ebay, they could have put that time into writing the software.
Or if you want compare vibe coding with any technology, like electricity. Sure, that one person got electrocuted or their house burned down. But it's just so useful, and "somehow civilization continues to function". I guess they should've known better.
I'm personally not comfortable hyping up the benefits whilst ignoring the risks, especially for lay people.