for the kids/newbs: effectively the (co)inventor of The Spreadsheet. and consider that spreadsheets were easily the killer app for the first PC's, thus giving them much more business value, in turn causing more money to flow in, helping to create many more paying jobs, etc, in a happy snowball effect which leads to Linux, Google, AWS...

here's where you might say, "sorry, different Bricklin." oops

an entire side discussion about Bayes predictions could be entered here. where having a few rough rules would yield a 90% beneficial prediction. add a 2nd rule or exception boosts your yield to 95%. add a 3rd rule/exception boosts your yield to 97%. and so on...

trust me, if you're smart and wise then the older you get you should be getting more and more reality-based in your decisions. not theory. not ideal. not PC. reality.

1. you are 20-something, white or Asian, fresh out of college, Jewish/Stanford/Ivy/otherwise-2nd-gen-pampered-background, male, maybe still in college or 1st startup AND you are willing to move anywhere they want, do anything they tell you, you have no spouse, no kids, no ill parents, no local geo investments, no major illnesses, not multi-careered, you're still impressed by Shiny/Words, etc.

2. you are 30/40-ish but now established as a Major Name (Linus, Vint, Guido, etc.) and/or owner of a company Google wants to buy, and therefore $M+ talks loudly

if you don't fit (approximately) into one of those two boxes, then Google is a non-ideal fit for you

META: downvote me all you want HN, I do not care what the GroupMind's Allowed Opinion algorithm here thinks anymore

MITM

Therefore when I awake it is always dark.

Problem. Mismatch.

Turns out that if I awake between the local hours of 5am and 7pm then it is light. Otherwise it is dark. Problem. Mismatch. Turns out, it depends on the "time zone". Also turns out, depends on whether I'm sleeping inside or outside. In a hotel room or tent. Whether in a tent or in a building room with blinds. Etc. Etc. Each devil-in-the-details helps refine the case even further. But the "bet" to make is always the most "correct" bet to make, based only on the evidence observed to date, at hand. Thus Bayes.

Thus the Turing award.

It's just as perfect and reliable as that. And just as imperfect or vulnerable as that.

One thing that struck me early is that while Bayes itself is rock solid, like arithmetic, when you go to apply it the results live or die on the quality of the models, and the relevance/realism of the evidence used to train them. GIGO.

But once you do have a good, relevant, signal-producing model, then, using it is a bit like doing a multi-dimensional lookup, or function call. Conceptually easy to understand, and, in many cases (depending, of course, on the details) cache-friendly.

please don't make a Bitcoin exchange/bank. or anything that will take enduser's private PII or money.

the mindset to "just go make something" is admirable in some cases. on others it's not. scratching your own itch and then monetizing it is admirable. picking up a knife and thinking therefore that one can be a neurosurgeon now, is not.

too many people do the latter. the former is fine. ;-)

But yes, seek the minimum amount of complexity to materialize the inherent, necessary complexity. But don't allow a drop of complexity more than that. Architecture astronauts, pattern fashionistas, I'm looking at you. KISS. Spend your complexity dollars where it gives you something you truly need or want. Don't do things Just Because.

But the elegant hacker in me? Prefers Lisp. And PG captured that in his writing.

I know that's too high level of a description. but what I'm saying is... that you always pay the price for poor quality, rushed work, whether you pay that price in an hour, tomorrow, next week, you always do, somebody does. so better to get quality right.

however, I see lots of astronaut architecture and too-much-abstraction -- especially in all-Java/enterprise shops -- where, I see folks spending lots of time on things which objectively don't have any business value and don't objectively increase quality (reduced failure rate, reduced bug rate, etc.) instead arguably seem to increase it, or increase the complexity and quantity of moving-parts which can fail or otherwise bite people later. Quality good, quantity bad.

Simple-but-perfect is better than bigger-but-shoddy.

-- the mid-90's Perl CGI scripts are calling and they're laughing at us all.

Google: Go

Microsoft: C#

Sun/Oracle: Java

almost all others: more on their own merits, from developers eyes (Python, Perl, C++, Ruby, Rust, D, Scala, LUA, JS, etc.)

a language should have innate merits, of course, but never discount the advantages of having a single corporate entity with lots of cash and focus and a built-in install base of eyes