I frankly don't buy into this trope that a lack of monetary cost should shield something from criticism. Anything created by humans for other humans, especially tools meant for getting work done, should certainly be open to evaluation/judgement/critcism, regardless of whether the creator chooses to charge for it.
And it's not like Golang is some freshman student's hobby project; it was created by one of the world's largest tech companies, by people with a strong pedigree in programming language design.
I can't speak about Dart, but Carbon had just barely started development when it was first announced 4 years ago, and is currently presented as an experimental language that is not yet ready for use [0].
This is a limitation of the training data. If you were uncertain about something, you wouldn’t write a book about it. The kinds of people you’re talking about tend to generate far more text in their lives than others, because they can spend more time generating - writing books, blogposts, whatever - and less time thinking and working and actually doing things. The models never say they’re uncertain because we never say we’re uncertain, or at least we don’t write it down anywhere.
If you change it from asking a question to giving an instruction, how many humans do you know that have trouble saying no to things that aren't reasonable? I'd argue that pretty much every human will refuse to do most things you might instruct them to do, whereas an LLM will happily attempt most things you ask them to do for you, regardless of whether they're capable of succeeding, and it's up to you to figure out if they actually did it right or not. There are tasks where this is extremely useful, but they're ones that are extremely low risk and can easily be audited upon completion. This isn't anywhere near the level of what a human is capable of.
I can sympathize; I shudder to think of how many total hours of my life I've spent tweaking fonts in my text editors.
That said, these days I almost exclusively use Input Mono [0], specifically the "Narrow" variety. With an occasional sprinkling of either Iosevka Fixed or PragmataPro Mono.
Doesn't work for me either. I'm running Sequoia on an Intel Mac. When the saver runs, it says "No art sources configured. Open Screen Saver Options to add pack URLs or a local folder." I've added all 5 of the recommended pack URLs listed on the GitHub page, and even tried clicking the Refetch Packs button, but it won't show anything except that message.
Opinionated design was great back when Apple's Human Interface Guidelines were based on concrete user testing and accessibility principles. The farther we get from the Steve Jobs era, the more their UI design is based on whatever they think looks pretty, with usability concerns taking a back seat.
It was good because it was both Opinionated (in other words, the path to write software that follows the design was easy, and the paths to write software that violated the design were hard), and also well-researched by human interface experts.
Now what we appear to have is "someone's opinion" design. A bunch of artists decided their portfolios were a little light and they needed to get their paintbrushes out to do something. I don't work at Apple, but my guess is that their HI area slowly morphed from actual HCI experts into an art department, yet retained their power as experts in machine interaction.
So here we are, we still have Opinionated design, but it might just be based on some VP's vibes rather than research.
I don't like to paint Apple as being completely incompetent (but damn have they been screwing stuff up), but I do think trying to solidify the experiences around a common codebase has become untenable. The idea is great thought - write one app that works on macOS, iPadOS, iPhoneOS, visionOS, etc. What a time saver that is for developers - but the problem is that screen sizes and interactions with those different platforms vary. Yes, resizing a window with your clunky finger needs a bit more wriggle room, while a pixel precise mouse or touchpad is a lot different.
The flaw in trying to detect AI by its use of particular idioms is that it would have learned these idioms from its training corpus, which consists of writings from actual human beings.
In other words, some people actually write like this.
Key word here being “some” people. Not nearly at high enough frequency that this way of talking was noticeable before. AI uses this pattern CONSTANTLY and it’s very fucking irritating.
Have you ever met human beings that constantly reuse a certain idiom/figure of speech/linguistic pattern?
The valley girl using "like" every other word, for example?
Or I had a colleague who would use the expression "we can say" (in French, because we were speaking in French) basically every couple sentences for a bit.
Humans also repeat speech/linguistic patterns, therefore "repetition of the same pattern" is not sufficient to mark text as produced by AI :)
Yes but there are a lot more "idiom personalities" in humans (you just mentioned several) than there is in AI. Basically every English-language interaction with AI anywhere in the world produces more or less the same argot and style. Its like (heh) we're all talking to the same valley girl stereotype.
I find takes like this very strange. Whether or not it gives the correct information, it's clearly not designed to give false information to factual queries.
The design of it is based on the intention of the people creating it, not the actual outcome, and it's pretty clear from all available information, plus a general understanding of incentives, that it's designed to be as accurate as possible, even if it does make errors.
Humans update their model of the world as they receive new information.
LLMs have static weights, therefore they cannot not have a concept of truth. If the world changes, they insist on the information that was in their training data. There is nothing that forces an LLM to follow reality.
And it's not like Golang is some freshman student's hobby project; it was created by one of the world's largest tech companies, by people with a strong pedigree in programming language design.
reply