This SAM9x60D1G-I/LZB SOM module is a mouthful to say. But at 28mm x 28mm its roughly the same size as a US Quarter. But… at $60 it sounds like a bad value. Okay, it is a bad value, but stick with me here, this represents far more than you might think.
The Orange Pi Zero is not that larger (48 mm × 46mm), ships with up to 512MB DDR3 SDRAM, wifi, and 10/100M Ethernet RJ45, and can be bought for half the price.
I think that it’s because a) the abstraction does solve a problem, and b) the idealized solutions aren’t actually all that simple.
I'd go a step further and state quite bluntly that these critics do not even understand the problem that the abstraction solves, and their belief is formed based on their poor and limited understanding of the problem space.
Everyone can come up with simpler alternatives if they throw most requirements out of the window. That's basically the ages old problem caused by major rewrites and their expected failure once the unknowns start to emerge.
But I still agree with the article because I also think that a) the problem solved by the added abstraction isn’t practical, but emotional, and b) the idealized solutions aren’t all that complex, either.
Hard disagree.
There is not a single technical argument refuting these abstraction layers; only ignorance of the problems they solve. It's easy to come up with simpler solutions if you leave out whole sets of hard requirements.
The idealized solution never leaves the conceptual stage because the idealized solution is never thought all the way through and the key requirements are never gathered. That's when the problems solved by the abstraction layers rear their head, and what forces these critics to face the fact that their proposed solution is inconveniently converging to the real world solution they are complaining about, but that they are reinventing the wheel poorly.
I like this bit because it really is a common answer whenever someone complains about how maddening/inefficient some tooling is nowadays.
I don't think this is a valid take. What we see in these vague complains about levels of abstraction is actually an entirely different problem: people complaining that they don't understand things, and they feel the cognitive load of specific aspects is too much for them to handle.
If the existing layers of abstraction were actually a problem and they solved nothing, and if removing them would solve everything, it would be trivial to remove them and replace them with the simpler solutions these critics idealize.
A very large part of the problem is that the people who are knowledgeable are often the ones that bought into the whole lone wolf coder shtick.
I'd add that a large part of the problem is that we have people complaining about perceived problems without being able to present any kind of solution.
Like everyone has mentioned, because you want the data to persist across program runs.
RDBMS do not imply persisted data. There are plenty of databases which support or are designed explicitly to work as in-memory data stores. Perhaps the most popular one is SQLite, whose in-memory store is a popular choice.
Why do so many programs use rational databases instead of loading the data during startup and keeping it in memory?
I presume you're referring to relational databases instead of rational.
The responsibility of a RDBMS is to implement a set of performance-focused data structures that help clients reliably get the data that they need in the fastest possible way, without having to reinvent the wheel.
More often than not, this data does not fit in the heap.
Also, in many usecases there is more than a single client.
I think you’re missing the point. It’s exactly cause Microsoft created it that people get worried about it.
I don't think there is any merit to that concern. Not only is TypeScript FLOSS, Microsoft also has an excellent track record developing high-quality programming languages and tech stacks. Take for example C#. It's been around for over two decades and if anything it's getting better by the release.
I understand the rationale behind the concern, but there is also a factor of mindlessly parroting cliches.
Could also be that the standard is lacking in some areas.
I don't think that explains it.
If we're talking about extensions that cover custom features then obviously those aren't supposed to be standardized because they haven't been widely adopted.
If an implementation is missing a feature then that's a shortcoming of that particular implementation, not SQL's.
If an implementation screws up and has non-compliance qwirks, that's a bug in the implementation, not a problem with SQL.
SQLite is pretty popular. Does this mean SQL is lacking in any way? Is the SQL standard "lacking" because it supports ALTER TABLE foo ADD CONSTRAINT even though SQLite does not? Or is this a problem caused by an implementation failing to comply with a standard?
I’m absolutely biased as a data engineer who loves SQL, but there are some good reasons why SQL has been the de facto standard for interacting with databases since the 80s.
I find it funny how the people who actually have to wrangle data swear by SQL as awesome, but there are always random hacks coming out of the woodwork, who don't even look at SQL at all, with sweeping statements claiming SQL sucks because reasons.
It's like the most opinionated people against SQL are the ones who don't use SQL.
sql was built so people other than devs can use it, but we got stuck with it.
Not really. Being designed with UX in mind, so that it sacrifices conciseness for readability, does not make it something for "people other than devs".
Likewise, BASIC was also developed with UX in mind, and no one in their right mind would ever claim that it's not a programming language.
That does not mean that SQL, as specified by one of it's standard versions, is not portable. It just means that some implementations fail to comply with the standard and/or provide their own extensions.
If an implementation fails to comply with the standard, that's a failure on the side of the implementation, not a failure of SQL.
It’s long running, so you want a database so you can store your state. If you’re storing state, locking it into a state machine makes sense.
That's besides the point. Of course that the most fitting way to represent a state machine is with a state machine. The point is that implementing the transition table in a database table creates many problems while apparently solving none.
Also, it’s worth noting that cargo is a fairly good package manager all things considered.
Yes, I'm familiar with Cargo. My point was to point out the absurdity and silliness of OP's remarks on "no bulky management of a virtual environment, no make files, no maven, etc." Once Rust fundamentalista take off their rose-tinted glasses, it's clear that Cargo is just as good (or as bad) as any contemporary integrated build system.
The Orange Pi Zero is not that larger (48 mm × 46mm), ships with up to 512MB DDR3 SDRAM, wifi, and 10/100M Ethernet RJ45, and can be bought for half the price.