ericsink

Interesting. I left Spyglass in January 1997, just as they were heading in that general direction.

I don't remember anything about "Microsoft Mosaic" as a name, but we definitely retained the right for Spyglass to sell our own browsers.

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.

Based on my understanding, some of the details he gave about the Spyglass/Microsoft situation are not quite right, but I don't think it would appropriate for me to provide specific corrections.

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.

Shameless self-promotion:

https://wordmax.game

Released for public preview just today.

Game play similar to Scrabble, but played "duplicate" style.

Admittedly not exactly "quick low-stakes".

I too miss discriminated unions in C#.

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
  };

(Author here)

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.

None of those are working yet. I'm hoping to get things going with MAUI.

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.

(Author here)

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.

Indeed. I've been using the .NET 8 previews with Native AOT on an M1 Mac for several weeks, and things work quite nicely.

I like the warnings about style and naming conventions. I kinda wish there were more of them. These warnings can help teams avoid arguments about things that don't really matter very much.

Note also that the Meteor project has "minimongo", which is yet another implementation of the MongoDB query language.

FWIW, I've recently been implementing the MongoDB query language as well:

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.

I think maybe the most interesting open source companies today are Couchbase and Mongo.

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.

And, er, nevermind that comment. It's redundant.

Lesson learned: Don't comment until you RTFA, even if you wrote TFA.

The original business for Spyglass was scientific visualization tools. When we did our "pivot" into web browsers, the company name stayed the same.

The science tools were sold to Brand Fortner, one of the original founders.

I should have chosen law as my example. No matter what I chose, it would be wrong, but picking on lawyers is more fashionable.

I like to think that by expressing my opinion and labeling it as such, I am meeting the [very low] expectations set by a blog entry at a URL with my name in it. :-)

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

Er, yeah, time is linear, but I don't think the distribution of runners is.

I bet there's a bell curve there, and Usain Bolt is WAY, WAY off on the right part of the curve.

Indeed. If software truly mirrors sports in this regard, we might want to think of elites as a once-per-generation thing.

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.

One of the commenters over on reddit gave an example of the kind of person who might be considered an elite accountant.

IIRC this was beaten later by Steven Gordon's GADDAG algorithm.

Edit: yep. Fixed name. Here's the Wikipedia link:

http://en.m.wikipedia.org/wiki/GADDAG

Fair point. There will still be some very, very large scale problems in the B2B wave.

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

Yeah, I'm saying that this is one of the issues that brought the popularity of nosql databases. Constraints are expensive, and you can gain performance (while accepting greater risk) if you remove them.

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.

Well, I'm guessing Foxconn is the biggest by some measure. ;-)

Exactly. And very well said.

"Apple could have zero growth and remain highly profitable for years."

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.

Part of me agrees with you and wants to rant about it at length.

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.

Sorry if the article is unclear. My intent was to clearly communicate that the problem can happen with any two instances, not necessarily of different versions. Like the nutshell summary at the top says.

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.

(a) Yes, the author (me) does forget to mention that. Oops.

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

No offense intended, but that's not correct. :-(

You can get this problem with two instances of the same version of SQLite (accessing the same file at the same time).