• 53 Posts
  • 85 Comments
Joined 1 year ago
cake
Cake day: July 29th, 2023

help-circle













  • I often felt that current ML speeds up newbie devs by effectively teaching them the language and libraries — but slows down experts that already know the stack well from memory.

    It depends. You don’t need LLMs to write stuff for you that you already know. You use them to take.care of the drudge work or explore things you are not familiar with. Things like Copilot’s /explain can speed up onboarding even for seasoned developers, and Copilot can also help you speed up iterations on proofs of concept. For example, I’ve been using Copilot to experiment with some changes to the software architecture of some projects I own, and it’s fantastic at generating code following specific design patterns. It’s also fantastic to get it to iterate designs in near-real.time by prompting it with directives such as “repeat the last example but implementing X with design pattern Y and moving the implementation to Z”. You are presented with examples that you can browse through and get a taste of what you’d get, but with a fraction of the time. To top things off, you can prompt Copilot to present pros and cons and even propose optimizations.

    Like any tool, it has its purposes. You just need to learn how to use it.


  • I don’t use chat, it’s usually useless.

    I think Chat is the most useful feature of Copilot. Prompts like /docs work impeccably, but /explain and /optimize is also pretty good. /tests is hit-and-miss if you have zero tests and require too much context if you already have them. More often than not /fix is a waste of time.

    Where I found Copilot to be quite useful is something unexpected: naming things. You can prompt it to give suggestions, you can ask it to refactor things for you. Quite nice.

    I think that Claude is far better at generating code, and explore new stuff, but Claude is also down and broken extremely often,not to mention it’s annoying limit of 10 questions per half a day.


  • I use chat the most. It’s pretty good once you understand the importance of building context, set up personas, and feed it workable prompts. The biggest mistake I see people do is presume that you can expect it to output gold when inputting garbage.

    Once you build up an understanding of what personas work for your personal tastes and what context you need to have, it can output impressive results. The most success I’ve been having is with somewhat complex refactorizations. Stuff like “refactor X so that Y and Y” can save you a lot of time.

    The most disappointing experience has been with writing unit tests. copilot has this infuriating tendency to remove old tests when you’re prompting it to add new ones. You need to explicitly request it to append tests to file X without overwriting existing tests for it not to mess up, and even then results are sketchy. For unit tests it’s also important to setup good contexts otherwise whatever time you save by prompting copilot to write them will be wasted refactoring code to use specific frameworks and follow specific styles.


  • Like most have already said, the auto complete is top tier (…)

    My experience is the exact opposite. Even though it has its moments, more often than not it just hallucinates and proposes a lot of stuff that neither matches definitions nor could possibly compile. I guess that this might reflect the impact of having classes with similar names in multiple namespaces but it’s bad to the point I prefer to rely exclusively on plain old autocorrelation.









  • I don’t see why using submodules as a package manager should excuse their endless bugs.

    I don’t know what are these “endless bugs” you’re talking about. Submodules might have a UX that’s rough on the edges, but there are really no moving parts in them as they basically amount to cloning a repo and checking out a specific commit.

    Do you actually have any specific, tangible issue with submodules? Even in the cases you’re clearly and grossly misusing them


  • Aside from the obvious UX disaster, Git has some big issues:

    I find this blend of claims amusing. I’ve been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called “disasters”. Odd.

    What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn’t, but I would not call any of these “disasters”. The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn’t have been bundled. It’s nothing an interactive rebase doesn’t solve, but it’s multiple steps that could be one.

    Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.





  • Because this is a casual discussion and that’d be more effort than I’m willing to put in.

    I didn’t asked you to write a research paper. You accused Git of suffering from usability issues and I asked you to provide concrete examples.

    And apparently that’s an impossible task for you.

    If you cannot come up with a single example and instead write a wall of text on you cannot put the effort to even provide a single opinion… What does this say about your claims?





  • I initially found git a bit confusing because I was familiar with mercurial first, where a “branch” is basically an attribute of a commit and every commit exists on exactly one branch.

    To be fair, Mercurial has some poor design choices which leads to a very different mental model of how things are expected to operate in Git. For starters, basic features such as stashing local changes were an afterthought that you had to install a plugin to serve as a stopgap solution.




  • I think a common misconception is that there’s a “right way to do git” - for example: “we must use Gitflow, that’s the way to do it”.

    I don’t think this is a valid take. Conventions or standardizations are adopted voluntarily by each team, and they are certainly not a trait of a tool. Complaining about gitflow as if it’s a trait of Git is like complaining that Java is hard because you need to use camelCase.

    Also, there is nothing particularly complex or hard with gitflow. You branch out, and you merge.