I have a problem with a specific class of pop facts that get thrown around. It goes like this: someone says, for example, "I love tomatoes, it's a juicy vegetable", only to be responded with something like "well, you know, it's technically a fruit".
I think there's a greater issue to resolve before we assign truth values to things stated by both of these people, and I think the underlying lesson is much more valuable than having a clean resolution on what category tomato belongs to.
It's incorrect to assume terminology from one domain can't mean something very different in another domain.
It's instantly obvious when you look at an example:
Bug (n.)
(entomology) An insect of the order Hemiptera (the “true bugs”).
(informal, proscribed) Any motile small terrestrial invertebrate, especially one that is seen as a pest.
In computing, the same word is used for something completely unreleated:
(computing, engineering jargon) A problem that needs fixing.
However, things can get much dirtier. Sometimes the terminologies overalap (there is not a rule that says they can't). And such terms can lead to confusion.
Metal (n.)
Any of a number of chemical elements in the periodic table that form a metallic bond with other metal atoms; generally shiny, somewhat malleable and hard, often a conductor of heat and electricity.
but:
(astronomy) An element which was not directly created after the Big Bang but instead formed through nuclear reactions; any element other than hydrogen and helium.
(I wasn't aware of this unusual usage of the term metal until I looked for good examples for this article. Thanks to my friend Pranav Mahapatra from evincism.com for validating the term is actually in common use in this sense.)
Words don't exist in isolation, context around them can change what they mean.
I would go as far as saying that different people may use and understand a word slightly differently in the same discussion. A lot of times, this results in disagreements: Is hijra a gender? Yes and no:
Gender (n.)
[..]
Sex (a category, either male or female)
Identification as a man, a woman, or something else, and association with a (social) role or set of behavioral and cultural traits, clothing, etc; a category to which a person belongs on this basis.
Neither of the answer is incorrect, they are simply using the word "gender" differently. And neither of these usages of the term is incorrect either. You cannot deny that for most of the history gender simply meant sex and continues to do so. You also cannot refuse, at the same time, that people (and acadamia) don't use it in the second sense.
When having discourse, I think it's imporant that you clarify in what sense your opponents are using a word. This video comes to mind: Jordan Peterson: "What do you mean by believe". He was memed, a lot, by atheists, because he asked "What do you mean by believe"--I think he was doing something, however much I disagree with his definition of what it means to "believe", it's how he chooses to use the word. It's an important clarification however, becuase now the discussion can proceed with his understanding of what it means to believe in mind.
I think we should do this more often.
Two categories may not necessarily be mutually exclusive, that is, a thing can belong to two different categories, A and B, unless their definitions necessarily require them to be disjoint.
This seems obvious, but we do think of some categories as mutually exclusive when they are not. Consider: water, it's both natual (as in naturally occuring) and a chemical substance. A lot of people seem to use the term chemical to mean synthesised, harmful substances, which is of course in mutual exclusion with natuarally occuring.
Chemical (n.)
(chemistry, sciences) Any specific chemical element or chemical compound or alloy.
(colloquial) An artificial chemical compound. "I color my hair with henna, not chemicals."
(slang) An addictive drug.
Again, I am not arguing against such usage, but academia uses it in a way that is not mutually exclusive with natural, therefore, as far as chemists are concerned, water is both natural and a chemical.
Imagine having a conversation where one states "water is a chemical" and the other person states, with an intention to refute, that water is natural. They would be right, but it's not the argument the other person think they are making. Being a natural substance does not imply that water is not chemical. Of course, their statement is true, but it's not in conflict with the initial statement the other person made.
I started with tomatoes, but I sidelined them for the rest of the article.
The pop fact that "tomato is a fruit" has it's origins in the botanical definition of a fruit:
fruit (n.)
- (botany) A product of fertilization in a plant, specifically:
The seed-bearing part of a plant; often edible, colourful, fragrant, and sweet or sour; produced from a floral ovary after fertilization.
The spores of cryptogams and their accessory organs.
Tomatoes fit.
However, the same pop fact has now taken the shape of "tomato is a fruit, not vegetable".
This stems from the fact that in culinary, fruits and vegetables are disjoint categories.
You can't eat your cake and have it too..
Botanical concept of a "fruit" is about classifying parts a plant. The parts of plants that are not fruit are: stem, leaf, root.
The category of vegetable is simply not something botany concerns itself with. Why should it? Whether something is vegetable is of little importance to a botanist.
To me, saying "tomato is a fruit, not a vegetable" is an idiotic statement to make. Not because it is false (which it actually is [1]), but because it misses the point of both, botany and culinary classification of fruits and vegtables.
It reads like the person making the claim does not actually know what a botanical fruit is--one would never contrast that with a vegetable otherwise.
This "pop fact" is "pop" becuase it spread by people stating it to others verbatim without actually getting into the nature of those words in botanical and culinary disciplines, and providing no argument for why something that's a fruit can't be a vegetable (spoiler: it can).
Furthermore, the culinary classification is culture based and there is no clear line between fruits and vegetables.
Quoting Wiktionary:
(culinary) Any sweet or sour, edible part of a plant that resembles seed-bearing fruit (see former sense) even if it does not develop from a floral ovary.
- A sweet or sweetish vegetable, such as the petioles of rhubarb, that resembles a true fruit or is used in cookery as if it was a fruit.
But the way I personally see people use the term as:
A part of the plant, shaped like true-fruit, which is eaten without cooking.
By this definition, something can be a (culinary) fruit or vegetable depending on where you live and the culinary norms.
In parts of India, jackfruit is cooked while in others it's eaten raw. That makes jackfruit a:
Even at an individual level, for a person who eats tomatos raw (yes I do), it is a (culinary) fruit.
Below is an interactive diagram that shows relationship between each of these terms. Intersections are clickable.
Do you know more such terms that have caused similar class of confusion? My e-mail inbox is open.
Also: how do you define a vegetable?
When you talk about fruits and vegetables in the same sentence, I am automatically going to assume you mean "culinary fruit" since the entire category of a "botanical vegetable" simply does not exist.
People in the tech industry assume everyone has a LinkedIn account with an up-to-date profile. I do have an account, but I refuse to update or use it; for various reasons listed here.
Read:
I don't want my employment histroy to be public. Simple as that.
I do not understand why employers and everyone in corpo expect everyone to put their employment histroy and education background out open in public, for everyone to see.
If you want to know where I have worked for the entirity of my career, you should have to request that information from me; in form of my resume for example. I do not believe this information should be publicly available for viewing without my permission/consent.
Most, if not all LinkedIn posts on my LinkedIn feed are one of either:
I do not wish to see any of these.
If you are my employer, asking me to update my LinkedIn profile with your organisation's logo or post something on behalf of you: I refuse. And I will quit my job over it if this is a deal-breaker for you.
If you are a co-worker/peer/friend: now you know why.
I had just began to cook my super secret project for which I needed an embedded data store to back my data.
Now, I could, use a well known and well supported solution. But hey, that's not very fun, is it?
I decided I will write my own. Not because this was an "unsolved" problem, but just because I thought "how hard could it be to roll by own key-value database?".
I had recently read up some literature on building simple databases from various sources and really wanted to give it a try. The whole process has been very rewarding. I might even give building a relational database a shot in future.
My goals for the store (from the orignal use-case) are:
Git has traditionally used files under .git/refs to store refs ("loose refs").
This is simple and worked, however some large repositories such as android and
rails had way too many refs and lookup was noticeably slow.
Other problems with loose refs include:
It should be noted that git also had the "packed ref" format as an alternative but it had its own problems:
This lead to the development of the new reftable format which employs an LSM-tree-like storage engine. The performance gains are massive in terms of both query time and storage.
For more information, see reftable page in git's documentation.
This facinated me and I dived a little bit into the design and implemenation details of this new format.
While looking around the ideas and techniques behind the reftable format, I found a few more key-value databases. The one that perticularly stood out to be was RocksDB. Reading about it, I discovered the concept of Log Structured Merge trees (LSM trees).
I also named this project SandDB because I was inspired from RocksDB.
The core and heart of SandDB is LSM tree. A data structure designed for very fast writes.
LSM trees have a tiered storage model where each tier/level is more "permanent".
The first level is (usually) backed by an in-memory data structure. This is
called a "memtable". SandDB uses Rust's BTreeMap (for no other reason than
it is readily available for use in the language).
All the new writes are added to the memtable and no files are touched.
If you can't tell, this is very fast since we inherit BTreeMap's insertion
time complexity i.e. O(log n) where n is the height of B+Tree.
Of course, entries in the memtable will eventually have to be written to files in order for the store to be persistent.
Once the memtable reaches a certain threshold, it is flushed to an SSTable file. This is an immutable file i.o.w, once created it is never modified.
We must also flush the memtable to an SSTable when the database exits so that we don't lose any entries.
SSTables are binary files. I have documented it's format here if you are interested.
Now since we create a new SSTable on each flush, we will inevitably end up with several such files over time. This can be a problem for querying as we might end up having to scan a lot of different files. Opening files also add to our number of syscalls per query.
We must therefore occasionally compact our SSTables, i.e. merge smaller SSTables into a larger ones.
SSTables are tiered. When a memtable is flushed, a level 0 SSTable is created. When we have "way too many" SSTables, we initiate a compaction: gather all level 0 SSTables and merge them into a single level 1 SSTable.
When we have enough level 1 SSTables, we merge them to level 2. At the time of writing, SandDB only merges upto level 2. We also merge several level 2 SSTables into one if there are too many of them.
We only pay the cost of compaction once in a while.
An additional file called manifest is kept around to track the SSTables and their metadata. It includes:
Each time an SSTable is added or removed, the manifest is updated to reflect the same.
When querying, the reader looks at the manifest and figures out which SSTables might contain the key it is looking for and reads those in the order of their (ID, level). The ordering matters because we want to ensure we look in the most recently written SSTables first.
We only open the SSTables which the manifest tells us might contain our key. This way we don't have to open every single SSTable and we save reads and syscalls.
We can also go beyond having a key range and add per-SSTable bloom filters in the manifest. This would further reduce the number of files we would have to open and read. I plan to implement this sometime later in future.
The manifest file is a WAL-style file. When a new SSTable is added, an entry saying "added sst x" is appended to the file. Similarly, when an SSTable is deleted, an entry saying "deleted sst x" is inserted.
Why do this instead of rewriting the manifest? For atomicity (and possibly for isolation, in future).
If we replace the entire contents of manifest instead of appending, a reader in the middle of reading manifest might end up reading first half of the file before the sst was added and the later half after.
I will admit that SandDB does not yet allow concurrent read/write, however I do see myself sitting down to implement it in future. Soon (TM).
I have documented manifest file's format here here if you are interested.