TimJYoung

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.

I've been trying to tell this to people for years:

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.

Object Pascal (Delphi) also optimizes case statements, depending upon the nature of the statement:

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.

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:

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

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

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.

Which is fine, but don't be surprised if the majority of the people choose to do other things and not produce the very thing that you want produced.

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

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.

That is a fantastic read, thank you. It's amazing how many structures and institutions have evolved from that simple concept.

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.

Two things:

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.

Of course it was constructed. Aliens didn't just drop it from the heavens - the US specifically released the internet to the public and commercial interests, whereas previously it was limited to academic interests. Once commerce was up and running on the internet, it was simply a matter of companies getting big quickly and inserting themselves as middlemen between customers and producers/distributors. The fact that most of these companies eschewed profits for many, many years in favor of growth makes it self-evident that they understood that capturing the majority of the network (winner-take-all) was the primary goal.

Not just house - Wax Trax! Records was very much responsible for exposing quite a few people to industrial music in the 80s, also:

https://en.wikipedia.org/wiki/Wax_Trax!_Records

Chicago often doesn't get the cultural recognition that it deserves. My wife and I love it there, and visit as often as possible.

That title is pretty misleading. The breakage is being reported as being in the default program file associations (Default Programs under Control Panel/Settings):

https://support.microsoft.com/en-us/help/4028161/windows-10-...

Because the caller either deals with the error (and fixes the state) or they don't, but there's never a case where the callee was unable to force the caller to fix the state. If the caller then goes on to just handle/suppress the exception and continue with the invalid state, then at least they're making an explicit decision that is on them.

It does if they don't handle the exception, which is the situation being described.

"Your whole reply is a straw man. The author is claiming that nothing explodes b/c the error is correctly handled, not b/c it was silently swallowed."

Yes, but I think that this is exactly what pilif is objecting to: the fact that there is no way for the callee to force the caller to deal with the error condition (I'm not sure that this is entirely correct, given that Go has the panic/recover keywords that are later discussed in the article, but then you might as well use exceptions).

IMO, this is very similar to what happens with use-after-free and other types of memory reference errors: they are extremely hard to debug because the symptoms/results of the error can be totally disconnected from the original source of the error, in some cases by minutes or longer. You simply don't want to have a situation where improper state is allowed to linger and further pollute/corrupt any subsequent computations.

Most companies do not want to deal with the hassle of finding someone to perform support/bug fix work on their software. They want to be able to call up a vendor and get an answer today about a bug fix or support. Most open source projects do not have this level of support.

Linux "won" in the sense that every single one of those devices is special-purpose, and not for general-purpose computing. Linux is helping those that want to lock down computing so that it is consumption-only, which is completely antithetical to the goals of FOSS. Creation happens on the desktop, and right now the desktop is primarily Windows and Mac.

That's not quite true. You can easily decompile any binary and glean all sorts of valuable information from it. On Windows you can find out which API calls it makes and can even use detours/trampolines to redirect such calls:

https://github.com/Microsoft/Detours/wiki/Using-Detours

At one point I wrote a little piece of software as a proof of concept that used detours to redirect any file I/O in IE that was deemed "unsafe" to a special in-memory file system.

The bottom line is that you don't need the source code in order tell if an application is "phoning home" or if it makes suspicious API calls. In fact, it is often easier to just simply monitor how the software interacts with the host system to determine if it is performing (possibly) malicious actions. IOW, if you're concerned about a certain piece of software, then auditing the source code isn't going to be as good of a solution as just sandboxing the application so that it's impossible for the application to do something bad.

Nobody is going to use software for anything critical that doesn't have someone "waiting around" to fix any bugs that appear, even if they are several years down the line from the original release (and yes, this happens a lot). So, what you call "rent" is, in actuality, the cost of keeping the lights on and the original developers around so that such long-term support can be provided. And yes, these same developers can and do provide new features (which can also introduce new bugs, thus restarting the clock) during that same time.

This isn't to say that software companies don't exist that just milk the hell out of their customer base. But, that's a problem with any industry, not just software, and is an economic phenomenon, not something intrinsically bad about proprietary software. Typically, it's a problem with a lack of competition and the ability of incumbents to erect artificial barriers to such competition.