Just to clarify, I'm not advocating to introduce a new `unknown` keyword. I'm saying that the existing `null` in SQL was not named properly and that the name `unknown` would have been more fitting. SQL's `null` already has the semantics of `unknown` as explained in the part of the article that I quoted.
SQL NULL is not "exactly equivalent" to unknown. E.g. in an outer join, there's nothing unknown about the result that is missing a row from one side, yet SQL semantics is to fill it with nulls.
In practice, it behaves as "unknown" in some contexts, as "missing value" in other contexts, and sometimes it's just plain WTF like SUM() returning NULL rather than 0 if there are no rows.
The term "null" comes from C. A. R. Hoare, who has proposed in November 1965 various additions to the programming language ALGOL 60, including pointers (called references by Hoare, "pointer" comes from IBM PL/I, in July 1966), and including a special value "null" for references a.k.a. pointers, for denoting unknown or not applicable values.
C. A. R. Hoare, 1965-11:
"In order to enable references to represent partial functional relationships, i.e. ones which do not necessarily yield a value, a special reference value null is introduced.
This value fails to refer to a record, and any attempt to use it to refer to a record leads to an undefined result."
In his proposal, Hoare has followed the COBOL 60 terminology for some of the additions to ALGOL, i.e. "record" instead of the word "structure", introduced by IBM PL/I in 1964-12, and "record class" instead of "structure type", hence the "class" of SIMULA 67, from where the word "class" has spread into all OOP languages.
In Hoare's proposal, references a.k.a. pointers could point only to values belonging to user-defined types, i.e. records a.k.a. structures, not to primitive types.
I wouldn't necessarily define `null` as "unknown" -- it's just "no value" -- which is really the same thing and also somewhat equivalent to "unset". But null pointers aren't unset as pointers aren't initialized to null in C and you can explicitly set a pointer to null.
E.F. Codd added nulls to relational model in 1970 so that does pre-date C. The concept is even older than that I imagine.
In nth normal form, you can't have 'no value'. That would mean your model is wrong. In academic relational data books, null does mean "unknown". There is a value, we just don't know what it is (yet).
If there might actually not be such a value, you're supposed to change your schema to reflect that.
> There is a value, we just don't know what it is (yet).
In all my years, I've never used null for that. If I don't have a value yet then generally I'm not writing any part of the record. I only ever use nulls for the absence of a value. Creating a new table for every potential optional column is the "academic relational way" and also insane. :)
What happens if your data is produced by some automated process such as a sensor reading and occasionally the sensor fails to return a value? NULL seems exactly the appropriate value to use.
I'm still a bit confused. Suppose you have another table, call it temperatures with columns id and temperature, where every row contains only a valid temperature (no NULL records), and you have a main logging table with date and temperature_id so that you can join on temperature_id = temperatures.id. This seems to be what you mean, with a canonical measurement record table related via the temperature_id foreign key.
But then if your sensor fails to record a measurement don't you end up with NULL for that row's temperature_id?
Ah but then how do you record that the measurement actually happened but did not produce a value? I want a record of that failure.
I mean sure, you could do yet another table. But honestly that level of normalization is much more work than it's worth. Just because it's some academic definition doesn't make it right.
You'd also have to ask when NULL came into common use in C (to which I do not know the answer). AFAIK NULL was not considered to be standard until C89. As far as I'm aware, all C compilers implement it as a #define in a standard header somewhere; it's not actually part of the core language itself.
I wonder who first added that macro? Was it there from the beginning?
I think authentication is about proof of identity. Identity can mean a lot of things imo. Applications identify me all the time without me giving them any proof of who I am. This happens in meatspace all the time too. People project identity and we make assumptions about what we observe. We don’t necessarily ask them to verify this identify through mutually agreed upon terms.
Second the room treatment. It should likely be prioritized over everything. Specifically you should look into getting bass traps and a gobo or three. There’s budget stuff out there but sound is fickle. Control those reflections. Expensive mics still sound bad if a room sounds bad.
I’ve had limited success with the null object pattern but there is one case that it worked really well for me. I worked on a feature that was highly dynamic and users could compose reports selecting data points from tangentially related models. Null objects were a really helpful pattern because it was hard to anticipate how models would be composed and if a developer made a mistake it was hard to notice there was no effect. Our null objects would raise exceptions in development and explain what you need to change but wouldn’t prevent execution in production.
You could easily argue we should have just presented this exception to the user in all cases but this is where we landed. It’s probably the only case this pattern was beneficial for me.
I’m trying to recall a time in my career where I’ve heard this phrase and it was actually a technical problem. Most of the time this is a dismissive response that is more political than it is technical. And let’s be honest — we’re the ones inventing the architecture of the applications. If a feature is desired but it “conflicts with the architecture” then you figure out how to resolve the conflict.
They already have the feature implemented, in their paid Enterprise Edition. Why would they accept an outside contribution for code they've already written? If they want it in the community edition, they'd just add their own implementation, and then not have two different implementations of the same feature to maintain. That sounds exactly like "not fitting into the architecture".
Regardless, they are not obligated to accept any contribution that they don't want, for whatever reason, even if that reason is "profit" and "business model".
The full sentence was "However, ToolJet enterprise edition already has this feature and there will be a conflict in the architecture if we merge this PR."
That explanation seems completely reasonable to me. Why should they maintain 2 different implementations of the same feature, 1 of which they didn't write in-house? Why should they spend time reviewing and merging something contributed by a third party who couldn't be bothered to read or follow their CONTRIBUTING.md, let alone something that hurts their own bottom line?
I agree it's reasonable, but the claim there are "technical reasons" for the rejection is bullshit. They're obviously rejecting it largely (if not entirely) because it's a feature they sell in the paid version.
If the rejection was actually because of technical merit they would have (1) explained in more detail than "conflict in the architecture" and (2) left the PR open for the submitter to fix.
It's not bullshit. It conflicts with the architecture because they already have the feature implemented, presumably in a different way. And they plainly state that it's present in their paid version; they're not trying to hide that fact. Leaving the PR open and essentially helping the author morph the code into the exact same implementation the paid version has seems like a pointless exercise. If they wanted it in the community edition, they'd simply copy the implementation from the paid version.
Not sure why you're so up in arms about this. They built the project themselves; they get to decide what goes into it. People who don't like that are free to fork, and compete on their own merits.
> If they wanted it in the community edition, they'd simply copy the implementation from the paid version. […] Not sure why you're so up in arms about this.
Because they don’t want the feature in the free version even if someone gave it to them.
So when you invest in open-core, you don’t get incremental improvements as people collectively make an effort, like open-source. You get incremental improvements by eventually switching to the paid version.
> Because they don’t want the feature in the free version even if someone gave it to them
Gave it to them? They already have an implementation of this.
How is it a "gift" to spend unpaid time reviewing and merging a duplicate implementation, and then maintaining it forever, even though it likely has different dependencies and configuration option names than their existing implementation? And then after all that effort, all the maintainers get in return is a pay cut, if some paid users downgrade back to the free edition because they were only paying in order to use that feature?
As stated clearly in their CONTRIBUTING.md, this project follows the very common practice of requiring prior discussion on an issue, before submitting a pull request.
In this case, the pull request author completely ignored that process and submitted a 400+ line unsolicited pull request with no prior discussion. All of the wasted effort would have been completely avoided if the PR author bothered to post a single-sentence issue asking if the maintainers actually want this.
As for a chilling effect, the worse one I see is maintainer burnout from having to deal with PRs like this.
What I'm saying is that there are probably many, many authors who realise that and wouldn't risk contributing (therefore having a chilling effect). Kinda makes the project "open source-ish". All the legal infrastructure, none of the community norms.
> It’s not about the wisdom we glean. It’s about what wisdom we grow.
I think the author does a good job of actually testing the original point—questioning if all but a handful of books are a worthless distraction. I think the entire piece has almost nothing to do with prayer. The monks are used as a thought experiment around the value of thought for the sake of thought.
That we should not take shortcuts and expect we'll gain anything by exchanging an extended treatment of a subject with a distilled short talking point.
Do you have any sources on birders directly causing extinction? I think it’s absolutely wild that someone in that profession would drive a species to extinction just to draw it so I’m curious to read more.
One of the most famous is Rollo Beck and the quelili. Collecting bird species was a very fashionable thing to do, the rarer the more money it brought in. Better to stuff it and exhibit it than to lose it to the forest - this is before conservation was as concept was a thing.
We're losing bird species like crazy - mostly due to lose of habitat (the big reason for the quelili as well). We're never going to learn.
Yeah but we also overestimate that because when you trace all the references back you come to a dubious statistic formed from someone predisposed to the position.
Sure, anything you don’t like must come from biased sources.
It doesn’t trace back to a single statistic, multiple independent studies have looked into it. The often quoted 1 billion birds killed is actually below most scientific estimates of around 1.3 to 4 billion: https://www.nature.com/articles/ncomms2380
With domestic cats causing ~31% of the ~2.4 billion deaths and strays making up the majority. You can get similar numbers by ignoring domestic cats and simply look at the stray population and roughly estimate how much meat they need to survive and then compare the percentage of bids vs small mammals caught.
Besides just the fact that the American bobcat's range is all of the continental USA and it can outcompete the domestic cat in the wild for prey easily.
Sort of a natural limitation of science is that any "study" is treated as gospel truth by people not acquainted with the process or the mathematical knowledge required to verify.
Even low ends of the estimates for US stray cat population is 10x that. The majority of them need to hunt life prey to survive vs handouts, which is mostly small mammals but anyone that’s been around outdoor cats notices the birds are on the menu.
I’ll turn this around what percentage of a wild cats diet do you think are birds? 5% or 15%? You can work out the pounds of meat they need to survive a year and work back to number of birds needed.
Stray cats are distributed primarily in the urban population, not in the wild. They kill a bunch of pest birds which we'd otherwise use Ovocontrol or something similar to deal with.
That Nature study is pretty much all Fermi estimates. Since we're trading questions until you start answering, what is your estimate of house cats in the wild.
Fermi estimates are fine, we aren’t trying to track bird deaths out to 6 decimal places. I have no problem saying 30-70 million stray cats and something like ~6 billion calories per day from wildlife.
Stray cats may have higher density near people but so do song birds because humans feed birds they like to look at. Someone buying 10kg of bird feed a month keeps quite a lot of bird biomass alive.
Ah, but humans kill about 7 billion birds a day. So it's a drop in the bucket.
Or so one could reach with Fermi estimates. I think it should be made clear when you link that study that you meant "a back of the envelope calculation says that x birds were killed" etc. etc. rather than implying there was any rigor to it.
Literally making up a number doesn’t support your point, as shown with your wildly incorrect bobcat statement.
And no you can’t reach 7 billion birds a day killed by humans from an honest fermi estimate. People collect information on birds, making wildly incorrect stuff up quickly contradicts actual information which bounds the potential numbers. Feel free to try or actually come up with any actual estimates that support your point.
If it was easy to show this research was wildly inaccurate someone would happily publish a paper showing the errors. You on the other hand are just trying to hand wave I don’t like this therefore it must not be true which is only making you come off as a fool. No, wishing really hard doesn’t make reality bend to your preconceptions.
