ericsink
In my recollection, the initial payment from Microsoft to Spyglass was higher than what Marc said, but I'm not sure.
But I am sure that the deal was later renegotiated at a substantially higher number.
I'm also pretty sure that even after that rework of the terms, Spyglass didn't get enough from Microsoft to compensate for the fact that Microsoft, er, you know, killed the browser business. And insofar as that is the essence of Marc's point, I agree with it.
However, since I was the Project Lead for the Spyglass browser team, there is one correction I can offer: We licensed the Mosaic code, but we never used any of it. Spyglass Mosaic was written from scratch.
In big picture terms, Marc's recollections look essentially correct, and he even shared a couple of credible-looking tidbits that I didn't know.
It was a crazy time. Netscape beat us, but I remember my boss observing that we beat everyone who didn't outspend us by a favor of five. I didn't get mega-rich or mega-famous like Marc (deservedly) did, but I learned a lot, and I remain thankful to have been involved in the story.
Released for public preview just today.
Game play similar to Scrabble, but played "duplicate" style.
Admittedly not exactly "quick low-stakes".
But even more often, I find myself wishing C# blocks were expressions.
In F#, I could do this:
let x =
let z = whatever
...
value
So in C#, I want to do:
var x =
{
var z = whatever;
...
value
};
Well this is a blast from the past.
Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown.
F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.
But I've made some progress with Avalonia.
Here's a sample using Native AOT and Avalonia, with a projection to Rust:
https://github.com/sourcegear/bridge-info/tree/main/samples/...
And here's (basically) the same sample projected to TypeScript:
https://github.com/sourcegear/bridge-info/tree/main/samples/...
These are built using the binding generator I mentioned elsewhere in the comments here. All this stuff is just raw tech, not a ready-to-use solution.
Most of the buzz about .NET Native AOT is focused on things like startup time for compiled executables in cloud environments. For good reason.
But Native AOT also supports compilation to libraries with a C ABI, including both shared libs and static. My blog series tends to lean in that direction, talking about interoperability.
Some of the posts talk about very fundamental things. Some of the later posts give mention to a (somewhat experimental) binding generator I've been working on, using CLR metadata to automatically create glue and projections for other languages like Rust and TypeScript.
In general, interop between C# and other languages has been possible for a long time, but Native AOT allows it to be done without hosting a CLR, and as the feature matures, I think that'll make it more interesting for some use cases.
https://github.com/zumero/Elmo
In F#. Not even remotely close to usable or production-ready.
The approach here is somewhat different, as this implementation is built on SQLite, which it treats as a simple key-value storage layer.
AFAICT, everything Couchbase does is Apache Licensed. An old-school traditionalist could look at them and conclude that they have no proprietary IP at all.
Mongo has perhaps a little more of a boundary because they use the AGPL (which will scare away more enterprise customers than the Apache license will). But still.
AFAIK, both of these firms are paying the significant costs of developing their own software. Neither of them can be characterized as building their business model on low dev costs from the use of community-developed code.
These firms have more funding than many open source firms get from an exit. Both of them seem to have significant and fast-growing revenue. Both of them seem to be on track to a successful IPO with reasonable expectations for continued growth thereafter.
Even in today's open source world, what these two companies are apparently doing seems kind of amazing.
Lesson learned: Don't comment until you RTFA, even if you wrote TFA.
The science tools were sold to Brand Fortner, one of the original founders.
The McConnell link would have been an interesting thing to include, but if I had done so, it would be looked something like this:
For the closest thing I can find to real evidence and research supporting the 10X programmer, start at this link to a piece by McConnell. But even there it is interesting to note that most of the scroll bar is consumed by comments from people debating the validity of the claims.
Even with the McConnell link and its contents, I would still find myself saying that I believe the elite developer exists but readily admit that I can't prove it.
If we could prove it, we wouldn't be arguing about it.
The 10X developer is to software as low-carb is to nutrition.
Hey, that last line is pithy! I'm gonna tweet that...
I bet there's a bell curve there, and Usain Bolt is WAY, WAY off on the right part of the curve.
But it is also interesting to consider the possibility that because we don't have a measuring system like sports, there is a Michael Jordan of software on the planet right now but nobody has ever heard of him/her.
Edit: yep. Fixed name. Here's the Wikipedia link:
If I weren't trying to keep the wording of my blog entry so tight, I would have more clearly distinguished the following three cases:
(1) B2B apps that do not challenge our notion of scale like the B2C wave did. (stuff that doesn't need something like Couchbase)
(2) B2B apps that are of similar scale to the B2C wave (stuff that does need something like Couchbase)
(3) B2B apps that challenge our notion of scale in a whole new way (stuff that will disrupt Couchbase)
I was trying to say that:
(a) There will be a lot of case (1)
(b) There will also be plenty of case (2)
(c) I'm not sure we will see any of case (3) in this wave. We're probably not going to see much NEW disruption that didn't already happen in the B2C wave. And that's part of why there won't be a lot of buzz.
-- E
But it's actually a little more complicated than I make it sound above. By removing things like unique constraints and foreign keys from the database layer, you also end up with a design that can much more easily scale out instead of up. Distributed database. Lots and lots of nodes. etc.
NoSQL databases have their place.
Traditional SQL databases do too.
Sure they could. But Wall Street would punish their stock price anyway.
Not everything about the way AAPL fluctuates is rational. Maybe NOTHING about it is rational. :-)
But the concerns about Apple's ability to sustain its ridiculous growth ARE quite real. Their growth IS slowing.
It is invariably true that developers who understand the full stack get along better. They know what's going on "under the hood". When they click a checkbox in the Visual Studio properties dialog, they understand what will happen at the MSBuild level, and how that translates to a difference in the command line invocation of the compiler, and what the compiler does differently because of that, and what it means in terms of interaction with the OS. It would drive them nuts to not understand this. So much so that they're probably only using Visual Studio instead of vim/cygwin/bash because somebody is forcing them to. :-)
OTOH, lots of developers let their tooling or platform do things for them that they don't understand. Those developers often struggle, especially during the latter stages of shipping a product. (I just wanted to not learn SQL! How was I supposed to know that NHibernate is so slow?!?)
But it is also true that expecting all developers to understand everything from their ORM down to the x86 microcode is neither realistic nor efficient. It's just not gonna happen.
But I also think that talking about different versions of SQLite is relevant, since dealing with those issues is one of the things that can lead an app developer toward the problem.
(b) Yes, it's true that there are plenty of uses cases which won't hit the problem. But for those that do, the consequences are pretty severe. And the distinction between those two classes of use cases is not obvious.
You can get this problem with two instances of the same version of SQLite (accessing the same file at the same time).