Neel Nanda (of Google Deepmind - his part begins on page 33) discusses his opinions on the paper, and the small-scale replication he performed on an open-weight model.
Lots of things were disallowed in 0.19, but probably the most disruptive were that custom native modules were disallowed (which basically means that, only certain official packages would now be allowed to directly call native JavaScript), and the package manager was locked down (which means that you can only install packages from the official elm repository, not GitHub or anywhere else).
You can still indirectly call native JavaScript, in a message-passing kind of way (via Ports or custom elements) but these changes were still really disruptive to many codebases.
After reading through several pages of their comments, I'm roughly 100% certain that the user you're referring to is not a bot and is not karma farming. They just post a lot.
> Wikipedia has a bunch of languages that were used by like one person, because there is published material on them
No. It's more like, there are plenty of articles on Wikipedia that don't meet Wikipedia's notability guidelines AT ALL, but when you write an article on Wikipedia and enough time passes without anyone noticing that the article is poorly sourced, then eventually the tendency of Wikipedia community is to just keep it.
This is what has led to the what-about-ism regarding Odin's deletion - there are lots of other programming languages that also don't meet the notability guidelines, yet, to this day, still have Wikipedia articles.
Could someone come along and propose deletion for such articles? Yes, of course. You yourself could go do that right now, if you want. But nobody's getting paid for such work, so someone has to want to. The tendency of Wikipedia editors is that, when an article is many years old, they would rather flag it for improvement rather than simply throw away years of fellow editors' work. Whereas an article that's brand new is likely to not have much work put into it, and also more likely to be self-promotion and/or spam.
This is very frustrating for people who create Wikipedia articles and have them deleted. "You mean, whether or not my non-notable article gets deleted or not is just the luck of whether someone comes along and notices that it's not notable?" Yep. Like I said, nobody's getting paid for deletion work.
"pump the price of a token" seems like the complex part that you're hand-waving. Either this token has a bunch of other traders (in which case, it's not trivial to simply "pump" its fair-market price by your own effort), or your alt wallets are themselves most of the liquidity (in which case, you're really just transacting with yourself, which is trivial to trace)
> people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly
You could always use setuid to allow the agent to run designated commands whose operation depends on the files, without the agent itself being able to access the files.
No, not all vulnerabilities are bugs. "Bug" implies a system working in a way its creators did not intend, but a system can be working exactly as intended yet have a vulnerability.
For example, if you allow weak passwords, then you have a trivial vulnerability to people guessing other people's passwords. But nothing about the login system is working differently from how anyone intended. It's just that the intentions themselves were naïve.
"Fintech" is extremely broad, and most of what gets called "Fintech" is really communication. Communication between firms, between traders, between systems, between ledgers, etc. There is no industry-wide "right" way to program anything, because the right way is ultimately whatever way the other party you're communicating with will understand.
If you're dealing with a party who tracks currency in cents, then tracking currency with more precision than that is going to lead to rounding disagreements. Vice versa if you deal in cents but they deal in tenths of cents. And so on for all the other advice in this document.
> Implication 1: Lower entry barrier makes software lower-respect field
Maybe? This one's kind of subjective. I'm sure there are some people who will feel this way, and many who won't.
Do you respect artists less, now that you can make AI images?
As for pay, it seems unlikely to me that the job title of "software engineer" is going to see a significant decrease in median wage as a result of AI. Though there may simply be fewer "software engineer" jobs and more "prompt engineer" jobs.
> Implication 2: Optionality changes the commitment to software products
It's not clear to me that the typical decision-making process the average company was using to choose (for example) project management software, is going to be significantly different in the AI era than before. "Let's use JIRA, since that's what everyone else uses."
Making decisions this way is low-risk, and lower-cost than the token cost of vibe-coding something custom. The analogy to dating apps doesn't work - dating apps reward searching far and wide for something perfect, whereas the business world rewards going with what you know and making decisions quickly.
> Implication 3: The middle class of software products will disappear
I don't believe the cost of software creation is approaching zero. People are taking this concept too far and too literally. First of all, obviously there are token costs. And secondly, obviously there is still a time and effort requirement involved in maintaining anything, even via vibe-coding. Most companies have absolutely no reason to prefer to incur these costs rather than simply paying the man his $50/month.
But thirdly, and probably most importantly, there's the inherent cost of merely being responsible for something. Like I wrote earlier, decisionmakers want to minimize risk. The mere fact of being responsible for something - of it being someone's fault if something goes wrong - is a dire political cost, which most business leaders try to avoid by buying external rather than creating in-house. The SaaS market isn't going anywhere.
> Implication 4: If you want to win, sell services, not products
Service automation is a fruit that has already been mostly squeezed by conventional software.
That is to say - the space of things that traditional software can't already automate, that LLMs would be capable of automating, and that LLMs would be reliable and efficient enough at to significantly move the needle on real productivity - is small.
(Ironically, software development is one of the few things in that space. Since when you automate software development you can also automate the creation of tests that (at least attempt to) validate the correctness of the software itself. Not so much for legal documents.)
Anonymous records aren't complex in principle. The main challenge Haskell has always faced in this area, is the simple fact that its type system (and syntax) weren't designed for anonymous records from the start, so they have to be shoehorned in without breaking existing semantics.
PureScript has much better support for row polymorphism for this reason.
I don't think if-expressions have to affect existing semantics. Basically, in the parser you would have two different kinds of AST nodes, one for when the `if` keyword is encountered in statement position and another for when it's encountered in expression position.
Right now, `if` in expression position is just a syntax error ("unexpected symbol")
There are ways to go into debt without dealing with banks. Any time you use something and are charged afterwards, it's a debt (which you could fail to pay by being broke by the time the invoice arrives). Common example - rent/lease. Or gas/electricity.
Case in point: https://github.com/postgres/postgres/blob/master/src/common/...