brlewis

>I actually thought that this sort of law would be disallowed by the fed, since they reserve the right to govern interstate commerce

Yes, the US Constitution gives regulation of interstate commerce to the federal government, but this has been worked around. Lots of states have "use tax" which is an obvious[1] tax on interstate commerce, but they skirt the Constitution by saying they're taxing "use" of the goods purchased within their own state, not the interstate commerce involved. It's possible the AZ law could be written in a way that claims to tax something that happens within the state, while still being for all intents and purposes a tax on interstate commerce. And probably nobody would do anything about it.

[1] The tax is computed 100% based on the money exchanged in interstate commerce, and 0% based on usage.

Mine is very much worth it. I have an old Humanscale mechanical sit/stand desk that lets me very quickly adjust the height between sitting and standing whenever I'm inclined to do so. I don't know if you can still get this kind; it probably could be dangerous if kids played with it since nothing stops it from moving fast. There's more mental friction involved in the slow-moving electric-motor adjustable desks, but if you have preset buttons you can think about something else while you're waiting for it to get to the right height.

Some people who stand at desks say it's a lot more comfortable with a soft pad to stand on. I haven't used those myself.

Ideally there are enough details in the study to where you can evaluate the truthfulness of it from its content rather than its funding. But FWIW: https://css.umich.edu/people/external-advisory-board

"Multiple competing options" ignores that there's a prevalent style already.

https://github.com/prettier/prettier/issues/840#issuecomment...

Consistency has more value than the subjective advantage of the proposal that you're comparing to the objective advantage of being phonetic. I think the prettier maintainers made the right choice.

My recollection from flying kites a long time ago is that operating a kite gets easy after a certain height. I imagine the Kite Control Unit (KCU) can easily keep it aloft once it's high enough. The tether is 352m long according to https://thekitepower.com/the-hawk/#components

Translation: You're right on the point that one can spell words more easily in other languages. But the important thing in this case is that people find what they expect. If the majority are looking for `} else {` it's better to give them what they expect. It's possible that a scientific investigation might find that `else {` would be better for those who haven't yet become accustomed to `} else {`, but we're in a world full of people who've already become so accustomed. So `} else {` still works better, just as it works better to use a familiar language even though another language has advantages.

Details: https://thekitepower.com/the-hawk/#space_requirements

Tienes razon sobre el asunto de que uno puede escribir palabras mas facil en otras lenguas. Pero lo importante en este caso es que la gente encuentran lo que esperan. Si la mayoria de la gente buscan `} else {` sera mejor darles lo que esperan. Posiblemente una investigacion cientifica podia descubrir que `else {` seria mejor para los que ya no se acostumbraron a `} else {`, pero estamos en un mundo lleno de gente que ya se acostumbraron. Pues `} else {` sirve bien, lo mismo que sirve bien usar una lengua familiar aunque otra lengua tiene ventajas.

There's an "intro" link to a video at the bottom of the site. Comments can also go on this essay: https://www.lesswrong.com/posts/f2CftRRndH97RpAwL/how-i-got-...

The world's lack of good tools for assessing the truthfulness of arguments is my fault. Some things came up that stopped my work on the next iteration of https://howtruthful.com/ but only temporarily. Expect some big changes in 2024.

Reading between the lines, I don't think this article is about a particular way of using emacs. I think it's about the psychological safety that comes from using a platform that won't pull the rug out from under you.

A lot of tools that are commonly depended on today will change on their own schedule. Nice ones will give you warning ahead of time that a change is coming, but you can't opt out of the change. APIs get deprecated. UIs get reorganized. There's not much you can do. With emacs there's an expectation that what worked for you 20 years ago will still work today. And in rare instances where that's not true, you can just not upgrade to a newer version of emacs.

Working in emacs definitely gives a feeling of control. If anything is ever going to replace emacs (or neovim, which I don't use but I understand is similar), it will have to give the same feelings of control, in addition to the same sense of focus that comes from an uncluttered UI.

I think Apple just hasn't realized yet what a great sales opportunity a UI for quota management is. There's no better place to sell more storage. That's what Google does. See https://one.google.com/storage and https://photos.google.com/quotamanagement which work well for finding stuff to delete, in the hopes that eventually you'll tire of deleting things and go ahead and buy more storage.

What do you mean by more forcefully confident? Do you mean pretending there's no uncertainty? That will only work as long as every result matches its probable prediction. One can be forcefully confident while acknowledging uncertainty. https://www.goodreads.com/quotes/344623-i-know-what-you-re-t...

Note that this was written in 2016 in the context of a mysql-centric project. You will not find an "unchanging strong opinion that foreign keys should not be used" outside that context.

I haven't kept up with mysql enough to know if there are still good reasons to avoid foreign keys. I just stick with postgresql.

Most assets have costs associated with their ownership. So one might temporarily think about ownership in terms of liability as a reminder that those costs exist. However, you should then go back to using "asset" and "liability" in a way that people understand. Don't thank your collaborators for adding useful liabilities to your codebase.

That's a sufficient test. It's the community's prerogative to keep it up to date later with further PRs. I don't expect anyone, whether a company or a volunteer, to do ongoing maintenance work on features that don't directly serve them. The thing I'm testing for is whether they'd block someone else contributing a change that doesn't serve that company or volunteer.

If you were advising an airplane manufacturer where production was tracked by weight, you might admonish them that they were putting airplane parts on the wrong side of the ledger. But later, after they changed their practices to stop encouraging the production of useless parts, the remaining airplane parts would be counted as assets, not liabilities. You, and they, would look back on the ledger comment as hyperbole.

>Isn't it more useful to think of code not as an asset but as a liability?

No, it is not. For consistency, you'd have to start thinking of everything you own as a liability, and only use "asset" to refer to a problem solved by something you own. This would be confusing to everyone you talk with about assets and liabilities. On a day when you didn't drive anywhere, you'd point at your car and say "I got no assets from this liability today." (There would be some truth in that statement, but your listeners would definitely be confused.)

EDIT: I should add, I believe Dijkstra was using hyperbole to make a point with the "lines spent" part of https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...

The best way to test this hypothesis would be to send a pull request that makes the self-hosting docs clearer. If they accept it then their business does not rely on self-hosting being hard.

Is it as easy as you want it to be for JS yet? I would think so from your deno example.

I just signed up. The front page seems to show lots of posts though I haven't followed anyone yet. Do most users avoid the front page?

(I think your comment is on topic for a post about a moderation system.)

In other words, don't stop reading this article until you get at least through the section with the heading "first month: ...".

That's helpful. Thanks.

Would you mind sharing examples of the kinds of things you mindmap? I made a tool for decisions/arguments which ended up incidentally serving as a non-graphical mind map, and I'm curious what people are looking for in this space.

From the article,

   <Card>
     <Avatar />
   </Card>

This is talking declaratively at a high level about the kind of interface to render. Lots of component frameworks look like this example. Thinking "how sad it is that we haven't progressed beyond the state of gluing together low level divs and spans" sounds like a preconceived idea rather than a response to this article.

By the way, I come from mid-80's BASIC on 8-bit home computers. You get off my lawn.

Contrary to what the Dan Luu article says, I see a very specific detail from Bruce Tognazzini that takes the mystery out of the claim that $50MM in research says the mouse is faster. Once you go past the expired certificate warning you can see it too at https://www.asktog.com/TOI/toi06KeyboardVMouse1.html

It's in the context of inconsistent keybindings across different apps, and the pertinent detail is, "It takes two seconds to decide upon which special-function key to press".

Contexts where you instantly know the keys to press are different from what the $50MM research studied.

Thanks for the interesting references. I think I have a better data model than those had, but it's cool that people have recognized before that there's a need for something like this.

The problem that people make quick judgements based on appearance is not modern. I also would like to just make things functional and have people quickly see the value, but unfortunately we're stuck with the need to also make things look cool.

The rationalization given in this comment for the layoffs is obviously false. Google had ways of getting rid of underperformers without massive layoffs that they have been using for many years. Google has ways of getting rid of projects that do not involve layoffs.

My experience trying to market a UX designed for rational discussion is that you still need an engagement-focused part to attract users.