lisa_henderson

> Store of Value: Bitcoin is better than gold at what gold does. Gold is about $7tn. BTC ~$180bn

I don't know many women who feel this way, and women's interest in jewelry has historically helped establish an important floor for the value of gold. If civilization collapsed tomorrow women would work hard to protect their gold, but not their Bitcoin (or similar). But of course , it doesn't require societal collapse to put downward pressure on Bitcoin.

Wait, is this Kyle Kingsbury? If so, where is his name? Who are the authors? I notice this text doesn't mention the authors:

"We wish to thank Jordan Halterman for his discussion of Hazelcast use cases. Luigi Dell’Aquila & Luca Garulli from OrientDB, and Denis Sukhoroslov from BagriDB, were instrumental in understanding those systems’ use of Hazelcast. Thanks also to Julia Evans, Sarah Huffman, Camille Fournier, Moishe Lettvin, Tim Kordas, André Arko, Allison Kaptur, Coda Hale, and Peter Alvaro for reading and offering comments on initial drafts. This research was performed independently by Jepsen, without compensation, and conducted in accordance with the Jepsen ethics policy."

I'd like to know who stands behind this research

Your first 2 examples are good, but "bespoke" is older and often more specific than "custom".

Or questions that are original but get marked as duplicate. This has happened to me several times. It's become my biggest frustration with StackOverflow. I might run into a problem that is a new variation on an old problem. I try to document it carefully, and I often link to old questions on StackOverflow so that people will realize that I've done my research, and my current problem is not the same as the older problem. But still, the moderators on StackOverflow don't always take the time to read all the way through a post. They seem to just read the first sentence or two and decide that the question is a repeat of an older question. I've been shocked at how aggressive they can be about marking a question as a duplicate.

pervycreeper is making the point that all computers are, for practical purposes, probabilistic, since you can never know if a given result is because of a machine failure. In the normal sense of a math proof, one can not "exhaust the problem space" using a computer. Using a computer remains an empirical approach, since there is always the chance that the computer is malfunctioning.

Great teachers are expensive. This needs to be emphasized more. Even if there is strong demand for the dev bootcamps, the bootcamps still have to hire great teachers. The teachers are highly experienced developers, the kind of people who could be making something between $120,000 to $160,000. So the schools face some very high expenses.

A comparison might be made to retail. Sometimes you'll see a store that is very busy, full of customers, and then it goes out of business. Why did it fail when it was so busy? Often the reason is that the landlord raised the rent.

High costs can kill an otherwise good business idea.

This article misses what seems like the most obvious explanation, which is that the USA economy has recovered from the Great Recession. We had a stretch from 2009 to 2014 when it was difficult to find any normal investment that paid better than 1% or 2% a year. Seeking yield, money poured into startups, because they seemed like the only thing that might be able to offer better than 20% returns (assuming a basket of startups, most of which fail and some of which return 100x).

Since 2015, the economy has returned to almost normal, so the need to invest in software startups is reduced. And this would most likely effect San Francisco the most, since it had received the most investment during the era 2009-2014.

Now that the economy is almost back to normal, there are a lot of areas in the economy that offer possible returns. The need to focus on software startups is diminished.

You have it backwards. The plague starts in east Asia, then spreads West along the Silk Road, it arrives at the Black Sea, and then is carried to Venice. Most likely it was in rats that were on the ships which the merchants of Venice operated in the Black Sea. It arrives in Venice in 1347, and the next 36 months are the event that in the West is called The Black Death.

I got started in software in the late 90s. At that time, there were immense philosophical differences between the communities that drove each programming language. Perl had a well known culture, which was utterly different than what the Python folks were doing. The people around Java were excited about the thought of building the ultimate enterprise language, and there was talk of some day automating UML schemas so that projects would only need architects, not actual coders -- an idea utterly foreign to the Python crowd. Ruby's culture was shaped by Matz, who said that programmers should experience joy while working. PHP rejected all the hype about Object Oriented Programming, instead, PHP was for people who wanted to write programs using a collection of functions, with an emphasis on quick and dirty projects -- and in an era when there were no package managers, PHP's "all in one" philosophy was a real blessing. A huge amount of code was included in the default install of PHP. And C programming was a different beast depending on whether you were focused on Unix machines, or Windows, or Macs.

The idea of Open Source was still in its early days, and only Perl had a great central library of code that was free for anyone to use.

And of all these languages, most were hot with a fanatic idealism about how Object Oriented Programming would solve the problems of the tech industry. Those languages that rejected Object Oriented Programming (Python and PHP, and also, to a lesser extent, Perl) were proud of their defiance, till the moment (a few years later) when they gave in and decided to become Object Oriented.

There has been a convergence of culture. Nowadays most programming languages have all of the same things:

1.) package managers to manage your dependencies

2.) frameworks with command line tools to automate setup and database migrations

3.) multi paradigm -- most languages now facilitate Object Oriented Programming, but also Logic programming and Functional programming and pattern matching, and other paradigms.

4.) open source libraries of code for everything, typically on Github

Nowadays I can go from writing in Python to writing in Javascript, and most of the stuff I expect is exactly the same in both languages. I can think these words about practically any language that I am asked to work with: "Oh, I have to write a module to send email to new users? Okay, let me look up the open source libraries that handle email. There are probably a dozen projects on Github"

There is much more of a mainstream to computer programming than their used to be. This "normalization" happened first with software for the Internet, though lately its even been spreading to hardware projects. A few languages (Clojure, Haskell) still have strong philosophical differences from the mainstream, but they offer the common basics, like any languages that nowadays wants to make a programmer feel productive.

So these lists of skills are less meaningful than they used to be. Once upon a time it would take months to give up one language and learn a new one, whereas nowadays the switch is easier, since so many assumptions that are true in one language remain true when you switch to a different language.

Last year I worked at an electronic publishing firm which had wasted $3 million and 5 years on a Ruby On Rails application which was universally hated by the staff, and which we replaced with 6 clean, separate services. The problem with the Ruby On Rails app is that it was trying to be everything to everyone, which is a common problem for monoliths in corporate environments. But the needs of the marketing department were very different from the needs of the publishing department. A request for a new feature would come in from the blogging/content division which would be added to the Ruby On Rails app, even though it slowed the app down for everyone else.

Six separate services allowed multiple benefits:

1.) each service was smaller and faster

2.) each service was focused on the real needs of its users

3.) each service was free to evolve without harming the people who did not use the service

There was some duplication of code, which suggests a process that is the exact opposite of "Monolith First":

Start with separate services for each group of users, then later look to combine redundant code into some shared libraries.