This kind of thing permeates through our society. We can all see it, we all know it's absurd, but we can't change it. That requires the people with the money and power on board. I don't need to tell you how they got that money and power. It's not only the buildings that have owners
Clean code was the first book I found when looking for books about writing clean code, go figure, and back then I found it very helpful. It's easy to criticize now that I'm so far removed from then (in both time and skill). Before this point I really had never even thought about the code's design, only its functionality. I wouldn't recommend it now, but this book played its role in my life
NYT writer discovers the term 'slop' days after NYT source leaks on 4chan. Specifically on a board where this is a common phrase. Cites 4chan. I'm connecting the dots
I just don't see how any of these examples from Udio or ElevenLabs could be considered good. To me they sound just bland enough that I may be fooled by them if I weren't paying close attention. If I do pay attention it sounds like a song accidentally came about. It sounds like music might in a dream. Eerie.
I think if I gave you 20 pieces of music, half of them made by AI, you wouldn't be able to tell which ones are made by AI much better than guessing randomly.
I am certain I could, in fact I'd bet a lot on it. I'd have a hard time distinguishing AI generated images at this point, but earlier on there were major indicators. This tech is still primitive. The lyrics are dead giveaways, the tracks all sound blended together. A 5 second snippet of a song seems coherent, but the songs never go anywhere. If you listen to a lot of music, and have a decent pair of headphones, it's immediately obvious. Someone who makes music would be able to identify the specific flaws better than me.
This looks like the perfect tool for rapid prototyping. I am not yet sold on this being a viable method to produce commercial games, but I do think you guys are on to something. Very cool!
This is a mixed bag to me, some of the features sound very cool. I like automatic pulling, doing away with stashing, splitting commits into checkpoints and merges, optional locking and supporting large binary files makes it super adaptable to non-programming workloads.
I don't think uploading on save is a wonderful idea for many reasons mentioned here. I don't agree with replacing forking with branching because forking is not only done to contribute to the mainline project. I'm against stuffing AI where solves no problem.
I also get the feeling that if Grace goes anywhere it's going to be commercialized. It's practically screaming paid service.
Not with something like GitHub Secret Scanning monitoring things, or we could imagine a local ML model automatically checking every save before it gets uploaded.
This is an easily-solved problem. And in case one slips through, versions are easy to delete in Grace.
I have many other things that aren't secrets, which I still do not want to be uploaded.
Don't get me wrong, many concepts are great (such as the watch/auto rebase). But I still would base everything on top of git. Call it the network effect or whatever, but every nice concept you promote could be done with a git wrapper. Version repos are a solved problem, and git is so much a de facto standard that fighting it will be ... interesting.
> or we could imagine a local ML model automatically checking every save before it gets uploaded.
It's so 2024 to not actually engineer things but say (only say) "we tackle it with some ML model". I have goosebumps from a though that VCS would require GB data file for the model or require (let be honest here, 99% more possible, nobody creates own models) an online chatgpt access.
> This is a mixed bag to me, some of the features sound very cool. I like automatic pulling, doing away with stashing, splitting commits into checkpoints and merges, optional locking and supporting large binary files makes it super adaptable to non-programming workloads.
Thank you, I really am trying to write something that meets the needs of developers in the late 2020's.
> I don't agree with replacing forking with branching because forking is not only done to contribute to the mainline project.
That's an interesting point.
I'll use "GitHub" below as a stand-in for "Git hoster", but they invented the fork, so, you know...
I start with the idea that forks are not a Git feature; they're a GitHub feature. They're bolted on to Git to enable open-source dev in lieu of opening up the main project to write access from everyone. You write to your own fork, which you have write access to, and then ask someone with write access on the main project (through a PR, usually, also a GitHub feature) to take your contribution and write it to the main project.
All of this is yet-another workaround that we're used to because of Git, but that doesn't mean that it's not a workaround, or that it's the best way to do it.
My design intent with personal branches instead of forks is to say: if you want to make a copy and go forth and work on it totally separately from the main project, cool, go ahead. But if you want to contribute to an open-source project, or have your own tweaks on it but still keep up-to-date with `main`, well, I'm writing a whole new VCS, let's rethink this part. Let's acknowledge that there's an important use case that forks have been the answer to so far, but that we can deliver using personal branches. Authorization in Grace won't just be at the repo-level; it will be at the branch level, too.
So you'll be able to create personal branches that you can write to, even if you can't write to `main` on an open-source project. And you'll be able to create PR's and have that code promoted by someone who does have access.
> I also get the feeling that if Grace goes anywhere it's going to be commercialized. It's practically screaming paid service.
It's 100% meant to be easily adopted by the large hosters and offered as a new, web-scale version control system.
I expect Grace to be offered for free, the way that Git currently is, for personal accounts. The big hosters don't compete on the version control level, they compete on the services above that (project management, issues, CI/CD, security, etc.) and that shouldn't change whenever the thing that replaces Git catches on.
And it's also designed to meet the needs of enterprise customers. I've been an enterprise developer for much of my career, so I have some idea of what that requires. There's no way that a replacement for Git can be successful without addressing enterprise needs, and since we're building from scratch, we don't have to bolt that on anymore.
Because of that, I don't see a way to use venture capital to create "VCS vNext" to go after Git. The win for a new VCS is going to be adoption by the big hosters, not the creation of a startup that would have to also build All The Things (project management, issues, CI/CD, security, etc.) just to have a shot.
100% open-source, built in the open, no way around it as far as I can see.
I'm not sure how that makes sense today, to me it's more of a novel idea than a solution to a problem. I use AI every day in my workflow and I honestly don't believe it's capable of reliably solving merge conflicts. GPT-4 can write a really nice method but can't integrate it into my code-base. If half of the proposed solutions are incorrect, I need to scrutinize all proposed solutions equally. Would I rather review likely inaccurate conflict resolutions, only to solve it myself afterwards, or resolve it myself from the get-go in a way that I know makes sense? Do I want to give my teammates the ability to click a button and introduce subtle merge bugs?
Don't get hung up on what GPT-4 can do. That's irrelevant. Even Sam Altman calls GPT-4 "mildly embarrassing".
"Don't skate to where the puck is, skate to where the puck is going." In 2028, for instance, will GPT-7 (or whatever) be able to handle solving a merge conflict? I expect it will.
It's totally cool. It's not a product yet, it's a one-person project so far. I'm not asking anyone for any money. I expect one day that it will be a product.
It's still an alpha (see the highlighted note towards the top of the readme). There are features I intend to ship in 1.0 that aren't even started.
And even if all goes as well as possible, it won't ship 1.0 until 2026 at the earliest, which means early adopters, and mass adoption not until 2027 or 2028.
If you're going after something as big as Git, it takes time. It would be irresponsible to not think about where computing will be in a few years vs. today as I work on it.
Honestly it's so poorly written it's ambiguous as to whether the article refers to "notepad" the program or a physical notepad. The earlier sections talk about compiling often, notepad lacking fancy IDE features, etc. This whole article reads like an AI generated attempt to advertise the Amazon links at the bottom of the page.
Was this even written by a human? The connections and misconnections seem like they could only have been made by some dozey AI. Physical notepads, and Notepad, the old Windows stalwart. It seems very sus. Now ask would using Crystals make you a better developer? Juxtapose some new-age thinking about the harmony of lattice structures with a Ruby derived language. Could be a fun read.
+100 on the amazon links.
I'm 90% sure this was at least partially written by GPT. Idk if it's for the headings, that flourished way of speaking, or the general vibe after using it for so long; but it definitely looks like it
reply