That does not make any sense. Plenty of things on the internet are Open Source / Non-profit yet it affects us a lot. Of course it’s good to give people relying on your stuff heads-up etc.
It's "let's not take your picture inside of the office because everyone hates the inside of offices. let's take your picture outside instead, near the office, but not featuring the office. oh, that tree over there is nice, but darn, the lighting underneath its branches isn't great. hey, that hedge over there reads great in light test and it works with what you're wearing, so, yeah, that'll do just fine."
Don't you just put tick "know this already" or whatever mechanism is used. It'll be asked a couple of times but it shouldn't be "relearned from scratch".
It does lead to people loosing their job. If you have a pile of dirt that needs 3 people to move it with buckets but now 1 person can move the same pile with a wheelbarrow then the 2 others are out of a job.
Same as when one developer with AI can do the job of 3 developers and the other 2 are fired.
do you have stats on moving of dirt with buckets vs. moving with wheelbarrows? Or is this just an assumption you are making? I think probably an assumption because how often do people move piles of dirt without wheelbarrows nowadays so where would you actually have your data from?
In my anecdotal experience moving piles of dirt manually (for large piles of dirt) it is generally the digging up of the dirt that takes the most effort, if I had to move it with buckets or a wheelbarrow I would still expect that to be the case.
I would furthermore expect that there are some functions at work in modelling the moving of large piles of dirt using manual labor.
Your model may make sense with a small pile of dirt but I don't think you will find 1 remains and 2 go, at best 1 goes and you take a bit longer to move the pile.
Also, this is just my observations of having had large piles of dirt to move with manual labor (including wheelbarrows and several of those) As you scale up the amount of people you could drop by adding wheelbarrows goes down, because again the main problem is the digging. The wheelbarrows becomes a thing you trade off diggers on running. You will want to have more wheelbarrows that wheelbarrow users so that diggers can fill wheelbarrows while the users are running the already filled wheelbarrows to where the dirt is being dumped.
At this point then you would probably want to drop the wheelbarrow analogy and go to a backhoe and a truck, but then all of the various observations of the other flaws in the wheelbarrow argument become apparent, such as the factories to build backhoes and trucks, the training for backhoe operator etc. All leading to a relatively strong argument that existence of backhoes and trucks are a boost to the environment, potential job creator and those jobs will be more skilled jobs leading to higher wages in the economy.
I do the same. On Mac I use macwhisper. The transcription does not have to be correct. Lots of times it writes the wrong word when talking about technical stuff but Claude understands which word I mean from context
I feel that was more true 1-2 years ago. These days I find Claude Code write almost as good (or as bad depending on your perspective) Elixir code as JavaScript code and there must be less Elixir code in the training data.
I personally find it much more painful to generate valid Rust code that compiles and does what I want than e.g. valid python code that runs and does what I want.
i think it's pretty clear that some of "the things you expect to make an LLM good at a language" (like strong typing) are not actually the case. other things like "don't indirect your code by jumping to something unexpected" might be more important.
If anything llms would be poorer in codegen for static languages because they are more verbose - More tokens to generate and use limited context windows parsing code.
The advantage rather for llms in strongly typed languages is that compilers can catch errors early and give the model early automated feedback so you don’t have to.
With weakly typed (and typically interpreted) languages they will need to run the code which maybe quite slow to do so or not realistic.
Simply put agentic coding loops prefer stronger static analysis capabilities.
not necessarily. if your refactoring loop requires too many cycles you'll fall off the attention context window.
also, some nonstatic languages have a habit of having least surprise in their codebases -- it's often possible to effectively guess the types flowing through at the callsite. zero refactoring feedback necessary is better than even one.
I’ve found Claude (at least until Opus 4) would routinely fail at writing a bash script. For example it would end an if block with }. Or get completely lost with environment variables and subshells.
But those are exactly the same mistakes most humans make when writing bash scripts, which makes them inherently flaky.
Ask it to write code in a language with types, a “logical” syntax where there are no tricky gotchas, with strict types, and a compiler which enforces those rules, and while LLMs struggle to begin with, they eventually produce code which is nearly clean and bug free. Works much better if there is an existing codebase where they can observe and learn from existing patterns.
On the other hand asking them to write JavaScript and Python, sure they fly, but they confidently implement code full of hidden bugs.
The whole “amount of training data” is completely overblown. I’ve seen code do well even with my own made up DSL. If the rules are logical and you explain the rules to it and show it existing patterns, the can mostly do alright. Conversely there is so much bad JavaScript and Python code in their training data that I struggle to get them to produce code in my style in these languages.
Other major countries that have adopted eInvoicing have kept it optional for a few reasons:
- It's a barrier for small businesses, or those which seldomly invoice, such as craft and hobby businesses (particularly remote online businesses).
- Large companies see eInvoicing as a cost saving method and force it upon their vendors. This reduces the need to make it mandatory and provides a financial incentive for companies to adopt eInvoicing (i.e. more carrot, less stick.)
The EU has a solid trend of finding ways to self-harm when introducing reforms. This self-harm story segue's into how the EU is considering implementing an Australian-style social media restriction for children:
Quote from abc.net.au below:
European Commission president Ursula von der Leyen told the audience she had been "inspired" by Australia's "bold" move to introduce the ban.
"As a mother of seven children and grandmother of five, I share their view," she said.
The European Parliament has since passed a non-legislative report that would set a minimum age of 16 for social media, while allowing those aged 13 to 15 with parental consent.
-- end quote --
Here the EU is walking down the path of another bad implementation.
Limiting the age for social media only works if it's mandatory for all children, otherwise kids will just pester their parents for access. In the EU's plan the parents become the "bad guy" in that arrangement, the home becomes the battleground for obtaining access to social media.
The EU's plan also means that social media remains relevant for young people, where access may be needed for arranging social activities and sports, and those which don't have it are either inconvenienced or miss out. Meanwhile the Australian implementation removes that purpose as no kids are allowed on the platform, thus there are no "haves" and "have nots" kids.
Finally, and probably most importantly, advertisers, data brokers, and bad actors will still continue to target children through social media networks, since they will still be there in useful numbers.
Yea, but EU can of course have a common standard and not make it mandatory. It’s not more strange than US making federal standard vs different standards in each state.
Yes I agree, and this would be the ideal and most efficient outcome, and it should be repeated: an EU-wide common standard, which can then be optionally adopted by businesses in each member state alongside not forbidding existing invoicing methods.
In this scenario we can anticipate that business practices will shift to the common standard over time, and that would include the accounting software used by new businesses: resulting in a phased conversion with minimal disruptions to running a business.
reply