Why not treat AI-generated art as scaffolding in cases like this? Use the AI-generated music or sprites so that in early stages, your game can more closely resemble a complete game and you can think through your aesthetic preferences with concrete examples.
Then, if the project lives and grows long enough to be published, you start soliciting involvement from human artists but with minimal budgetary commitments. If your project gains momentum, you start allocating more realistic incentives for human collaborators.
I chose to listen to the blog post instead of just reading it. I don't know how much if it is just the idea of AI-generated music for me, but the listening experience was extremely repulsive.
(I mean that seriously, actually— I don't think people who have used both but prefer Vim would generally list "more powerful" among their reasons for preferring Vim. It's usually more about not liking Lisp, some kind of "minimalism", or a different sensibility about composability.)
Well, Vim is not some concrete implementation, it's not like "Photoshop", where it means a specific product line, it's an idea. "The power of Vim" is its grammar, the grammar is design, and designs port - that's why Helix, Kakoune, Evil-mode, Meow, etc. exist. I agree that the "command structure" you're referring to may feel better than modifier-chord scheme of vanilla Emacs, where commands are a flat namespace - a mixed bag of bindings with no algebra connecting them.
However, the years of muscle-memory might be deceiving. Vim's objects are text-shaped - the design has no idea of what a function or an expression is. Vim's grammar is excellent but its nouns are approximations. The modern answer perhaps to keep the grammar and upgrade the nouns, which is what tree-sitter text objects attempt of doing.
Anyway, my main point is not about the grammar, but about the grand idea. The idea of Vim is a beautiful, pragmatic model and it can be perfectly used outside of Neovim. If you truly want to take it to another level, maybe consider combining it with the power of Emacs.
Innovation and insight rarely happen within a single substrate - you typically need to explore intersections of divergent disciplines. Emacs itself is rooted in another grand idea, arguably one of the most important ideas in all the history of computer science - a practical notation for lambda calculus widely known as "Lisp". Once you understand the immense, pragmatic value of that idea, it eliminates any skepticism you might have held against it.
If you think Emacsians don't get vim, well, you're misinformed. There are thousands of vimmers who choose to be viming in Emacs. Because Emacs vims better. As a die-hard vimmer I can attest.
You would think that no one would be stupid enough to use Fable or Sol for small one-off tasks like filtering tweets, but AI has opened up a lot of avenues for stupid people to ship code. It's only going to get worse.
yeah man it's me who's stupid and not you when i use an example of the author who claims that you can use pro subscription on all of the mundane tasks w/o going over the budget. sure. my point is that you can only use it with cheaper models. also some tweets are fairly dense in their compression/context, so yeah sometimes it's necessary.
If you factor in cost then it may well be, but it's definitely the case that the high-end models can get you significantly better results than the cheaper models even for tasks that feel like they should be straightforward.
Almost never do software companies even attempt to design secure systems. I'm not sure this requires new fundamental research so much as slightly giving a shit.
Regulation and an ethics/licensing board à la Engineers would probably be a good start. If management knows they can’t tell you to do a bad or sloppy job because no one in your industry worth a damn will… everyone wins.
I just see unintended (but easily imaginable) consequences that don't fix anything.
Especially since the world isn't Dilbert where your boss goes "oh, authz? lol nah, just yolo it" and you go "dangit, alright boss". Instead, security requires eternal vigilance and zero missteps along the thousands a project takes in its lifetime.
I think there's a reason HNers who pitch this idea never give any concrete examples of entailments of their proposal: it doesn't even sound good superficially. e.g. How this actually changes security issues. In fact it just sounds even more convenient to blame engineers.
Bullshitting is how LLMs work. It doesn't require active encouragement. All it takes is a machine without consciousness or physical access to the world and an actually-lived life. A training set that contains lots of confident answers and few to no refusals doesn't help either.
An LLM outputs tokens, one-by-one. It stops the loop if it outputs the end-of-text token. Which is, of course, statistically much rarer than any other kind of token.
(This is why you cannot, in general, prompt an LLM with something like "don't answer if the result is correct". It has to output something, by design.)
When Apple Sherlocks something, aren't their implementations usually worse? Typically the thing being Sherlock'd is very mature and featureful, and Apple's implementation is much less capable and has undergone much less user testing, at least at the outset.
To be clear, this does technically meet the very minimal commitment[1] they gave when announcing the acquisition:
> In the coming weeks, we will relicense all of our source-available tools, including Tart, Vetu and Orchard under a more permissive license. (HN discussion: https://news.ycombinator.com/item?id=47730194)
In this case they moved from one source-available license (Fair Source License v0.9 with seat restrictions) to another (Fair Source License 1.1-ALv2 without seat restrictions), with the same sort of restrictions on field-of-endeavor as before.
Why they've chosen this isn't super clear, as (1) there are already open-source alternatives that use the same storage formats as Tart, like Lume[2]; and (2) Tart is certainly already in the training sets of all of OpenAI's "direct competitors", who are practically held back little or not at all by the restrictions of the FSL. The only entities this really restricts are F/OSS distributions which might otherwise include Tart as a first-class package in their distros. :-\
Writing better exams, even if they're more expensive to grade, and removing homework from grading as far as possible addresses this problem well wherever it's applicable. Senior-level math courses at many universities are already like this: homework is ungraded, or counts for little, and it's possible for students to "cheat" on the homework by copying another student instead of struggling through the exercises. But the students who do that don't learn much, if at all, and predictably fail the exams. Professors warn students at the beginning of the class and tell them how this will work, something like:
> You can always ask me for feedback on your homework and I will mark up every part of it, but you won't receive a grade for homework. However, if you don't do the homework and take your time with it, you will fail the class. My office hours are in the syllabus and you're strongly encouraged to use them. There will be an early exam to give you a chance to know whether you are likely to fail this class before you lose your chance to drop it.
Correctness is harder to adjudicate in some humanities disciplines but the format of these exams is actually not super different from essay tests (when a math professor grades a proof, they're inspecting specialized prose for validity, coherence, persuasion in a way that also reveals knowledge).
When you don't rely on homework for determining whether or not a student passes the class, you make cheating on the homework into the student's problem instead of the professor's or the university's. Students have the right incentives to solve problems for which they are the ones responsible, and they figure it out after one failed (or ideally, dropped) class at worst.
Then, if the project lives and grows long enough to be published, you start soliciting involvement from human artists but with minimal budgetary commitments. If your project gains momentum, you start allocating more realistic incentives for human collaborators.
reply