I have no reason to think you're lying about the first part (although I'd point there's several ways that metric could be misleading, and approximately every piece of evidence available suggests it doesn't generalize), but the second part is very fishy. There's really no way for you to know whether or not you'd have written the same code or effectively the same code after reviewing existing code, especially when that review must be fairly cursory (because in order to get the speed up you claim, you must be spending much less time reviewing the code than it would have taken to write). Effectively, what you've done is moved the subjectivity from "how much does this speed me up?" to "is the output the same as if I had done it manually?"
LLMs can, for example, write a script to calculate all permutations of the levenshtein distances between words in a sentence and deliver it before the average programmer even understands what this means. Trivialy.
You're just holding it wrong if you're asking it to simply count the characters in a sentence.
Interesting. I'm not experienced in data cleaning.
About Python vs Excel:
Isn't manual cleanning of data in Excel prone to permanent error? Because:
- it's hard to version control/diff
- it's done by a human fat fingering spreadsheet cells
- it's not reproducible. Like if you need to redo the cleaning of all the dates, in a Python script you could just fix the data parsing part and rerun the script to parse source again. And you can easily control changes with git
In practice I think the speed tradeoff could be worth the ocasional mistake. But it would depend on the field I guess.
> - it's hard to version control/diff
As I mentioned, this is only prototyping.
After that, we move on to implementation in code, knowing what we want to see in the end and understanding the nuances of the data itself.
> - it's done by a human fat fingering spreadsheet cells
No one is entering anything into the cells, please reread the message.
> - it's not reproducible. Like if you need to redo the cleaning of all the dates, in a Python script you could just fix the data parsing part and rerun the script to parse source again. And you can easily control changes with git
And that's what I said above. That it takes longer. Why use git/python when I can do it in a few clicks and quickly see a visual representation at every step?
> In practice I think the speed tradeoff could be worth the ocasional mistake. But it would depend on the field I guess.
Another sentence that shows once again that you haven't read what was written.
That's the upshot of what he's saying. But how the cross pollination happens -- crossing over to another plane of thought -- is I think the real point. That is: Cross-pollination between programming languages is a good thing, and therefore we must often force ourself to think outside of our narrow way of thinking in order to find new ways, or else we will dig ourselves into a trench (or find ourselves at a local maxima in the design space of languages).
I honestly don’t understand how that’s offensive. It’s just a metaphor, and a pretty good one. Why are you taking it as some kind of value judgement? Do you feel like people who don’t know something are lesser beings?
The book was originally written as a metaphor for understanding a fourth spatial dimension, and as far as I know the metaphor is generally taken as helpful, not demeaning. The flatlanders are never described in an unflattering way.
While there are several comparable European alternatives, many countries put their bets on the F-35 a long time ago. It is very much a part of this discussion.
I’m from one of those countries, and I can assure you a lot of people would now have preferred that we went with an EU competitor instead.
What comparable alternative is available today? None of the European companies has a production 5th generation aircraft nor the integrated sensing capabilities. This is what is driving the incredible demand despite misgivings. You can't survive in a near peer combat environment without it.
Countries are buying it because it is the only game in town for certain high-value capabilities, not because they necessarily like the implications of there being a single seller of those capabilities. For better or worse, the US has been flying these for 30 years and has 6th generation aircraft in production. Everyone else is still figuring out their first 5th generation offering.
Closing that gap is a tall order. Either way, European countries need these modern capabilities to have a capable deterrent.
I'm no expert, but the narrative is that it really depends what you need them for. And keep in mind that joining the jet fighter programme also means joining the development of it, enacting a certain amount of influence through your funding. For example, it is conceivable that a sufficiently upgraded Gripen tailored to our needs would be just as effective (which aren't really dogfighting, as I understand it), and cheaper.
Anyway we're all just crossing our fingers that the US is just temporarily insane and will eventually come to its senses. What else can you do.
Some days ago I got interested in using Syncthing to keep a folder of markdown files synched between computer and phone, for personal notes.
Lost interest the momment I found out that all mobile clients for Syncthing are from third parties.
I understand that maintaining a server plus clients is a lot of work. But by not having an official client you leave people at the mercy of random clients by random people.
The Git Sync or PuppyGit apps are a good way to keep markdown files in sync between devices. I use git for my Obsidian notes.
It's better than file sync because you have diff and merge in case you accidentally edit the same file on 2 devices and get a conflict. Plus you have full history of everything.
If you do need file sync I really like the FolderSync app on my phone, it's reliable and connects using a ton of protocols.
Also when I use LLM to fix a bug, I tell it to write a test to prevent regression of the bug at the end of the session, after the bug is fixed.
reply