I spent about two hours last night trying to get a consistent and accurate answer out of Claude regarding a set of graphics APIs. I then went the old fashioned way to find most of the articles outside of a couple of sources were also incorrect API slop. I can't override methods that don't exist and never have existed in an API, but that's what the clankers have latched on to.
Just before that, at work, I found a bug in an AI driven refactor of code. For some reason, both the original refactor and the ai driven autocomplete kept trying to send the wrong parameters to a function. It was determined to get it wrong, even after I manually fixed it. [Edit - I should also mention the AI driven code review agent tried to do the same thing. The clankers are consistent.]
This is why familiar language matters. Because at some point, you'll have bugs that the AI can't fix. And by the way, I use LLM tools at work and have a set of skills that improve my productivity, if not my QoL. But I still need to be able to dive into the language, the build tools, and fix things.
I agree, the risk at the CTO/CIO level is it's four years later, the startup went under, and you have this software integrated into your environment. If you're lucky, someone else will have bought it. They'll on-ramp you to their stack. But then you run the risk of their seeing your as trapped. It's not about how much money you want to pay for the product. It's about extortion.
Or, if you're less lucky, you'll left with software you can't maintain. Even if there's a contract clause that says you get all the yummy, yummy source code. You may not even be able to open source it because you don't own the copyright to some or all of the code. You just have the source code. Good luck with that.
No one gets fired for buying IBM because you know (or at least we once knew) IBM would definitely be around for years to come to support the product. Is it expensive? Yes. Have I found a lot of enterprise products miserable to use? Yes. Does everything have the stink of "well we made it work well enough not to get fired?" Yes. But you won't be getting extorted Broadcom style, or sitting around with 5,000,000 lines of AI generated source that has all sorts of hacks and work around for the four other companies to whom the startup sold their software.
I think you're right and it's possible to have something that exists with no other purpose than to cause harm. And it's not moral to make that thing. I also don't think it's fruitful to find the specific circumstances it's moral to eat babies (go down philosophical rabbit holes until you find the one time that doing something despicably immoral is actually the moral thing to do). But I would say the technology is the least important part of the problem. A moral person uses dangerous tools sparingly and intentionally harmful tools never. If Palantir did not exist, would they perform the raids? I think so.
Okay, that's where you draw the line. But someone provides power to their data center and their offices. Someone provides hand-held devices. Someone provides network connectivity. Someone has a contract to house and feed these agents. Someone has the logistical and fleet services for their vehicles. Someone is likely the landlord to their buildings. Someone has a contract to clean the buildings. Someone is a deciding to buy a block of Palantir stock versus some other software company. Someone runs the private prison into which people are herded. An attorney has a choice to file a charge or not file a charge. A judge has the choice to bend over backward to give ICE/CBP the benefit of the doubt, or be skeptical.
Baking a roll of bread is not immoral. Baking bread as part of a contract to feed the gestapo, is.
My point was, if you do invent something like Zyklon B, you need to consider its uses. While the gas itself is just a molecule, devoid of morality, not everyone who employs it will be a moral person.
In the case of Palantir, should we allow the federal government to combine databases (which may have been hoovered up by DOGE and held in a private sector company that isn't subject to FOIA)? Should there be judicial review, like for FISA warrants before you can field an application? Should we allow the government to buy that kind of app in the first place? I don't give Palantir a free pass.
But it's not the engineer at Palantir that decides to send poorly vetted and trained people into a home, fully stoked, believing your have complete immunity, and full of anabolic steroids, and praying any of the occupants shows an iota of resistance. 79 million voters chose this. This is the morality of the people employing the tool.
A thing clearly has no intention and it's impossible for us to know every possible use for a product. But at some level we need to feel responsible for what we create, we need to feel responsible for our choices, and we need to see the responsibility others have because of their choices.
Yes. It's not, and I agree. There's no bright line that says you're morally culpable or you are not morally culpable for what you do. But all of us should think about our roles in that light. If Palantir uses Git, does that mean new Git contributions are part of what is arguably an ethnic cleansing? I wouldn't be able to sleep at night and work on this project. (I do not work at Palantir).
But the point is also that maybe we should take one step back and think about the morality of the people we put in decision making roles. The technology is morally neutral, but the intention is not. And helping to realize that intention is not. And sometimes the things we build can be used in horrible ways unless we also think about safeguarding their use.
This is just the tip of the iceberg. It is my very real fear that a lot of information has been aggregated into Palantir and other applications and is usable with no restraint. And that even if you just run the build system, across hundreds of apps, you might be culpable as well.
In another comment, I referenced Eichmann. A train is not a good thing or a bad thing. A rail car is not a good thing or a bad thing. Having an app that aggregates multiple different data sources and puts them together is not a good thing or a bad thing. It's the morality behind the hands into which we put that tools that matters. The more capable the tool, the more good or evil you can do with it. Maybe we should ask ourselves if this kind of a tool should exist at all, or there should be some level of process before it can be used. But the engineer at Palantir is just as guilty or not guilty in your eyes as the engineer fixing the trains or laying new track.
Not in the short while since they've purchased Arduino, but I could see them restricting the licensing for commercial use, while keeping it freely usable for education. Like STM.
15 years ago I think Arduino was the best choice for educational purposes. I still think it's a great choice now. The fact the IDE and board are basically the same as they were 15 years ago, means you can figure out how to set everything up once and focus on teaching, rather than PC trouble-shooting. Which, for basic concepts, or younger kids, is great. And if they find a 5 or 10 year old video on how to do something, it's still relevant.
If I were putting teaching materials today - I would pick something like Micro python. The down side is it isn't as "canned" a solution, meaning there might be something new to figure out every so often. Which means you spend more time helping people trouble shoot why something isn't working, instead of teaching something useful. On the up side, Python is pretty much the introductory language of choice, today. With lots of available materials.
That's not to say Arduino was perfect. Far from it. Just easier to do, and more consistent over time, than other options.
From an embedded developer's perspective, Arduino is awful. That hero-loop programming is not what anyone should ever do. And experienced developers can get better results from something like FreeRTOS (or if you're a masochist Zephyr). And ESP32s are cheaper, as are RP2040s. ...
But take a room full of kids and get them to write a program that blinks an LED, or drive a simple 'robot' forward, and it's awesome. Easy to use. I've never burned out a board (even driving considerable current through them). Things are tolerably well marked. Lots of teaching tools. Lots of different suppliers of easy to connect motors, servos, lights, sensors, etc.
For the same reason, if you are not an embedded engineer, but need a simple micro-controller to turn something on an off like a heater in a chicken coop, it's fantastic. And if you want, buy the $5 knock-off Uno. It should be the same, except that it doesn't support the (now defunct) foundation.
The cool thing about an Arduino is you can just buy the boards and use them in a commercial product. This isn't something you can do with other boards. Some people have said the license requires you to disclose your firmware, but that's not the way I read it and I've never heard of anyone being compelled to release anything (unless they modify any GPL covered code).
Not all platforms give you the right to do this. For example, if you buy a dev board from STM - it's only licensed for research and development. Also, because you might want to continue to sell the same thing for years, and the board designs were open-sourced, you could buy the same part for years and years. So you can continue to sell your CNC kit that uses an Mega 2560 without worrying about Arduino coming after you or that they'd discontinue that part.
It won't be just one big move that kills the community. Eventually, I could see it as locked down as the STM32 ecosystem. Nor do I see them continuing to sell the same parts for over a decade. They'll just want to use it to promote new kit. Nor do I see them keeping to board designs open over the long term. That will come one little step at a time.
When I bought a 3-D printer years ago, I had an important insight. I was either buying a printer as a project, or I was buying a printer to help with other projects.
Both are reasonable answers. It makes people happy to work on their 3-D printers. They love tinkering with them, like printing new braces, holders, parts, etc. The love tuning them. They love finding the perfect filament storage system. That's the hobby. The 3-D printer itself.
I was buying a 3-D printer to make parts. When I realized that I didn't want another hobby, a whole bunch of printer options fell off the table. I wound up choosing a printer that would pretty much work acceptably, once assembled. I have printed stuff with the printer, but I guessed right. At no time do I ever look at the printer as anything more than a tool to get something else done.
From my perspective, it feels like a lot of the JavaScript community falls into the former category. Their JavaScript environment is beautifully incomplete. It must be perfected. They tinker with the works to get the perfect packaging and build process. Bits and parts are changed out, re-worked, or re-written. I think the fact the language invites edge-cases also gives plenty of fodder for new ideas.
I'm a tool user, and that's what I liked about straight-up rails. It did a good job, was faster to develop on than enterprise Java, and the end-product was understandable. Rails and Ruby weren't my projects. The application I was working on was my project.
The one thing I don't miss about Rails is constantly feeling like I'm doing it wrong. I had a 'discussion' at RailsConf when I was told I should stop using C Ruby and switch to JRuby because it's so much better. And that's the right way to do it.
But I couldn't get JRuby to package reliably. I'd fix the issues, it would work for a while, and then something would change.
Oh... because I wasn't doing it right. I have to rework a bunch of dependencies. And after a while, it breaks again. Why? Oh... I wasn't doing it right, I should be using this middleware instead...
So I said I'm done mucking around with JRuby. When I said this, I was told at RailsConf that was doing it wrong, and by implication, irresponsible with my clients' applications. That was I setting everything up for failure. Yet the applications that were working just fine on C Ruby. (I don't really hear much about JRuby any more - but I haven't been part of that world since George "strategery" Bush was president.)
And this was the shtick for conference speakers and YouTubers. You're doing it wrong. Do it this way to do it right. You're using Controllers wrong. They should be fat. They should be thin. They should be big boned. You should never use models. You should only use models. You should sit on two chairs and pair program with yourself when you develop. Only drink water when writing tests.... etc. etc. etc.
This left a bad taste in my mouth in what otherwise was a great community. I felt like a lot of the community wanted to do build great applications, quickly, cost-effectively, and with high quality. But that same impetus could be manipulated by folks in a way that's unhelpful. THAT part of Ruby I don't miss. RailsConf in Portland, eating VooDoo doughnuts, talking shop with other folks? That I miss.
Just before that, at work, I found a bug in an AI driven refactor of code. For some reason, both the original refactor and the ai driven autocomplete kept trying to send the wrong parameters to a function. It was determined to get it wrong, even after I manually fixed it. [Edit - I should also mention the AI driven code review agent tried to do the same thing. The clankers are consistent.]
This is why familiar language matters. Because at some point, you'll have bugs that the AI can't fix. And by the way, I use LLM tools at work and have a set of skills that improve my productivity, if not my QoL. But I still need to be able to dive into the language, the build tools, and fix things.