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 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.

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.

https://news.ycombinator.com/item?id=14804175

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.

https://stackoverflow.com/a/2548425

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.

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.

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.

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:

https://www.bizjournals.com/buffalo/news/2015/06/28/oldhomes...

I think our house could easily go another 100 years with the proper maintenance.

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 ?

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.

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.

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.

Jaron Lanier talks about this a lot in his books and speaking engagements, and I would highly recommend his books for a better perspective.

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.

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.

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.