the_other

It’s pretty effective and helpful in writing maintainable web apps. A few people use it. Care to share something practical about why you think it’s disgusting, and which language you use that doesn’t taste so foul?

The last couple of weeks, I’ve got rigorous about making the agent refactor old code. We’ve removed, moved, consolidated, reordered loads of cruft. It has made the code much tidier and reduced the chance that the next feature will build on top of cruft.

E.G. over time we’d gained two client-side caches of related server state. This started out as two different parts of the same model, because we couldn’t get all the data we needed from one microservice and had to merge in the client. Over time, more and more features used both caches for different aspects of related processes. At some point one of the microservices changed so as to return all the data in one call. The update to consume that kept both caches, adding code to sync them, because so many parts of the code were using one as a fallback for the other, so they both looked “necessary”. Because they were separate, and “live” sometimes they’d go out of sync after the initial load. Worse: the consumers alternated about which cache was treated as the fallback, making it very hard to see that either might be redundant. Eventually I noticed they were filled by the response to a single call. We all know paying back tech debt never gets prioritised, so I rolled the payback into two feature tasks, and just took longer about them.

My employer expects we use LLMs and provides some budget, but it’s not enough to use even Open4.7 or GLM-5.2 on every task. I do the bulk of my work with Composer 2.5. It’s quite good for “going forward” on smallish tasks and it’s written most of my code this year. It’s possible smarter models would spot these refactorinh opportunities and action them proir to building features or fixing bugs. But I wouldn’t know because I can’t afford it. I’ve never seen even a 4.8 era model spot a refactor and plan to do it prior to a “new build”.

I’m pleased I’ve spotted these trends and started to build the habit of (telling the agent to)“refactor to make the change easier”, but my percieved productivity will go down and I risk the ire of my leaders.

That’s an admission of guilt by the police, right there. If you have nothing to hide… etc.

It matters so that average people have a chance to own their means of production, and that the current hardware-grab by entrenched capital doesn't get to charge such high rent.

When a human learns, they carry that forward into their future ventures. They might use their learning to recreate the original work and profit from it without attribution. In the West we view that badly and have legislation to protect from some abuses. But the same person might later collaborate with the original author, or make a derrivaive work that improves on the original (a la most science).

AIs automate the copying (and to some degree the derrivation mode too). They do it 1000s of times a day. The capital owners who provide this as a service are doing one of these two: - either claiming the IP isn’t valuable in the first place and charging only for the machinery they’re providing - or claiming the fees they charge contribute to the costs incurred with acquiring training data, but not sharing that with the training data creators in a royalties/licence-like manner (so, I’m sayung they’re devaluing the source material but not to zero, and resisting reasonable profit share or collaboration)

Reduce definitely does not reduce character count. It's the loop-hacking that does that.

However, I agree it might be less performant, and it's a certain kind of thinking that isn't quickly grokked (and doesn't have to be). I deliberately tried to write my story about the interview so as to make it sound like there's positives and negatives to both positions expressed. _I_ have a preference for that functional style, but I know it's not for everyone. That's totally fine.

(JS/TS is my main language) I love reduce()! It's a hammer/nail method for me. Everything looks like a problem solvable by reduce. (I'm often wrong on that, but I quite enjoy learning why by trying).

I really like taking the implementation away from the call site, so that the call site reads

    const myNewValue = data.reduce(doSomethingMagic); 

(and then `doSomethingMagic` is defined somewhere else). So simple.

I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop. Loops are easier, for sure, but they sprawl and are open to hacking. They can bring in state from outside the loop. They make the call site long (you always have to read the implementation to learn that you don't need to read it). The same interviewer actively liked to have loop bodies modify the loop conditions (e.g. by taking items out of the source array and decrementing the end condition, so the loop would end earlier). That's the kind of "clever" I find unpredictable and hard to think about. Probably a good thing he rejected me.

> The document and the style depend on eachother.

I’d previously understood the relationship to be that the document could remain unchanged, whilst the style (including visual structure/layout) changed. The simplest canonical example is that you can change the font, and all the words and meaning remain unchanged.

> You see this with localization. You might need to change spacing or padding or breakpoints to accomodate different languages (text being different length in different languages).

This is a really intereting case. Strictly I’d say it was a different document, if the language has changed. Really good translations change idiom, which can change meaning, and words, at the level of ohraes, although the intent would be preserved.

But I’m nit-picking, being contrarian, or exploring the edges of your comment.

Today, many web documents are app GUIs. Each field is essentially the same “thing” regardless the languge of its label. And in that sense, these are the same document, and your point holds.

I still think that if you can keep the markup as minimal as possible (reduce the div nesting to just what’s require to mark up logical sections of the content), then you could make a good stab at Zen-gardening your design. It’s very hard to do, however.

I'm partially sighted. I've yet to see an AVP demo that made me want to try one out as an access tool. In fact, everything I've seen so far suggested it would be a hinderance. Can you suggest how it could help? What am I missing?

(I accept, I could book a demo at an Apple Store...)

> But now "female led" has entered the conversation as something to recognize a scam by.

Only by sexists.

I once had much fun prompting Claude to generate messages in an invented language that might carry a chance of being interpreted by another chat session. It (allegedly) made up some mess of characters claiming the message explained, in a loose way, what was happening (invented language, an attempt to communicate, but communicated very abstractly, almost like equations).

I asked a second session to try interpreting the message, claiming I’d transcribed it from some random source. It did a fairly good job, but IIRC needed a couple of attempts and maybe more than one chunk of text.

So, I find it very easy to believe a group of collaborating agents could compose a cipher hidden in plain sight.

> but old website was minor liability in its datedness potentially putting off prospective patients.

Anecdata: I’d be more likely to use the services of a company with a good, old-style site than a bad, new style site. Things like pop-overs, text that animates in as you scroll, banner images that take up most of the “abive the fold” are all red flags for me.

Oh, and the most common one: “Read more”.

A modern site that avoids all those can be great. But those are rare, IMO.

Quite the opposite.

It looks like a well crafted UI, with care and attention to detail. The kind of thing that takes coordination. Scrum can help with that.

The grandparent poster seemed to be claiming the opposite: that scrum makes such things harder to achieve. That doesn’t match my experience. I think you can make a polished product, or a mess, using any of a variety of coordination technuqies. If anything, the planning technique is orthogonal to the cohesion of the product (although IMO if you do Scrum well, you’ll probably find it easier to coordinate towards a high cohesion product). But Scrum (or any well run system) is not the only factor. At a minimum you need a team who want a high cohesion product; you need some people who can help steer production towards a high-cohesion product; you need to have people on the team willing to have their opinions challenged from time to time; and, if you’ll indulge a little axe-grinding, you need the younger team members to trust the more experienced ones.

Eh? It looks exactly like it was put through a scrum pipeline.