• 0 Posts
  • 41 Comments
Joined 3 years ago
cake
Cake day: June 12th, 2023

help-circle


  • If you take data, and effectively do extremely lossy compression on it, there is still a way for that data to theoretically be recovered.

    This is extremely wrong and your entire argument rests on this single sentence’s accuracy so I’m going to focus on it.

    It’s very, very easy to do a lossy compression on some data and wind up with something unrecognizable. Actual lossy compression algorithms are a tight balancing act of trying to get rid of just the right amount of just the right pieces of data so that the result is still satisfactory.

    LLMs are designed with no such restriction. And any single entry in a large data set is both theoretically and mathematically unrecoverable. The only way that these large models reproduce anything is due to heavy replication in the data set such that, essentially, enough of the “compressed” data makes it through. There’s a reason why whenever you read about this the examples are very culturally significant.



  • VoterFrog@lemmy.worldtoTechnology@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    edit-2
    7 months ago

    What? I’ve already written the design documentation and done all the creative and architectural parts that I consider most rewarding. All that’s left for coding is answering questions like “what exactly does the API I need to use look like?” and writing a bunch of error handling if statements. That’s toil.


  • VoterFrog@lemmy.worldtoTechnology@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    4
    ·
    7 months ago

    Definitely depends on the person. There are definitely people who are getting 90% of their coding done with AI. I’m one of them. I have over a decade of experience and I consider coding to be the easiest but most laborious part of my job so it’s a welcome change.

    One thing that’s really changed the game recently is RAG and tools with very good access to our company’s data. Good context makes a huge difference in the quality of the output. For my latest project, I’ve been using 3 internal tools. An LLM browser plugin which has access to our internal data and let’s you pin pages (and docs) you’re reading for extra focus. A coding assistant, which also has access to internal data and repos but is trained for coding. Unfortunately, it’s not integrated into our IDE. The IDE agent has RAG where you can pin specific files but without broader access to our internal data, its output is a lot poorer.

    So my workflow is something like this: My company is already pretty diligent about documenting things so the first step is to write design documentation. The LLM plugin helps with research of some high level questions and helps delve into some of the details. Once that’s all reviewed and approved by everyone involved, we move into task breakdown and implementation.

    First, I ask the LLM plugin to write a guide for how to implement a task, given the design documentation. I’m not interested in code, just a translation of design ideas and requirements into actionable steps (even if you don’t have the same setup as me, give this a try. Asking an LLM to reason its way through a guide helps it handle a lot more complicated tasks). Then, I pass that to the coding assistant for code creation, including any relevant files as context. That code gets copied to the IDE. The whole process takes a couple minutes at most and that gets you like 90% there.

    Next is to get things compiling. This is either manual or in iteration with the coding assistant. Then before I worry about correctness, I focus on the tests. Get a good test suite up and it’ll catch any problems and let you reflector without causing regressions. Again, this may be partially manual and partially iteration with LLMs. Once the tests look good, then it’s time to get them passing. And this is the point where I start really reading through the code and getting things from 90% to 100%.

    All in all, I’m still applying a lot of professional judgement throughout the whole process. But I get to focus on the parts where that judgement is actually needed and not the more mundane and toilsome parts of coding.



  • Tariffs are a net negative. Always. The things produced will not be competitive on the global market, if they were, we’d already be making them. The higher prices always destroy more jobs than they create. Retaliatory tariffs destroy even more jobs. The higher prices drive down demand and make the working class consumer poorer. Always.

    There’s no economic upside to tariffs, over any time horizon. They create a small number of jobs in a specific sector at a very expensive cost. Some politicians might decide that the enormous economic cost is worth it for other reasons, but a net positive they are not.


  • I work at a pretty progressive company (comparatively but definitely not perfect) and DEI there has nothing to do with preferential treatment, nor does it need to be.

    The fact is that if you want to hire the top X people in the labor market, but your hiring and business practices exclude, say, half of that market, you absolutely will not get the actual top X. You will have to reach deeper into your half and be forced to pick people that are less qualified and/or capable.

    So DEI, at least where I’m at, is about widening that pool so that you can actually get top talent. That means reevaluating your business practices to figure out why you’re excluding top talent. Maybe your recruiters always go to specific colleges for recruitment and certain websites. Maybe just the way they’re talking to candidates is more attractive to a certain type of person. Maybe you’ve got hiring requirements and an interview process that is not actually predictive of success. Maybe candidates are looking for some benefit that you’re not offering. Everything needs to be looked at.

    For example, “Women just want more flexible working arrangements so that’s why we can’t get them” is something I hear often. Well, have you actually evaluated why your company is so inflexible? Is it actually necessary? Or are your executives a bunch of people who learned how to manage in the 20th century and haven’t changed since then? Maybe there are things you can do to enter the 21st century and make room for more women, not just because they’re women, but because you gain access to people who are actually better at their job than the ones you’ve had. Not every company can be supremely flexible, of course, but the number of times that inflexibility is actually necessary of much smaller than its prevalence.

    The demographic breakdown of your workforce is a quick and easy weathervane to help figure out how these efforts but of course they’re not everything. Diversity comes in maybe forms, not just skin color and genitals. But in my company they’re used in a backwards looking manner, to see how new policies are working, not for quota filling and preferential treatment.



  • Your inability to come up with a way to produce evidence doesn’t make the strong atheist’s stance unfalsifiable. Unfalsifiable isn’t “We can’t produce any evidence that would falsify the claim right now.” That would take us to an absurd definition of the word where any scientific theory that requires more advanced technology than we currently have is “unfalsifiable.” That’s not what the word means.

    The difficulty in proving that God exists isn’t what makes theism unfalsifiable. You shouldn’t make any assumptions about what can or cannot be proven true at some point in the future. What makes it unfalsifiable is that there’s no rational way to prove that God doesn’t exist, not because of an inability to collect evidence, but because the logical framework constructed by religious claims forbids it. Strong atheism has forbade no such thing. There’s no equivalence here.





  • VoterFrog@lemmy.worldtoNews@lemmy.world*Permanently Deleted*
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    1 year ago

    I think the real chaos is how it would affect dates. “The store is closed on the 25th” now would necessitate specifying the exact hours and dates because it would likely bleed from the 24th or into the 26th. Anyone filling out a form would have to be careful to check the time to make sure they get the date right. Even just the simple statement “Let’s get together Tuesday” becomes ambiguous.

    It would be pretty dumb to add all that confusion to the vastly more common use case, for what?