Yes - and further, even if something is "just human behavior", that doesn't mean it's never beneficial to humans to legally regulate the enablement or exploitation of that behavior.
Technically any market that's about someone doing something by a certain time can be an assassination contract, if you think the market will it enforce it that way. Can't do it if they're dead.
It was kind of close to that betting on Trump to not win the last election - $3.2bn was bet on Trump vs Kamala and there was of course an assassination attempt although not related to the betting.
> If the result is always provably correct it doesn't matter whether or not it's different at the code level. People interested in systems like this believe that the outcome of what the code does is infinity more important than the code itself.
If the spec is so complete that it covers everything, you might as well write the code.
The benefit of writing a spec and having the LLM code it, is that the LLM will fill in a lot of blanks. And it is this filling in of blanks that is non-deterministic.
You mention the quality several times in the article but it's not clear how this is verified. Do you have a set of known-location-ip-addresses around the world (apart from your home)? Or are we just assuming that latency is a good indicator?
> It is hands down good for code which is laborious or tedious to write, but once done, obviously correct or incorrect (with low effort inspection).
The problem here is, that it fills in gaps that shouldn't be there in the first place. Good code isn't laborious. Good code is small. We learn to avoid unnecessary abstractions. We learn to minimize "plumbing" such that the resulting code contains little more than clear and readable instructions of what you intend for the computer to do.
The perfect code is just as clear as the design document in describing the intentions, only using a computer language.
If someone is gaining super speeds by providing AI clear design documents compared to coding themselves, maybe they aren't coding the way they should.
The quote that I heard (I think on HN) was, "If we had AIs to write XML for us then we never would have invented json."
My biggest LLM success resulted in something operationally correct but was something that I would never want to try to modify. The LLM also had an increasingly difficult time adding features.
Meanwhile my biggest 'manual' successes have resulted in something that was operationally correct, quick to modify, and refuses to compile if you mess anything up.
And a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more, and talking about how much better it was than things like JSON.
The only thing I think I learned from some of those exchanges was that xslt adherents are approximately as vocal as lisp adherents.
> a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more
I still use it from time to time for config files that a developer has to write. I find it easier to read that JSON, and it supports comments. Also, the distinction between attributes and children is often really nice to have. You can shoehorn that into JSON of course, but native XML does it better.
Obviously, I would never use it for data interchange (e.g. SOAP) anymore.
> Obviously, I would never use it for data interchange (e.g. SOAP) anymore.
Well, those comments were arguing about how it is the absolute best for data interchange.
> I still use it from time to time for config files that a developer has to write.
Even back when XML was still relatively hot, I recalled thinking that it solved a problem that a lot of developers didn't have.
Because if, for example, you're writing Python or Javascript or Perl, it is dead easy to have Python or Javascript or Perl also be your configuration file language.
I don't know what language you use, but 20 years ago, I viewed XML as a Java developer's band-aid.
> if, for example, you're writing Python or Javascript or Perl, it is dead easy to have Python or Javascript or Perl also be your configuration file language.
Sure. Like C header files. It's the easiest option - no arguments there.
But there are considerations beyond being easy. I think there's a case to be made that a config file should be data, not code.
If people are really technical, then a language subset is fine.
If they're not really technical, then you might need a separate utility to manipulate the config file, and XML is OK if you need a separate utility. There are readers/writers available in every language, and it's human readable enough for debugging, but if a non-technical human mistakenly edits it, it might take some repair to make it usable again.
Even if you've decided on a separate config language, there are a lot of reasons why you might want to use something other than XML. The header/key/value system (e.g. the one that .gitconfig and a lot of /etc files use) remains popular.
I could be wrong, but it always seemed to me that XML was pushed as a doc/interchange format, and its use in config files was driven by "I already have this hammer and I know how to use it."
This doesn't sound correct. We have computers write binary for us. We still make protocols which are optimizations for binary representation.. not because it's a pain to write.. but because there's some second order effect that we care about (storage / transfer costs, etc).
Dunno. GUI / TUI code? "Here's a function that serialises object X to CSV, make a (de)serialiser to SQLite with tests". "And now to MS-SQL" pretty please".
I don't how much scope realistically there is for writing these kinds of code nicely.
Surely the public discourse over the past decades has been steadily moving from substantive towards labeling each other villains, not the other way around.
Most people seem to think that holding the "wrong" political stance is a failure of moral character so I'm having difficulty making sense of your point.
They truly don't. That's just part of the alienation.
When the opposition is called evil it's not because logic dictates it must be evil, it's called evil for the same reason it's called ugly, unintelligent, weak, cowardly and every other sort of derogatory adjective under the sun.
These accusations have little to do with how often people consider others things such as "ugly" or "weak", it's just signaling.
I disagree. There's an awful lot of "my position is obviously based on the data, so if you disagree it must be because you want to be evil". (In my opinion, the left does this more than the right, for whatever that's worth.)
If we expand "based on the data" to also include "based on my obviously correct ethical framework dictated by my obviously correct religion" then I figure the score is probably pretty close to even. The weird thing to me is how the far left has adopted behaviors that appear to be fundamentally religious in nature (imo) while fervently denying any such parallel.
Went down that rabbit hole a while ago. iOS works fine, but think they may have discontinued ad-hoc, or at least on macOS. Android has a bit issue with ad-hoc hot spot at that time. [1] But theoretically it should be able to do that.
I imagine in a situation like Iran, carrying a backpack full of WiFi gear to stay connected to the meshnet is a red flag.
Establishing a bunch of base stations is likely to raise red flags too.
It's pretty trivial for a nation-state that is jamming GPS to go around and jam WiFi or analyze WiFi spectrum for a meshnet operating in and around a protest area.
Yes, humans can be bad. But humans can change. Let's not start accepting bad stuff as not so bad, simply because it is "just human behavior".
reply