• 0 posts
  • 22 comments
Joined 3 years ago
Cake day: June 19th, 2023
  • Do you understand how bitmaps and raster drawing works?

    Yes I know the difference between vector and bitmaps

    Everything is represented as a 2d array of pixels.

    Only after the rasterization has taken place.

    The circle selection before you paint can be moved/scaled/etc and then when you actually want to draw the circle trace the path with the appropriate thickness and use antialiasing if you need to smooth it.

    The problem is that the selection itself can lose information, it’s handled internally as a raster mask. That’s why you should use a real vector shape.

    If you want to make vector drawings, take a look at InkScape. GIMP is the wrong tool for that, so use the right tool for the job if that’s what you want to do.

    No. Raster editors can support vector shapes. They vectors are rasterized during the final export, not while creating the shape (which is lossy and what selection shapes are).

    Look at how to create, move and transform a circle in photoshop (or if you don’t want to give adobe money, use photopea).

  • That’s not a circle, that’s a grid of pixels being colored in. It’s a lossy representation of something else.

    A circle is a shape which is a graphics primitive. Graphics primitives can be moved, transformed, skewed, etc… with no loss of information.

    If you do that with a grid of pixels, you’re going to lose information.


    Edit: Five downvotes. Apparently people don’t know how to use vectors in bitmap authoring software, or why selections are the lossy way to create shapes. See details in my comments below.

  • You get the LLM to write code quickly and then you review it and perform experiments manually.

    I think this is where the issue is, the word “review”.

    Reviewing comes in two different types: non-trivial reviews and trivial reviews.


    Non-trivial change example: Create a presentation where the user flow follows a flow chart.

    Someone could go to an LLM, prompt it with “create a presentation that follows this flow chart” followed by the mermaid syntax of the flowchart.

    The LLM will give you back an array of slides where certain functions/actions/triggers/etc… navigates to a different slide based on its index within the array.

    But if you ask a person to do it, they might sit there for a while, try a few different attempts to understand the problem better, then come back to you with some typed generics and a map/dictionary/object/associative-array/etc… with slides in it, and functions/actions/triggers/etc… that navigate to a flow chart by a slide’s id.

    Two different bits of code to review from two different sources.

    You can choose to do one of the following:

    • “LGTM” the changes (in which case it wasn’t actually reviewed),
    • Read through the entire change to try and comprehend it until you find a part that you don’t understand
      • Sidenote: If you didn’t find a part that you didn’t understand, then the change isn’t actually non-trivial, so you can refer to the “trivial change example” below. This section is about non-trivial changes.

    When asking the LLM a question about the part that you didn’t understand, it will either give you:

    • A completely different changeset, so now you have something completely different to review. And by the fact of the longest part of programming being digesting code you didn’t write, in effect you’ve taken a long-cut and could have written it yourself faster. (This is part of where the “LLMs make programmers take longer” observation comes from)
    • A post-hoc justification for it. Which would by it’s nature not have take place before the code was written, which makes it unable to have actually affected the code, and thus not actually be a valid reason for why the code is the way it is. So you don’t get a valid answer, you just get a convincing one.

    When asking the person why they did it, they’ll tell you they tried a few attempts to get their head around it, and mid-attempt they accidentally commented-out one of the slides which created an unseen error when one of the functions/actions/triggers/etc… tried to go to a slide that didn’t exist. So to prevent that problem from occurring again, they wrote another attempt where they used types/generics such that every slide’s id and reference to every slide’s id was type checked. That way, if a reference was ever incorrect or initially correct but made incorrect by a later change somewhere else, the editor would alert you before you even tried to compile your code. With that response, you now have the reasoning behind the non-trivial thing you didn’t understand.


    Trivial change example: Changing a color from “orange” to “red”.

    Someone could go to an LLM’s chat window and type, “Change the color to red”.

    But it’d be faster to just double click the word “orange” to select it, then type the word “red”.

    So for trivial examples, it doesn’t really make much sense to use an LLM, it’s literally faster to do it yourself then review your own trivial changes in a diff.


    Coming back to the problem of the word “review”:

    You get the LLM to write code quickly and then you review it and perform experiments manually.

    • Non-trivial reviews require back and forth communication. Reviews can be convincing without being valid. The review’s validity depends upon the validity of reasoning within that communication.
    • Trivial reviews are trivial, so there’s no point to using an LLM in the first place

    That means that reviews of LLM outputted code by their nature are either invalid and/or non-optimal.

    My advice: cut out the crutch/middle-man and do the hard work of establishing that rock-solid understanding. You’ll be much better off in the long run.

  • But that’s what I already have and it doesn’t work properly.

    Here’s my minimal test case for a typical mid-work layout:

    • Open a window
    • Open 4 new tabs
    • Type the tab’s number in each tab so it’s easy to tell them apart when trying to switch between them
    • Drag tabs 3 and 4 to the right side of the window so that the result is a window with 2 panes each of which contain 2 unique tabs.
    • Click on Tab 1 to select it

    Now the test:

    • Press Ctrl + Tab to switch to tab 2. Works
    • Press Ctrl + Tab to switch to tab 3. Does not work, tab 1 is selected instead

    The tab switching is stuck switching only the tabs in that pane, counter to the way every other tabbed program works.

    Holding Ctrl + Tab should cycle through every tab.

  • So just because I didn’t write a book means I could never understand it from reading it?

    Reading a book does not give you the same knowledge as the author.

    The author may have had to choose between two different pieces of exclusive information to add to the book, they may have written information then had to remove it for some reason, or may have had to exclude certain information it altogether.

    You would never know if they did, or the reasons behind why they did what they did if you only read the book.


    Are editors useless in the world of book publishing? Then what is the point of code review?

    The difference between your book analogy and human code review is you can actually talk with the author in a bi-directional channel to gain a deeper understanding of what they did, and why they did it.

    Book editors and human code reviewers are the same in that respect, they develop the deeper understanding that simply reading does not provide.


    When it comes to LLMs: that bi-directional channel doesn’t exist, only the illusion of one.

    LLMs don’t have the capacity to think things through, their reasoning is actually post-hoc justifications for their previous output, not a result of a priori thought. There is no actual understanding that could be gleaned because it literally doesn’t exist.

    To train an LLM you need more data and feedback than can be manually tagged, so tags and feedback are generated automatically. This means that they are not being trained against ground truths, they’re being trained against a confidence checker. To an LLM, there is literally no difference between a correct answer and a confident answer.

    That’s why they seem so stupid when they give an answer that is obviously incorrect.

    They are confidence machines, they produce confident sounding answers.

    The problem is that human psychology is wired not to be discern the difference when the output’s falseness isn’t immediately obvious.

  • I tried to switch to Zed at the start of the year but couldn’t Zed’s tabs to work.

    It seems like the biggest paper cut preventing users from switching to Zed and they don’t seemed interested in fixing it.

    I couldn’t find any settings to fix it.

    Were you able to figure it out?

    How every program (e.g. editors, browsers, file explorers, etc…) works:

    • Ctrl + Tab switches to the next tab
    • Ctrl + Shift + Tab switches to the previous tab

    How Zed works:

    • Ctrl + Tab and Ctrl + Shift + Tab brings up a tab switcher widget which doesn’t even list all tabs
  • Not always.

    Yes always. To paraphrase Feynmann: What you did not create, you have not understood.

    Prototyping can be valuable in many circumstances when you don’t know the shape you’d like the code to take.

    Yes

    Sometimes you need to try something before you know if it’s right.

    Yes

    I’d rather throw away prototype code written by an LLM than code I had to write the hard way.

    No.

    If you consider writing your own code “the hard way”, then your goal should be becoming better at prototyping yourself. It’s a skill that you need to requires purposeful effort to strengthen. But once you have it, you get both the understanding behind the code and the prototype.

  • Yes but that tracks issues of all severities and with all of GitHub’s services of which there are a great many.

    Yes. Remember there are two different main types of github users.

    1. Devs who just use github as a repo host, and maybe as an issue tracker
    2. Devs who use github for everything. Repo hosting, issue tracking, CI/CD pipelines, linting, testing, deployments, code editing, auth providing, and LLM slop generation.

    Users in the first group won’t notice anything going wrong until only the services they use are affected.

    Also “days since incident” is a terrible metric because it doesn’t capture how long the incidents last.

    Users in the second group experience full blown “intelligence brownouts” when any service goes down because they’re coupled so strongly together. That’s why that metric is useful (and also because it shows the true “number of nines” used in SLAs).

    And, github is doing every insidious trick they know to push group 1 users into becoming group 2 users.

    So yes. I am not sure GitHub is worse.

    If github weren’t trying to force users into the second group, then I think we could give them some more leeway here. But they’re not, so yes github is much much worse.


    […] For example the latest incident is that copilot had degraded performance with Fable due to an Anthropic issue. It only last 18 minutes, only affected part of a part of their service, and it wasn’t even their fault!

    That’s very different to “all of GitHub is down for 7 hours”.

    If you want something a bit more granular, then you can check: https://mrshu.github.io/github-statuses/

  • I’m perfectly happy with this.

    Why?

    Because at the end of the day, the users of the code forge can be broken up into three categories:

    1. Traditional coders with human made projects
    2. Vibe-coders who slop out 100 throw away projects, each of which is a dead project as soon as that user moves onto the next project
    3. Vibe-coders who focus work on only a single project.

    Category 1:

    • Code forges were already valuable before LLMs, so we already have a proof of value/utility/whatever for hosting projects from users in category 1.

    Category 2:

    • Projects from the users in category 2 have a half life of a couple of weeks.
    • They’re so quickly made that most of their contents is going to be rehashes of previous existing content, so there’s a reduced value holding on to them as reference when the original sources exist.
    • Since they were generated so quickly, a more up-to-date version can be generated in the future if they’re ever needed again.
    • Since the projects aren’t going to be used by others, they don’t actually use the features of a code forge, so it’s not a great idea to allocate so many resources that aren’t going to be utilised to host them on a community code forge. A better place for them would be cloud storage (dropbox, google drive, etc…). Most cloud storage services have a free tier. Anyone with a crazy amount of projects and assets that would exceed free tiers and who just wants to hold onto the projects for the future can use something like S3’s glacial deep archive which is about $1.20USD a year to hold onto 100GB of zipped up projects.

    Category 3:

    • These projects may actually get used by people
    • Since they’re developed with LLMs, there’s so much churn that there’s no actual point of reading the code since it’s quickly out of date. That means there’s no use for using the code forge’s source file features
    • Issues that reference code will go out of date as soon as the code goes out of date which is far more likely than with category 1 users.
    • These projects tend to have so much code churn that their builds are more inefficient than hand coded projects. This means that they’ll tend to want more powerful hardware to run their CI/CD pipelines than a community code forge can provide. So from their perspective, they’re better off running their own code forge anyway.

    Keeping category 1 users on community code forges, saving the code forge’s resources from being used by community 2 users, and letting community 3 users tailor their own code forges for their own needs seems like a win for everyone actually using the community code forge, and not those treating it as a file dump.