davidverhasselt

You've missed the point of my comment entirely and pulled two items out of context.

I'm missing a good reason why the distinction needs to be made visually clear. More about this at the end.

I think a lot of this design thinking is stuck in the past, and we should be able to challenge and throw off some of the shackles or crutches that made sense back then, but might not anymore today, in order to advance and give priority to different goals.

In this specific case, it should be clear that you can select multiple options from context or by text, or it should be encouraged to try it out (i.e. easy to undo). If you need to rely on the visual difference of the icon, then you've already lost more than 50% of the people who don't realise this.

My thesis is that this visual difference is only useful to a select, minority group of people who have an above average level of interest in software, who would even be aware of it. Yes, they were probably the target market decades ago, but nowadays software caters to a wider group than that, and I wonder if you would survey a group of "normies" how many would actually rely on the visual distinction in any way (even just supportive).

I'm late 30s and I remember being confused about the difference between "radio buttons" and "checkboxes" when trying to learn HTML4 when I was young - even the name "radio button" was back then already only something older folks would be able to understand, why it's called that way. The distinction, even conceptually, was more confusing than helpful. It's really just a property of a list of checkboxes, how many you can select, not an entirely different class of UI component.

To continue on from my first sentence, and conclude my argument, this whole article does not contain a single good reason why that visual distinction is important in 2024. The closest I could find, is this line which implies confusion: "There was a brief confusion up until 1986 when Apple used rounded rectangles instead of circles". Just the fact that the article has to describe the difference and show visual examples, tells me that this is just no longer a concept that's important, as it may have been 30 years ago, from when it originated.

Instead, it only makes references to "tradition", "convention", "internal training", or arguments from authority such as "art director says so".

I think that kind of supports my point - in the context of UI of 2024, the only reason that one would keep the distinction visually is for tradition, not for any actual practical reason anymore, or the practical benefits that may still be there have diminished in value so that they don't outweigh the downsides or extra constraint anymore.

Silverfin https://silverfin.com | Senior Ruby Engineers | Remote, European Timezones (including Africa) | Full-time contractor

We’re a bunch of fine folks in a fully remote team, working on a nice up-to-date Rails monolith with some Vue.js sprinkled on top.

Our SaaS product and platform is making accountant’s work more meaningful by improving their workflows and replacing their hairy Excel sheets with a 21st century product.

Read more about what our values are and what working with us is like on our job ad: https://grnh.se/550cf58b2us

Silverfin https://silverfin.com | Ruby Engineers | Remote, African & European Timezones | Full-time contractor

We’re a bunch of fine folks in a fully remote team, working on a nice up-to-date Rails monolith with some Vue.js sprinkled on top.

Our SaaS product and platform is making accountant’s work more meaningful by improving their workflows and replacing their hairy Excel sheets with a 21st century product.

Apply here:

* Senior Ruby Engineer https://grnh.se/550cf58b2us

* Senior Ruby Integration Developer https://grnh.se/cfcd3b182us

How to choose? As a Senior Ruby Engineer you will work on our main product in our large codebase together with 25 other engineers. As a Senior Ruby Integration Developer you will work in a smaller team of engineers closer to the professional services team, and will be developing smaller greenfield products that link our main product with third party software to accomplish commercial goals.

Hehe, that's creative. But I'd say - if you're making it that complex, just use a boolean column and a timestamp column separately instead, if you really need the timestamp, and make it explicit and simple to understand.

The OP does not talk about events, OP talks about state and when it was set. There's no where in the article that OP restricts themselves to discrete events that may or may not have occured.

I'd assume most languages don't have a problem with distinguishing between nil and false. The article explicitly maps nil to false, thus I don't see the relevance of your comment.

There is a downside which I've experienced: if you want a triple-state boolean (null, false, true) then having a boolean column allows for that while a timestamp-as-boolean column does not (you lose the "null" value because that equals `false` in timestamp-as-boolean).

Having a distinction between `null` and `false` can be handy for values that are optional or have a dynamic default. If it's `null` you know it is not explicitly set and could use a fallback value. If it's false you know it's explicitly set as false.

A simple use-case for this is when a user can leave the field blank. This is impossible to model with only a timestamp-as-boolean.

Another use-case is dynamic defaults or fallbacks, e.g. `hidden` of a folder where if `hidden` is nil, you fall back to the parent folder's value.

TL;DR a boolean column actually has 3 states, a timestamp only has 2. Article makes a big deal about there not being any nuance about the fact that a timestamp is superior. I disagree, because you go from 3 states to 2 states, there are cases where you'd want a boolean instead of a timestamp. Ironically OP missed this nuance (or they'll pull a no-true-scotsman).

Silverfin https://silverfin.com | Ruby Engineers | Remote, European Timezones (including Africa) | Full-time contractor

We’re a bunch of fine folks in a fully remote team, working on a nice up-to-date Rails monolith with some Vue.js sprinkled on top.

Our SaaS product and platform is making accountant’s work more meaningful by improving their workflows and replacing their hairy Excel sheets with a 21st century product.

Apply here:

- Senior Ruby Engineer https://grnh.se/550cf58b2us

- Senior Ruby Integration Developer https://grnh.se/cfcd3b182us

How to choose? As a Senior Ruby Engineer you will work on our main product in our large codebase together with 25 other engineers. As a Senior Ruby Integration Developer you will work in a smaller team of engineers closer to the professional services team, and will be developing smaller greenfield products that link our main product with third party software to accomplish commercial goals.

In a similar vein, I recently purchased this ebook https://pawelurbanek.com/heroku-migrate-postgres-rds - I haven't finished it yet but I enjoy the small, edited format of it.

Hey folks, creator of Coronadaily.io here

To try and cut down on my pandemic-related news consumption I forked my code for https://hndigest.com and repurposed it to send out a daily report every morning with the stats and graphs of the day before. I made this my "single corona-related moment" of the day, so I can get it over with and get on with my day.

You can select which regions you'd like the graphs to be from, including specific subregions in the US. As a Belgian living in Estonia I've set mine to send the stats on Belgium, Estonia, US, and China.

It's a rough first version and I'll be adding more stats and polishing things up a bit as we go along. I'll try answering questions as best I can, and will gladly accept feedback.

If you're looking for only HN stories, hndigest does it for free https://hndigest.com/

(note: I'm the maintainer of HNDigest)

You can easily disable the escape key on the TouchBar using the free Karabiner-Elements https://pqrs.org/osx/karabiner/

This is my setup: https://d.pr/i/sP4OMX

To stay in your simplified universe, consider just two entities, A and B. A has all $100K, B has $0.

- A loans $100K to B at 10%.

- B buys raw materials from A for $100K and creates products X and Y.

- A buys product X from B for $60K.

- B returns $60K to A.

- A buys product Y from B for $60K.

- B returns $50K to B.

A ends up with $90K and product X and Y. B ends up with $10K. At no step was money created out of thin air. Total supply still $100K.

You could simplify it some more by allowing B to pay back A using product X and Y instead of moving $60K around back and forth.

If you would like to learn why this common myth is false, I would recommend the book "The Ascent of Money: A Financial History of the World", which in one of its chapters explains that this result actually made the Rotschilds go almost bankrupt because they were betting on a prolonged war, and they were just barely able to maintain their wealth despite the defeat of napoleon, not because of it.

Heya, I run https://hndigest.com - you can configure it to email you the top n posts over a certain period (daily up to weekly). Check it out, it might suit your needs.

Hehe, good news I guess! Just hit reply on the digest if/when anything comes to mind :)

Hey, developer of hndigest here, thanks for being a happy user, and great to hear that it's helping you :)

Anything I can do to make it even better?

Indeed, I too had difficulty finding exact information on this new change. I then stumbled upon the PwC tax alerts where it was very transparently explained. Personally I wouldn't mind if they would take a bit longer to implement changes like this, so everyone can be accurately informed and optimise in time.

> In addition, if you've taken out profits before, then the company income tax is 14%, up to the amount that equals the average of the last 3 years. So if you take out similar profits on a regular basis, the tax rate is only 14% on everything.

As I understood it, this is only so for distributing profits to legal entities. If you're distributing to a private person, the private person will have to pay a new 7% income tax which sums up to a total of about 20%. This of course only matters if the private person is tax resident in Estonia.

I find the PwC tax alerts very informative to be kept up to date on the tax laws in Estonia: https://www.pwc.com/ee/en/press-room/tax-alerts/estonian-tax...

Hey raybb, thanks for being a subscriber :-)

I see what you mean. I'll investigate it, however designing html emails is kinda like black magic (although less nowadays since Gmail supports responsive design from October 2016) so no promises!

HNDigest (https://hndigest.com) is profitable some months, others not so much. Turns out it's quite expensive to send a ton of emails if you don't have sponsors.

I should probably spend more time finding sponsorship.

Hey, thanks for linking hndigest! We're in the process of rebuilding hndigest from scratch. If you'd like to sign up now, I suggest using the beta version which has improved looks and robustness (and upcoming new features): https://beta.hndigest.com

(If you're an old subscriber, you'll be moved to the new version in the upcoming days/weeks. Don't fret, if you don't like the look of the new version you can still select the old-style look).

Considering that this would be pretty easy to prove, but no one has yet, Occam's razor says this most likely was something else entirely. One possible explanation could be that the ad was shown to her before as well but she didn't notice it, yet it subconsciously registered and created a need or idea for such a product (i.e. you're switching around cause and effect). Another is that your wife is quite predictable in her demand of such a product due to other factors that are trackable by Facebook.

I can see drones being used in cities to dump packages into the top of packet vending machines that already exist, that open up with a PIN code. It'd be much easier too because the route can be hardcoded towards the machine.

The machine could just give you the UUID of a previous vote for the same candidate, and change your vote to another candidate. Using a HMAC with a personal secret key would work.

Probably not much less secure than calling and giving your CC to a person jotting it down or emailing with the same details. Most of the hotel custom booking forms look like '90s HTML3 pages so the alternative is usually not better anyway.

As an end-user, booking.com gives me so much added value I don't mind paying 10% more than I could maybe, possibly negotiate with the hotel on the phone. When I hear hotels complaining about booking.com fees, I believe they're ignorant of the end-user's plight. They're also free to not be listed on booking.com, but obviously the discovery is worth it to them.

Off the top of my head, a short list of advantages I like:

- someone that will take my side in disputes

- being able to book multiple hotels on one account, in the same place

- cards in wallet in my iphone

- knowing exactly what I'll get

- avoiding misunderstandings that might arise when having to book orally (i.e. wrong number of rooms, wrong number of people, ...)

And that's beyond the superpowerful search, which is kind of immoral to use without giving them the referral fee.

Yep, no problem! I also thought it quite interesting which is why I remembered this specific tidbit.

The research on the so-called "Mariel boatlift" in the 80's was done back in 1990 and has since been disputed:

> Most recently this has centred on a dispute between two economists, David Card at the University of California, Berkeley, and George Borjas, at Harvard University, over the effect of an unexpected surge in Cuban migrants to Miami in 1980 (the so-called “Mariel boatlift”). In 1990 Mr Card found this influx had no effect on the wages of low-skilled workers in Miami; Mr Borjas has now revisited the analysis, and claims that wages of high-school dropouts in fact fell substantially.

Source: http://www.economist.com/news/united-states/21705699-who-are...