bos

It starts in the very first paragraph. “The headlines say yes. […] The headline is wrong.”

And there are numerous such examples. “That was half true. The kill chain ran. The interceptor did not.”

LLMs produce staccato, ugly chains of sentence stumps like this all the time. They’re easy to spot, and your essay is littered with them.

If anything, spending a week on a project like this seems liable to blind you to the shortcomings of the prose, because after putting in a lot of effort you can’t read it with fresh eyes. That’s what editors are for, but an LLM is by nature very weak at editing LLM-generated text.

I want to be able to offer constructive feedback on the structure of the overall essay, for example that the interspersed animated/interactive models often don’t seem strongly connected to the text, but simply reading the words makes this a grind.

This is an exhausting and dispiriting article to try to read because of its short, choppy, clearly AI-generated sentences. The topic is interesting, but whoever caused it to be penned didn’t seem to care enough to make it appealing to read.

Your backstory is complete nonsense.

Liberty Utilities has nothing to do with libertarian separatists. It's a brand name of Algonquin Power & Utilities Corp, a boring Canadian infrastructure conglomerate that buys regulated water, gas, and electric systems across North America. They bought this chunk of rural California grid from NV Energy in 2009. That's it.

This is sort of a revival and elaboration of some of Bram’s ideas from Codeville, an earlier effort that dates back to the early 2000s Cambrian explosion of DVCS.

Codeville also used a weave for storage and merge, a concept that originated with SCCS (and thence into Teamware and BitKeeper).

Codeville predates the introduction of CRDTs by almost a decade, and at least on the face of it the two concepts seem like a natural fit.

It was always kind of difficult to argue that weaves produced unambiguously better merge results (and more limited conflicts) than the more heuristically driven approaches of git, Mercurial, et al, because the edit histories required to produce test cases were difficult (at least for me) to reason about.

I like that Bram hasn’t let go of the problem, and is still trying out new ideas in the space.

Really nice to see a solidly valuable project develop a sustainable foundation instead of turning into yet another VC-backed devtools startup that will inevitably die in a few years.

This is a bizarre essay by someone who understands neither functional programming nor the history of computers.

To be kind, we’ve spent several decades twisting hardware to make the FP spherical cow work “faster”, at the expense of exponential growth in memory usage, and, some would argue, at the expense of increased fragility of software.

There is not one iota of support for functional programming in any modern CPU.

Should say "(2018)".

No, this isn’t a good description of monads. It merely describes a case that shows up sometimes.

The wreck is actually from a 1986 crash that saw no fatalities.

https://www.facebook.com/199535516767620/posts/4006006656120...

Yes, and in fact this can even be done incrementally and efficiently these days.

One example is the open source tool Infer, which we run on very large bodies of native and Java code at Facebook. http://fbinfer.com

Let me put Mike's comment into what I think is its proper context. "Poor support for numerical computing" really means "relative to Mike's dream, which is not actually realisable by any programming language today" :-)

Most readers seem to be misinterpreting Mike as anchoring off other popular programming languages of today, whereas he's looking for language features for which there's (a) no consensus that they'll actually be good when they exist, and (b) don't yet exist. (I'm highly skeptical of dependently typed programming.)

I think that there's a case to be made that numeric programming in Haskell, relative to the state of the art of today rather than the year 2100, really isn't so great – but my concerns are very different than Mike's, and revolve around libraries rather than type system features.

Source: have done a bit of Haskell in my day.

Facebook has large engineering offices in New York, Seattle, London, and Tel Aviv, and smaller presences in Boston and Dublin.

There's also a vast range of engineering projects, from VR through video, mobile apps, machine learning, compilers and programming languages, operating systems, on to data centers.

There have been numerous well-known problems with the Java and Python standard libraries over the years. For instance, the date/time classes in Java were a disaster for a long time, and Python has taken decades to converge on a nearly-good-enough treatment of strings.

A small correction: GHC uses plenty of type tagging information. In fact, its metadata overhead is relatively high.

I think of programming in Haskell as being more about being able to choose a level of abstraction that makes sense for the situation.

The more abstract code is great when it works well, and when it falters I can easily drop down to something more concrete, or even to C, and still have most of my code benefit from that higher level of thinking.

In fact, it turns out the Pusher protocol is all JSON, so you can autogenerate the code.

Here's a Pusher message.

  {
    "event": "pusher:error",
    "data": {
      "message": String,
      "code": Integer
    }
  }

  {-# LANGUAGE DeriveGeneric #-}

  import GHC.Generics

  -- a generic wrapper type for all Pusher events
  data Event a = Event {
      eventType :: Text,
      eventData :: a
    } deriving (Generic)

  instance ToJSON a   => ToJSON (Event a)
  instance FromJSON a => FromJSON (Event a)


  data Error = Error {
      message :: Text,
      code :: Integer
    } deriving (Generic)

  instance ToJSON   Error
  instance FromJSON Error

I know nothing about the Pusher protocol, but the standard approach to boilerplate encoding/decoding problems these days is to use GHC.Generics.

It doesn't always fit (typically when your data structures don't resemble the wire encoding), but it kills all the boilerplate when it does.

Since you say that you can magically get away without boilerplate in Ruby in this case, I would expect that the Generics approach will give exactly the same result.

Right there on the front page: "We are also working on an Android implementation which we will release later."

Modern pans are cast in sand because it's cheap. The manufacturing method changed about 60 years ago from a more precise mould (that happened to cost more, but gave a smoother finish).

Nope, I pushed the release this morning once I realised that someone had actually noticed the post during the five minutes it was live at 1am.

The sweet spot that Hack hits is that it combines gradual typing (an idea that hasn't yet seen much real-world adoption) with an incredibly fast typechecker.

This lets you choose the pace and extent to which you want to adopt the safety of static typing, while preserving your dynamically typed code -- and without sacrificing the rapid turnaround of PHP.

That's a unique combination, in my experience.

I have a little bit by way of Haskell chops, and I'll venture that the performance of the Hack typechecker is a very big deal, and it is in a different breed than the turnaround time you get from snap or yesod (or Java).

It's more accurate to say that the point is to let you use dynamic typing where that makes sense, and static typing in the many cases where it helps. Hence "best of both".

As you note, the team developed the typechecker in OCaml, as that's what the founding engineers were familiar with. Many of ML's cousin languages happen to be well suited to this kind of work.

Because this is tremendously important to the usability of the language.

One of the reasons that PHP has been such a success is that you can simply save a source file and reload a web page to see what's going on.

The server-based typechecker that runs instantaneously is what makes it possible for Hack to replicate this experience: you save a file and reload a web page, but you have the safety net of a typechecker that told you about your type errors as soon as you saved the file.

I can't overstate how important this instant feedback is: it's really the thing that distinguishes Hack from working in a more traditional compile-based static language.

Oops! Thanks - we're fixing it now.

Yes, "<?hh // strict" at the top of a file will do the trick.

Yep, we're happy to be inspired by good ideas when they're obviously the right path to walk.

Yes, definitely.

100% of our web front end developers use Hack now. This has been an organic process of growth over the past year, by which I mean our engineers are using it because they like it and see value in it, not because there's someone standing over them with a big stick :-)

The biggest learning step for our engineering teams was to treat type errors from Hack as actual logic errors. We have a collection of "linters" that provide advice on code style and other nice-to-have factors. Some people (quite reasonably) initially thought of Hack errors as lint-like stuff that it was safe to ignore, when in fact they indicate real logical inconsistencies in code.