daotoad

I think the home automation market is waiting on things that most people really want and a lower barrier to entry.

Alfred North Whitehead famously noted that "Civilization advances by extending the number of important operations which we can perform without thinking about them."

What has household automation really given us so far? Dimmable lights? Whatever. If I cared, I'd already have rheostats on all my light switches. Thermostat? My digital thermostat is already good enough.

The thing that would sell like crazy is a robot valet.

In other words, the ability to navigate carelessly through your home, dropping items when you are no longer interested in them and have them "magically" return to their proper homes.

Such a thing would need to be able to roam around your home and pick things up and store them, and then retrieve them when appropriate (when asked or based on schedules and other automations). Maybe even do a little light dusting.

If you can make it take out the trash, fold laundry, and empty the dishwasher, you're looking at a ridiculously popular system. Even if it costs thousands of dollars.

Thing is, the tech isn't really ready to give us a household robot that can pick your jacket up off the couch and put it away. When we can do that, it will be huge.

Once we are there, we've grown so used to the idea of an adversarial relationship with the businesses that provide our services, that we are being spied on and our data sold, would we even trust the systems that would be needed to enable such products?

1. Starting from scratch is rarely a good idea. 2. It always sounds like a better idea than it actually is. 3. Item 2 is true even if you think you've accounted for item 1.

Is there something specific that you want that cannot be implemented reasonably on existing systems?

Unless you have a specific compelling benefit that only a rewrite can grant, focused narrow rewrites are the way.

The gap between quality work and baseline LLM output is precisely the understanding.

If it can be validated by automation, the bot will do it. But no automation suite is complete or perfect.

What concerns me is that building software using the LLMs gives a distance that inhibits the formation of the sort of understanding I need to "just know" a code base intuitively. So when product asks for a feature, my ability to be sufficiently pedantic about the 6 different non-obvious things this impacts is less effective. And when I need to choose abstractions and try to form an effective ontology, my intuition is less effective. I believe I can still grind out an effective solution, but I start farther from the finish line.

Does the LLM's ability to "answer questions" about the codebase make up for my lack of intuition? Does my apparent ability to run faster make up for the fact that I am starting farther from the end of the race?

I don't know yet.

RFC 3514 perhaps?

https://www.ietf.org/rfc/rfc3514.txt

I really, really want that to be true, but my experience trying to adopt it has been really painful.

Even selecting things in the UI has sucked. I went in and increased the selection radius or whatever, that helped. But really, should I need to do this as a new user?

Getting the constraints to behave is like pulling teeth.

It also kind of sucks that you have to have really sparse sketches that only contain one closed figure. I gather you can create a "master sketch" and selectively project geometry into other sketches. But the last few times I've tried the app, I haven't gotten far enough into my sketches before rage quitting to validate the technique.

Right now I am back F360 with their hobby license wanting to escape their regular messing with the terms and conditions.

It's a kind of crappy slide deck, not a proper home page. Even worse, the link drops you into the middle of the deck. (TBF, it wouldn't be so bad if you know that it's a slide deck when you load the page.)

Try using the arrow keys to navigate. It took me multiple tries to get it figured out.

Use up/down to navigate within a chapter/topic. Use left/right to switch between topics.

I lost a nuke to a phalanx in Civ 1. Still salty about that _decades_ later.

Anecdata:

I'm a Civ3 hater, give me 2 or 4 any day. 3 is my least favorite version of the game.

But, OTOH, my wife is ride or die for Civ3.

What I really want to know is, is it mighty mighty? And does it let it all hang out?

The problem is most people won't take that attitude. For most homeowners, the home is the largest asset.

This is a Catch 22 for elected officials. We must reduce housing costs dramatically if we do so, we will devalue significant assets of a large number of active voters and political contributors.

I'd love to see some ideas on how to pull this off, because we need them.

For a motivated learner with access to good materials, schools provide two important things besides that very important piece of paper:

1. contacts - these come in the form of peers who are interested in the same things and in the form of experts in their fields of study. Talking to these people and developing relationships will help you learn faster, and teach you how to have professional collegial relationships. These people can open doors for you long after graduation.

2. facilities - ever want to play with an electron microscope or work with dangerous chemicals safely? Different schools have different facilities available for students in different fields. If you want to study nuclear physics, you might want to go to a school with a research reactor; it's not a good idea to build your own.

Naming comments are useful when someone catches something like:

1. you are violating a previously agreed upon standard for naming things

2. inconsistent naming, eg some places you use "catalog ID" and other places you use "item ID" (using separate words and spaces here because case is irrelevant).

3. the name you chose makes it easy to conflate two or more concepts in your system

4. the name you chose calls into question whether you correctly understood the problem domain you are addressing

I'm sure there are other good naming comments, but this is a reasonable representation of the kinds of things a good comment will address.

However, most naming comments are just bike shedding.

US states are, in some ways, less independent than UK countries.

Wales can no more disavow the PM than California can disavow POTUS. So this separate status is limited.

The big counter to this is the idea that US states have their own militaries. States may have militias, but they can be subsumed by the federal government pretty easily, as we saw in California in 2025. They are not truly independent armed forces.

OTOH, states are not allowed to leave the US, we had a war about this a while ago. Meanwhile Scotland had a referendum on leaving the UK a few years ago.

Love it or hate it, we are Americans first before we are New Yorkers or Mississipians and so forth. This is especially true when it comes to international relations; that's handled on a federal level and most people in the world couldn't tell a Nebraskan from an Alaskan.

Do you like your cursor at the beginning or end of words?

Most of the time it doesn't really matter. But if you know you want to append to a word you can hit that target immediately by using `e` (`ea`). Or if you want to prepend, you can use `wi`.

Note that `i` and `a` have a similar pairing to `w` and `e`.

Motions can be inclusive or exclusive. It works like the different ways of annotating ranges: [0,1] and (0,1).

Consider the command `d` (delete) combined with the motions for `"`.

First we have `da"`, it deletes the everything between the pair of `"` characters that surround my cursor. Next, `di"` deletes the contents of the `"` pair.

The movement `a"` is inclusive (think 'a quote') and `i"` is exclusive (think 'inside quote'). Combined with the command you get "delete a quote" and "delete inside quote" when the mnemonics are spelled out.

https://vimhelp.org/motion.txt.html#exclusive

This usage is a double misunderstanding, it gets both the phonetics of homing and the mechanics of sharpening a blade wrong.

It’s like calling someone a “stropping young lad”.

Off topic and doesn't impact the validity (or lack thereof) of the post. Just reactionary whining really...

For the love of all that is good, "exacerbated" and "exasperated" are different words.

We've already screwed up "home in on" by allowing the horrid "hone in" to horn in our lexicons. On a side note, watch out for those honing pigeons, they've got very sharp beaks.

In my experience, what works best is having QA and a tech writer assigned to a few teams. That way there is an ongoing, close relationship that makes interactions go smoothly.

In a larger org, it may also make sense to have a separate QA group that handles tasks across all teams and focuses on the product as a unified whole.

That's because we don't value QA in the way that matters.

If you're a talented SDET, you're probably also, at least, a good SDE.

If you'll make more money and have more opportunity as an SDE, which career path will you follow?

I was about to say "Obsidian is free as long as you don't use it for work."

But it turns out that that is no longer the case. https://obsidian.md/blog/free-for-work/

Obsidian is now actually free for everyone.

Rereading TFM can be quite illuminating.

Robert Preston, is that you?

The real trick is getting just enough meaning into the name to be helpful, while keeping it distinct. SQLAlchemy is a great example.

I called by zsh bookmark tool `tutu`, my idea was to make it sound like what it does.

- It helps you go TO places - The main command is `tu` because it is short, a homophone of "to", and wasn't already taken - Additional commands `tutu` (which does a `pushd` instead of `cd`) and `untu` (which is just a wrapper around `popd`) are short, memorable, and pronouncable.

All of those naming decisions were made with ergonomics in mind.

Was I successful? I like it. A few other people are using it and seem to like it, too.

To the extent that I was, I think it's because the name is meaningful enough while remaining distinct.

https://github.com/daotoad/tutu

whereas all humans typically use the standard hyphen-minus character (U+002D).

I made it a point to learn to type the em dash—only to have it stolen by the bots; it's forced me to become reacquainted with my long lost friend, the semicolon.

Between perlbrew and cpanm it's pretty easy to have multiple perl installs with different versions and quite simple to manage your dependencies.

Carton (manage and bundle your perl modules based on lock files) and Pinto (easily run your own private CPAN) provided the icing on the cake that made things really powerful.

I miss working in Perl, but the job market has pulled me in other directions.

mod_perl hosting was much more expensive.

If you wanted to throw up a personal project using mod_perl you pretty much had to pay for a hosted box. At least once people realized how insecure it was to run shared code on a mod_perl host.

You could find hosts but it was comparatively expensive.

Plus it was a huge pain in the neck to do things like install the modules you needed on a shared host.

This was a huge barrier to entry and it made things unreasonably difficult. Meanwhile PHP was very low friction. And at the time, so many new people were teaching themselves web development to scratch itches and solve problems that these barriers were a big deal.

Which sucks, because mod_perl was amazing, beautiful tech.

I think you're right about the significance of PHP.

PHP kicked Perl's butt in the shared web-hosting environment.

You could do amazing stuff with mod_perl, but it was not possible to run a shared host with mod_perl without exposing every customer to every other customer's code. You could still do cool stuff with vanilla CGIs. Perl was practically synonymous with CGI back in the day. Once you grew past what a simple CGI would handle, it suddenly got a lot harder and a lot more expensive.

Meanwhile, PHP had simple Perl-like syntax and ran nicely in shared hosting. Better yet, you didn't have to choose from one of the 400 different Perl templating systems. No need to choose between TemplateToolkit, HTML::Mason, or Embperl. You just used the standard, built in templating.

PHP won because it was worse, you didn't have the power or choice Perl provided, but it was more than good enough and it was cheaper to grow with.

On Perl vs Python: - Perl was weird and proud of it, it promised creative power and flexibility - Python promised regularity and clear rules

- Perl tried to make hard things easy - Python tried to make routine things routine

- Perl had weird primitives that let you build whatever magical OO nonsense you wanted. - Python supported writing glorified struct OO that was fashionable at the time

- Perl was difficult to integrate with C libraries - Pyton integrated much more easily with C libraries

That being said, I like Perl much more than Python. Using Perl still feels magical, even if some of the syntax is odd. Using Python feels like I have my shoes on the wrong feet.

You say it was a "bad language" for projects of any real size. But I've worked on large systems written in perl maintained by multiple teams. Perl wasn't the source of our difficulties.

The real issue was ugly code that was in the product when it was acquired--you can write 2000 line methods in any language if you are cursed enough. Believe me, if you do this, you will be cursed.

We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.

I'd go so far as to argue that the expressiveness and flexibility of the language was an asset that helped us in our refactoring. For example, we built instrumentation that took advantage of Perl's unusual semantics for dynamic "local" variables to create flexible instrumentation that could have log levels enabled based on the call stack--if you turned on aggressive logging in function A, it would propagate to A's calls into functions B and C, while other calls to B and C would be logged at normal levels.

Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context, but the dynamic scoping gave us the tools we needed to build something powerful with only a small amount of clear, commented code.

As I have said before[1], I think the biggest thing slowed Perl adoption was the changing background of new developers. New folks just didn't have a background in shell, C, awk, and sed. This fact took Perl syntax from being amazingly intuitive and easy to adopt and turned it into obscure nonsense. As a newb what the heck are you going to think about constructs like the file test operators[2]?

[1] https://news.ycombinator.com/item?id=44726347#44752240 [2] https://perldoc.perl.org/functions/-X

https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect