This is 100% correct. We're in the process of doing this now with our products (and our internal systems, also), and it works well.
When you have products and systems that have been around for a decade or more, major portions of them become outdated and need to be rewritten (or largely rewritten, the two are synonymous to me). Best practices in crypto change, operating systems and hardware improve/change, etc., and if you want to keep generating value, you had better change along with it. You can see where organizations don't do this: the developers force weird constraints on IT like needing to use old, obsolete versions of operating systems because the software won't run on newer versions.
Along these lines, one of the problems that I think exists with the software industry today is an inability among developers to recognize that software sticks around a lot longer than one might originally envision. And this phenomenon only gets worse (better, for the end user) as the value provided by the software increases. It's a bit of a Faustian bargain: everyone wants their software to be used and provide value, but often don't realize the "soft commitments" being made in the background that can tie you (or the business) to the code for years (or decades).
Anything that deals with the source data, such as aggregation, sorting, or partitioning, should be done with SQL.
Anything that deals with the formatting/display of the columns in the result set rows can be done in SQL, but doesn't have to be done in SQL. It's really a matter of convenience to do it in SQL, especially when dealing with multiple front-end languages, because it means that the formatting is done in one place.
To me, the distinction is between a society where individuals are free to choose to rent or own, based upon their private circumstances, vs. a society where individuals are forced to rent because it is impossible to own. It seems to me like we're heading towards the latter, and that's not good.
Key-value stores are fine if you are always simply grabbing a single row/tuple from a single dataset. Any time you move beyond that, you're in for a world of hurt compared to a relational database that uses SQL.
The reasons are:
1) You often need a transactional, consistent view of the data across multiple datasets (tables). Relational databases using SQL provide that, key-value stores may or may not (most likely not).
2) Any time you're doing any kind of aggregation, key-value stores will require that you pull all data in locally and perform the operation there. It's questionable whether the local environment even has the resources to accomplish such a task, and the efficiency of such operations will be dismal compared to a SQL-based relational database server.
Key-value stores are, from an interface perspective, very much like the older ISAM databases that were popular before SQL and relational databases gained a foothold in the industry. They also recycled the exact same problems that SQL-based relational databases solved so elegantly (round and round we go).
Another way to put it is this: leaving aside scaling for now, SQL-based relational databases can typically do everything that a key-value store can do, whereas key-value stores cannot typically do everything that a SQL-based relational database can do.
The interesting part to me was the variations in the emitted instructions, based upon the source. IOW, it would be easy to mistakenly think that you weren't going to get jumps if you only used a few case branches to test things out.
Our product, Elevate Web Builder, has been using component-based visual controls with no CSS since 2014. It's modeled on the traditional way of doing components/controls in Delphi's VCL and .NET's WinForms, with a splash of WPF in terms of how control interfaces work.
I tested this recently (Delphi XE6), and it definitely is as-described: you get straight jump instructions with enough case statement branches, and it is very fast.
Barry Kelly worked on the Delphi compiler, and I believe he comments here on Hacker News occasionally.
Many of the older homes here are wood (typically, balloon frame) with a sandstone foundation, so you can reduce the amount of heat loss by making sure that the sandstone mortar is in good shape, making sure that all windows and entrances are properly-sealed, and strategic use of insulation. I say "strategic" here because you have to be careful about making the house too tight, which can cause moisture to get trapped and result in very bad things like sill rot.
The key is that these old homes have very good "bones", so even a gut job can use the original structure intact. Combine that with the fact that Buffalo's real estate is relatively inexpensive still (it's starting to get up there, though), and extensive renovations aren't too bad on the wallet.
Yeah, I kind of conflated my anecdote with the reference in support of my anecdote. I'll have to see if I can dig up more data on this.
As for population, you have to be careful with the statistics on this because, while the area did lose population since the 70s, there was also a lot of flight from the city to the suburbs over the same time period. So, it is often more instructive to look at the total population of western NY instead of just the city of Buffalo.
I know that you're probably talking a lot older than one century, but as a minor counterpoint:
Our house (in Buffalo, NY area) turned 100 this year, and there are thousands of houses just like it in the Buffalo area. In fact, most of the housing that was built in the late 1800s and early 1900s is still standing:
So, how is getting paid for one's time any different from being paid for the value of one's labor ? Do you think that economic theory doesn't apply in that case, and that, somehow, a person isn't going to just simply demand a huge salary that results in the same compensation ?
And how to you prevent someone from just creating a piece of software, keeping it to themselves, and then charging others if they want a private copy of it ? Are you going to demand that software developers release their code to the public, and enforce that through the state ?
What about live performances ? Are you going to mandate that performers invoice each person in attendance for their time ?
I need to ask you an honest question: have you every run your own business ?
If not, you should try it, it's a really eye-opening experience that will give you really valuable insight into the world that we live in. The one thing that you will learn is that we are all creatures of the environment we operate in, and very few of us actually have economic/political power that extends very far, so one should always be very careful about ascribing ulterior motives to other people. Most of the time, people just want to make a decent amount of money so that they can have a nice life with their families.
We do have ways of self-publishing or paying creators directly: the internet. Anyone can pop up a web site and start selling their wares with minimal fuss. It costs a couple of thousand bucks to set up an internet-based company in the US, with the majority of the money going to incorporation. Payment processing services, payroll services, tax/accounting services, hosting services, etc. are all super-cheap and don't require a lot of work.
Sometimes I have to stop myself from constantly grumbling "kids these days...", but wow, I'm seeing a lot of young people erecting mental barriers to acting on their dreams and aspirations. It's never been easier to make money in this country, but you have to a) put in the hours, b) stop giving away your stuff for free, and c) manage your expectations - nobody is saying that you're going to win the lottery by becoming the next Google or FB.
Yes, I would like someone here to provide an answer to this question.
For example: We're just wrapping up a new release of one of our products that I've been working on since August of 2017. It has over 1400 hours of work dedicated to it (single developer - myself). There's no way that we could possibly dedicate that amount of time to a software project without knowing that we could recoup the costs.
I don't think this book has been completely written yet. I think we're just now starting to see some of the major issues with FOSS, so don't throw up that "Mission Accomplished" banner yet.
FOSS is very much like the internet, in general: it was great when it was a small group of technical, like-minded, dedicated individuals working towards common goals. It starts falling apart, however, once you introduce the rest of the world into the system because the world primarily works on the basis of ruthless self-interest.
Absolutely - adding money doesn't automatically result in trustworthiness. What it does do, however, is make the transaction fall under legal commerce, which gives the purchaser/user rights and remedies that they do not have with free (as in cost) software.
With foundations or any other form of over-arching bureaucracy, you risk stultifying software developers and harming innovation. It's really, really hard to beat the self-organizing aspects of free markets combined with commercial legal frameworks.
No, I think what people are implying is that commercial licensing of software solves the trust/responsibility aspect of software. With proprietary software, there are legal remedies to malfeasance.
1) The PC software world did run for quite a few years on the model of predominantly commercial/proprietary software, most of it being closed-source, so it's not like it is some far-fetched idea that doesn't work in economic terms.
Personally, I prefer the commercial license/source-included model, with the emphasis on the author/company getting paid to ensure that the situations like the one described here are avoided. You can then have additional educational licenses for ensuring access to developer tools for educational purposes, but that's up to the author/company.
2) If you directly pay someone to write software, I would expect any such arrangement to include the source code as part of the work product, regardless of the ultimate visibility of the source code to outside parties.
When you have products and systems that have been around for a decade or more, major portions of them become outdated and need to be rewritten (or largely rewritten, the two are synonymous to me). Best practices in crypto change, operating systems and hardware improve/change, etc., and if you want to keep generating value, you had better change along with it. You can see where organizations don't do this: the developers force weird constraints on IT like needing to use old, obsolete versions of operating systems because the software won't run on newer versions.
Along these lines, one of the problems that I think exists with the software industry today is an inability among developers to recognize that software sticks around a lot longer than one might originally envision. And this phenomenon only gets worse (better, for the end user) as the value provided by the software increases. It's a bit of a Faustian bargain: everyone wants their software to be used and provide value, but often don't realize the "soft commitments" being made in the background that can tie you (or the business) to the code for years (or decades).