I get why people are creeped out by them, but we get filmed or photographed hundreds of times a day in a big city when we are in public spaces. Gatekeeping a potentially useful technology for being filmed in public -- well, everyone is _already_ filmed in public. ATM cameras, stoplight cameras, drone cameras, smartphone cameras, security cameras, doorbell cameras. You are on camera every time you step out of your house. You are on camera every time you open your work computer. Singling out cameras in eyeglasses as "creepy" is kind of worrying about a drop in the ocean. Cameras on self-driving cars. Nanny cams. Closed-circuit cameras. The things are everywhere, and they are always invasions of privacy. Why is the line the "creeper" glasses?

I'd be ok with it if we were for banning all non-consensual recordings in all spaces. But we're very much not.

And if we're not, then having a personal heads-up display that is contextual to your current surroundings or has augmented reality capability is too useful to not use (eventually). I'm bad with names, and good with faces. That use-case alone would be worth it for me, if it were available.

People will migrate, some will stay, and it will just be yet another noise machine they have to check in the list of snapchat, instagram, tiktok, reddit, twitter, twitch, discord, group texts, marco polo, tinder, hinge, roblox, minecraft servers, email, whatsapp and telegram, and slack/teams for work.

Absolutely exhausting to be honest.

I'm continually surprised that Microsoft hasn't completely cornered the market on LLM code generation, given their head start with copilot and ready access to source code on a scale that nobody else really has.

If it interrupts the user chain of thought with random questions about what it is hearing in the background, etc. If given tools for web search or generating an image, it might do unprompted things. Of course, this is a trick, but you could argue that any sensory input living sentient beings are also the same sort of trick, I think.

I think the conversation will derail pretty quickly, but it would be interesting to see how uncontrolled input had an impact on the chat.

For more subtle and slimier way of doing things, boost the relevance of brands and keywords, and when they are semantically similar to the most likely token, insert them into the response. Companies pay per impression.

When a guardrail blocks a response, play some political ad for a law and order candidate before delivering the rest of the message. I'm completely shocked nobody has offered free gpt use via an api supported by ad revenue yet.

There aren't many features that you'll never touch again. There are some, but they usually don't really reach that stage before they are retired. Things like curl, emacs, and ethernet adapters still exist and are still under active development after existing for decades. Sure, maybe the one driver for an ethernet adapter that is no longer manufactured isn't very active, but adding support for os upgrades still requires maintenance. New protocols, encryption libraries and security patches have to be added to curl. emacs has to be specially maintained for the latest OSX and windows versions. Maintenance occurs in most living features.

Tools exist to produce extra productivity. Compilers are a tool so that we don't have to write assembly. High-level interpreted languages are a tool so we don't have to write ports for every system. Tools themselves are abstractions.

Software is abstractions all the way down. Everything is a stack on everything else. Including, even, the hardware. Many are old, tried and true abstractions, but there are dozens of layers between the text editor we enter our code into and the hardware that executes it. Most of the time we accept this, unless one of the layers break. Most of the time they don't, but that is the result of decades of management and maintenance, and efforts sometimes measured in huge numbers of working hours by dozens of people.

A person can write a rudimentary web browser. A person cannot write chrome with all its features today. The effort to do so would be too great to finish. In addition, if finished, it would provide little value to the market, because the original chrome would still exist and have gained new features and maintenance patches that improve its behavior from the divergent clone the hypothetical engineer created.

LLMs output react because react dominates their training data. You have to reject their plan and force them to choose your preferred architecture when they attempt to generate what you ask, but in a different way.

We can have better tooling for sharing apps than the web. First, it needs to be built. This takes effort, iteration, and time.

Second, it needs to be marketed and gain adoption. At one time, Netflix and the tag it implented dominated the web. Now it is a historical footnote.Massive migrations and adoptions happen.

Build the world you want to work in. And use the tools you think make you more productive. Measure those against new tools that come along, and adopt the ones that are better. That's all you can do.

Trivial software is software for which

- the value of which the software solution is widely accepted and widely known in practice and

- formal verification exists and is possible to automate or

- only has a single satisfying possible implementation.

Most software is non-trivial.

There will always be:

- bugs in implementation

- missed requirements

- leaky abstractions

- incorrect features with no user or business value

- problems with integration

- problems with performance

- security problems

- complexity problems

- maintenance problems

in any non-trivial software no matter how "good" the engineer producing the code is or how "good" the code is.

These problems are surfaced and reduced to lie within acceptable operational tolerances via iterative development. It doesn't matter how formal our specifications are or how rigorous our verification procedures are if they are validated against an incorrect model of the problem we are attempting to solve with the software we write.

These problems can only be discovered through iterative acceptance testing, experimentation, and active use, maintenance, and constructive feedback on the quality of the software we write.

This means that the overall quality of any non-trivial software is dominated by the total number of quality feedback loops executed during its lifetime. The number of feedback loops during the software's lifetime are bound by the time it takes to complete a single synchchronous feedback loop. Multiple feedback loops may be executed in parallel, but Amdahl's law holds for overall delivery.

Therefore, time to delivery is the dominant factor to consider in order to produce valuable software products.

Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.

Just debate the ideas with the merits in the source code, ignore the haters, and be kind and helpful. It's not difficult to do.

1. https://en.wikipedia.org/wiki/Gravity_tractor 2. http://ui.adsabs.harvard.edu/abs/2021plde.confE.119A/abstrac...

As long as you are training it to make a tool call, you can add and remove anything you want behind the inference endpoint accessible to the public, and then you can plug the answer back into the chat ai, pass it through a moderation filter, and you might get good output from it with very little latency added.

> adversarial audience... Yes. Even if the audience you target is small and on your side today, a successful piece of writing will gain an adversarial audience, eventually.

> If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him. - Cardinal Richelieu (apocryphal paraphrase from hearsay apparently but still a great quote).

If you want something declarative, there's also bleep[1] in the scala ecosystem. And for single module builds there's scala-cli[2]. It's also possible to use gradle and maven for scala projects, but for an java-only shop I wouldn't be using mill or bleep because there's no need to introduce a new language just to manage the build. For scala/java/kotlin hybrid projects though, gradle or mill or sbt would be my recommended tool because of how tightly they are coupled with the cross-platform build matrix nature of scala library and build system plugin ecosystems. For larger builds, it's mill or bazel because there s a performance cliff in sbt and gradle, and bleep is too new to have all the standard plugins ported. We use mill at writer.

1. https://bleep.build/docs/

2. https://scala-cli.virtuslab.org/