Programming thread

[StealingElectricity]

AI will replace our jobs" is the most gay retarded midwit take ever and I can't stand it.

Awful take. Remember what happened to most common workers during the Industrial Revolution?

they cannot adequately comb through an entire multi-million line code base

Yet.

Those same people are niggerlicious enough that they refuse to pick up a book or do any learning outside of what their bootcamp taught them

This is here is prime example of the first people (soydevs) who have a reason to fear losing their jobs.

Granted, it won't replace the entire profession, but it will surely end the careers of the bottom ~30% (give or take) programmers.

 

[Kosher Dill]

FWIW, what I've heard from managerial types that I trust, is the actual competent Indian devs cost nearly as much as hiring local software engineering talent.

You ever heard the joke? "Why doesn't Mexico have an Olympic team?"
"Because all of them who can run, jump, or swim are already here."

It's the same with Indians. The ones who can actually program can and do get real jobs in the West for real wages (or at least H-1B wages). You won't catch them for long on slave wages unless they're very early in their careers and just getting their foot on the bottom rung of the ladder, or they have some reason they have to stay in India.
I know an Indian who in no way deserves the title of "pajeet". He started out in an outsourcing slave farm in India and quickly worked his way up to offshore contractor for a Western firm, then an onshore contractor, and so on up to "US citizen and full-time employee making local wages". Why? Because talent - or even just solid competency and work ethic - stands out in that crowd.

 

[Absolutego]

I wish Ansibile wasn't written with stupid people in mind and with next to zero features, because it is a fresh hell having to deal with Ruby's nonsense to operate Chef.
Why the hell are there six ways to do every simple task, and why do they all operate like half a dozen different languages instead of having some consistency?

People bitch about the Python community's obsession with keeping things "Pythonic" but at least I can read through a Python codebase and not have to constantly look up 8 gajillion built-in methods that all require different syntax to work and have different kinds of errors they throw because of it.

It literally uses the same syntax to denote a local var for a loop or method that it does for an OR operator, how did this make it through committee?

 

[DavidS877]

I wish Ansibile wasn't written with stupid people in mind and with next to zero features,

Some of my best code has been written in Ansible. It's pretty amazing just how far you can abuse Jinja to do stuff they didn't include. Of course, now I'd probably have done it in a Python module/filter instead.

 

[Marvin]

Credit where credit's due, inventing an electronic pajeet is an impressive accomplishment, considering it took evolution hundreds of years to achieve the same result.

Pajeet-inator

Awful take. Remember what happened to most common workers during the Industrial Revolution?

Luddites are still referenced today because we use the term as an epithet for someone unjustifiably panicking about technologically driven unemployment. That reference exists specifically because of how wrong the luddites fears turned out to be.

This is here is prime example of the first people (soydevs) who have a reason to fear losing their jobs.

Granted, it won't replace the entire profession, but it will surely end the careers of the bottom ~30% (give or take) programmers.

The majority of a programmer's job is human. It's interpreting the client's problems and mapping them onto the computer's capabilities.

Framing out the code structure might get automated away, but that's already been automated away anyway. See all the goofy web app generator scripts out there.

You're not paying for someone to type, you're paying for someone to carefully examine the details and make sure the important details aren't fucking up. LLMs can't replicate that because that's business logic, and business logic that's slightly unique every time. (If it wasn't, there'd already be an open source component to handle it.)

Like this is very reminiscent of how every few years, someone invents some drag-and-drop GUI programming tool. In like the 90's, they used to argue that office secretaries would be using shit like that to code and so many programmers would be out of jobs.

 

[StealingElectricity]

Luddites are still referenced today because we use the term as an epithet for someone unjustifiably panicking about technologically driven unemployment. That reference exists specifically because of how wrong the luddites fears turned out to be.

Still, we know that later down the line much of the same people did have to change their career.

You're not paying for someone to type, you're paying for someone to carefully examine the details and make sure the important details aren't fucking up. LLMs can't replicate that because that's business logic, and business logic that's slightly unique every time. (If it wasn't, there'd already be an open source component to handle it.)

I don't see a problem with AI achieving that in the near future. Because a task has a slight unfamiliarity, doesn't mean it will somehow prevent a well made LLM to do it.

 

[Safir]

I don't see a problem with AI achieving that in the near future. Because a task has a slight unfamiliarity, doesn't mean it will somehow prevent a well made LLM to do it.

It's not happening. A human comes up with a task. An AI user needs to instruct the AI to do it and then validate the result. Some tasks can be validated manually. Some tasks MUST be validated manually. And some tasks can be validated programmatically but still need a second source of truth.

Currently, I need to match some rectangles. I'm writing a program to do it, of course. Even if I explain the task to the AI and it writes a rectangle-matching script, who's going to validate it did everything correctly? Oh you'll just run a second LLM. Clever. But no, you don't actually have a second independent LLM. Data soyentists set aside a portion of the dataset for validation. But LLMs can't do this. You can't grasp the the amount of pajeettery that went into the LLM, and most of it is proprietary and stolen anyway. They all draw from the same enmeshed dataset that's getting continually "enriched" with moar LLM pajeetery.

 

[macrodegenerate]

AI and LLMs are good for recreating things. If you need to recreate something, you aren't programming at a professional level anyway.

 

[sneed weed 69]

Awful take. Remember what happened to most common workers during the Industrial Revolution?

Rejecting industrialization because you are obsessed with quality is a little different when you consider the trade-off in quality was, you know, industrialization? Mass production of goods on a scale that could lift the entire world out of poverty? You've gotta be chugging Sam Altmans cum if you think the industrialization of the modern world is on par with machine learning being able to adequately understand a complicated code base without shitting out clueless jeet code.

Also fuck me I just saw the Dave Plummer SoftwareOnline drama. Maybe total boomer death was right...

 

[StealingElectricity]

A human comes up with a task. An AI user needs to instruct the AI to do it and then validate the result. Some tasks can be validated manually. Some tasks MUST be validated manually. And some tasks can be validated programmatically but still need a second source of truth.

I see no problem here.

who's going to validate it did everything correctly?

Uhm, you? There should be always some testing put in place (just like there is now) to ensure everything in a codebase works before shipping a product. Still, if you are talking about testing the small chunks of code bit by bit I don't see why a second LLM won't work.

But no, you don't actually have a second independent LLM. Data soyentists set aside a portion of the dataset for validation. But LLMs can't do this.

I am yet to understand - why?

You can't grasp the the amount of pajeettery that went into the LLM, and most of it is proprietary and stolen anyway.

Fair, though at some point it would make sense that an AI would be able to generate an adequate output despite the jank.

you think the industrialization of the modern world is on par with machine learning being able to adequately understand a complicated code base without shitting out clueless jeet code.

The point I was trying to make is that there were large groups of people who feared losing their jobs, some of whom were ultimately forced to either switch jobs or settle for a much lower salary(like handloom weavers).

 

[Anti Snigger]

Does anyone have experience with Zig?
I know any language that attempts to enter the niche that C/C++ occupy are a bit of a meme by default, but it looks pretty fun to me thus far

 

[306h4Ge5eJUJ]

Does anyone have experience with Zig?
I know any language that attempts to enter the niche that C/C++ occupy are a bit of a meme by default, but it looks pretty fun to me thus far

Zig has completely insane function call semantics. Whether a non-primitive type is passed by value or by reference is implementation-defined (size-dependent in the reference implementation). The idea behind this is that the developers of Zig somehow convinced themselves that unnecessary struct copies during function calls are a big issue and that an optimizing compiler with copy elision just doesn't suffice. Despite repeatedly causing awful bugs in Zig programs and even the stdlib, the devs think that this retardation is a feature. See this and the links in the comments.

 

[SpergRush]

Does anyone have experience with Zig?
I know any language that attempts to enter the niche that C/C++ occupy are a bit of a meme by default, but it looks pretty fun to me thus far

I did the learn zig repo, the one with a hundred or so little problems to solve. I thought it was pretty cool. Comptime is way cooler than Macros and having never programmed in languages like LISP, it never occurred to me this was possible.

Its definitely a candidate language choice for a future project, especially where I might consider C or C++. Its pretty interoperable with C and C++. I think it has a promising future.

Zig has completely insane function call semantics. Whether a non-primitive type is passed by value or by reference is implementation-defined (size-dependent in the reference implementation). The idea behind this is that the developers of Zig somehow convinced themselves that unnecessary struct copies during function calls are a big issue and that an optimizing compiler with copy elision just doesn't suffice. Despite repeatedly causing awful bugs in Zig programs and even the stdlib, the devs think that this retardation is a feature. See this and the links in the comments.

I didnt notice this problem and I dont see why this would be a big issue. Maybe i just never pass big structs by value. If i wanted to copy an object I'd be more likely to copy it myself and pass the reference to the copy to something. Idk, maybe this would foot gun me if I wrote a few thousand lines more of zig.

 

[Napoleon III]

anyone know anything about wasm embedded in the browser somewhat similar to something like Tampermonkey. I'm fucking tired of shit that takes 10 seconds to load because of Javascript.

I've heard of emscripten but I haven't had time to look and see if there are better options.

I'm also in a situation/environment where memory is actually important since I actually do not have enough memory despite having 16gb. JAVASCRIPT I LOVE IT.

 

[Marvin]

I've been working on my non-work project this weekend, which has been a nice reprieve from pajeetery.

I'm working on a little daemon that manages resources. I'm being deliberately vague in case this project goes anywhere (), so, let's say it manages "media streams", with "sources" and "sinks". (Made up terms to be deliberately vague.)

So basically I want something that I can feed it a config file (yaml) of "sources" and "sinks" and "tasks" that direct the daemon to read from the sources and write to the sinks in a loop.

One little nuance is that some of the sources and sinks might have multiple channels in them that can be read/written in parallel.

So the config file can specify one task that reads from one source, writes to one sink, but if that source and sink each have two channels apiece, then it's more efficient to have two processes (or threads or whatever) instead of one. If I write the config file to specify two sources (each with a flag set to channel 0 and 1) and two sinks (channel 0 and 1) and two tasks that separately handle those pairs, then the daemon will fork and handle each task separately.

It would be convenient to have a flag on the daemon to do this expansion automatically when possible. Commit a simple, high level config file, but have it expand it to parallelize it as much as is possible.

So from

source:
  name: front-door-cam
  url: http://192.168.1.145/stream

sink:
  name: aggregation-target
  url: http://foobar/stream
 
task:
  name: upload
  source: front-door-cam
  sink: aggregation-target

To:

source:
  name: front-door-cam-0
  url: http://192.168.1.145/stream
  channel: 0

source:
  name: front-door-cam-0
  url: http://192.168.1.145/stream
  channel: 1

sink:
  name: aggregation-target-0
  url: http://foobar/stream
  channel: 0

sink:
  name: aggregation-target-1
  url: http://foobar/stream
  channel: 1

task:
  name: upload-0
  source: front-door-cam-0
  sink: aggregation-target-0

task:
  name: upload-1
  source: front-door-cam-1
  sink: aggregation-target-1

So this is a perfect little niche for TDD, test driven development. So I wrote up a bunch of functions for the config expansion code (several simple expansion stages), thought up all the contexts in which it should fail, and wrote up a bunch of tests. Now I'm just going through and implementing the stages and the tests start passing, one by one.



So I'm having a cozy saturday evening working on this. Some friends of mine are watching UFC online, so I'm half watching that while working on getting the tests to pass.

The reason I'm rambling about this, is because this had me thinking about how good concepts like TDD get (mis)interpreted by non-technical (or ex-technical) team managers.

TDD? Good idea for some situations. But then you get team managers who read some blog post about how TDD is the future of all software development and they breathlessly announce how we're moving to a TDD approach and every PR must come with a full battery of tests and they get super mad if the automated test percentage drops. So you end up writing a lot of pointless tests that essentially test for tautologies, just to keep them off your ass.

And substitute TDD for any other new trendy thing.

I've had good jobs in the past and bad jobs. Despite my bitching earlier in the week, my current job isn't really that terrible. But just thinking about all this, I think I'm going to resolve two things for my career going forward:

1. Never work directly under a fully non-technical manager. They can be nice people and maybe they're really good at managing people in other contexts, but if they have zero understanding of the technical implications of what they're telling me to do, I won't be very productive. Which means my job will be tedious and suck, and the company probably isn't well run. I worked for a marketing department like this once, with actual pajeets as coworkers.
   
   
2. No matter where I advance to, I want to still spend at least some portion of my time programming. I've had opportunities to advance in my career and run small teams, and that's nice (especially with the extra money).
   
   But my current boss hasn't programmed regularly in years. He's sharp and he can understand technical language, but the best he can do is just fuck off when me and the other guy give a basic technical explanation about an issue. Whether we're arguing with each other or together against management, we just need to offer just enough technical language to pass the sniff test and then he fucks off. It's not because he's smart or because he's not a programmer, it's because he's not a current programmer, and he's not currently balls-deep in the project enough to argue with us effectively.
   
   He's not much better than a fully non-technical manager.

It's funny, the CEO at my current job wrote our original product (it's a small company). He still comes around to try to contribute to stuff, but I think he's been left behind. I don't know if he likes his new role or not, maybe he's happy. But it's funny watching a programmer play as a big C-suite type. He's like a chimp in a suit.

I don't want to end up like that.

 

[Napoleon III]

Never work directly under a fully non-technical manager.

I think it is possible for someone to start as a non-technical manager. But they need to become technical in the process. They need to get a good sense of what is difficult and what is easy.

It's not because he's smart or because he's not a programmer, it's because he's not a current programmer, and he's not currently balls-deep in the project enough to argue with us effectively.

I think it would be possible for a manager to have a decent sense of a project if they really actually tried and they should try to understand what is going on. Having them write code is a bad idea but if they are truly intelligent and leaders should be, they can have a basic understanding of every piece of what ever project.

But this is not trendy, because it is a pain in the fucking ass and it is hard and requires a lot of effort and work. For these reasons it is not trendy either. Things which are hard work for the people implementing them almost never become trendy.

 

[Agent Sandoval]

Now I'm just going through and implementing the stages and the tests start passing, one by one.

God that looks comfy. I think of TDD as a specialized case of Contract Driven Design. To your point, there are times when you can define an interface and it's contract and that's all you need to do. Testing further than "the pre/post conditions and invariant assertions didn't fail" is an honest to goodness waste of time if your construct is tight enough.

 

[Megaton Punch]

I have a confession to make: I have no idea what a unit test is. I've never written a test. I don't even know what "write a test" actually means, nor do I have any idea how a program can test itself. When I make a program I just QA it manually myself. I pretend to be the most retarded end user on the planet and abuse my program as much as possible.

It's never been a problem for me because all of my projects have been small enough that I can detect and fix every(ish) bug by myself, but I'm guessing eventually this technique is going to cause me some problems. Then again, it's what people did for decades and it worked out just fine back then.

Are unit tests something you can just "do" or are they all different depending on what language you use?

 

[Anti Snigger]

I have a confession to make: I have no idea what a unit test is. I've never written a test. I don't even know what "write a test" actually means, nor do I have any idea how a program can test itself. When I make a program I just QA it manually myself. I pretend to be the most retarded end user on the planet and abuse my program as much as possible.

It's never been a problem for me because all of my projects have been small enough that I can detect and fix every(ish) bug by myself, but I'm guessing eventually this technique is going to cause me some problems. Then again, it's what people did for decades and it worked out just fine back then.

Are unit tests something you can just "do" or are they all different depending on what language you use?

A unit test is quite literally a test on a 'unit'. A unit could be a function, or a set of functions. Essentially, if your operations are deterministic, it lets you ensure that the unit gives the proper output. It's helpful to have things broken down, as you can then see which parts of your code are giving faulty output, and if you do any refactoring, it's a quick way to sanity check yourself

 

[Marvin]

I have a confession to make: I have no idea what a unit test is. I've never written a test. I don't even know what "write a test" actually means, nor do I have any idea how a program can test itself. When I make a program I just QA it manually myself. I pretend to be the most retarded end user on the planet and abuse my program as much as possible.

It's never been a problem for me because all of my projects have been small enough that I can detect and fix every(ish) bug by myself, but I'm guessing eventually this technique is going to cause me some problems. Then again, it's what people did for decades and it worked out just fine back then.

Are unit tests something you can just "do" or are they all different depending on what language you use?

They will be different depending on the language, but the concept is extremely simple, so it's portable to basically any language you want. There are test frameworks available for basically any language in common use, but you could really just write a separate program and frame out your tests however you want.

Manual testing is important, but machine assisted testing is older than you think. It dates to at least the 70's, if not earlier.

Here's a little demonstration of a unit test:

function is_person_name(str) {
  var parts = str.split(' ');
  if (parts.length != 2 && parts.length != 3) {
    return false;
  }

  for (var part of parts) {
    const regex = new RegExp("^[a-zA-Z-]+$");
    if (!regex.test(part)) {
      return false;
    }

    const capitalized = new RegExp("^[A-Z]");
    if (!capitalized.test(part)) {
      return false;
    }
  }

  return true;
}

// tests
function run_tests() {
  var tests = [
    {name: "first and last name capitalized", args: "Christian Chandler", expected: true},
    {name: "middle names OK", args: "Christian Weston Chandler", expected: true},
    {name: "no capitalization", args: "fff", expected: false},
    {name: "mononyms not allowed", args: "Sonichu", expected: false},
    {name: "hyphens ok", args: "Chips-Ahoy Chandler", expected: true},
    {name: "no other symbols allowed", args: "Zip^ Chandler", expected: false}
  ];

  for (var test of tests) {
    console.log('Testing: ' + test.name);
    var res = is_person_name(test.args);
    if (res != test.expected) {
      console.log('  test failed! Got ' + JSON.stringify(res) + ', but was expecting ' + JSON.stringify(test.expected));
    }
  }
}

// entrypoint
run_tests();

It seems stupid, but these automated tests (especially if you have them set to run automatically before you commit or in some sort of continuous integration setup) can be super useful.

The is_person_name function is from your library or app, and then you would keep the test code separate and run that regularly, usually right before you commit new changes.

The value of tests is that they fix your expectations of what your existing code does.

You can continue to add new features and expand the behavior of is_person_name without worrying about sliding backwards for what existing code expects it to do.

When I first started taking tests seriously, I had the obvious question of "well, what if there's a bug in my tests?". It felt like a dumb question, but I think it's really dumb that no one explains it for people new to the concept.

The answer is: well, then that's just a bug in the test. There's no real plan or clever solution to that problem. You just be extra careful when writing tests, and even then sometimes you might still have bugs in your tests. But that doesn't mean tests don't have value. It just means they're not a magic bullet for anything. (Nothing ever is.)

Still, there will come a day when you'll have completely broke some expectation in your code somewhere and your tests will catch them. You'll say "how did I ever fucking miss that?" and you'll be glad you wrote those tests.