Writing about biology, finance, or geology? Shrug.

Dumb filtering is bad enough when used by smart people with good intent.

> Maybe they do actually donate to the project, contribute code, or support in other means.

Maybe instead of shaming, the question is a cue for them to mention one of those things.

---

In the US it's Thanskgiving week. It's nice to give thanks. It can also be nice to give other things -- like support to a project that has saved/made your company non-trivial money. Not required, but nice.

To be clear, I think it would be fair if they answer something like: "I am trying to get my company to contribute... but as my original story showed, my company is pretty shitty at making simple decisions." :)

In this case https://www.sec.gov/Archives/edgar/data/1653482/000162828021...

The income statement, balance sheet, and cash flow are connected; sides of a triangle.

Each of the three views alone is potentially misleading. But for an initial impression and quick gut check I like to start with cash flow.

On the third hand, I spent all that time, so wrt "bus factor 1", there will be no pleasing you. :)

- You are correct that implementing markdown consistently is hard because there is no real spec. CommonMark is a spec, which helps, but a heroically thorough spec, so it's still not exactly trivial to implement.

- You are correct that markdown can escape to HTML. Indeed certain marketing email "features" probably would do this?

If I am missing something maybe someone could make an actual contribution to the discussion and explain.

In any case I think by far the most important point was made elsewhere: Google AMP is awful for the web and for email, both.

p.s. edit: Actually, I think the even more important point is that anything except plain text email is awful. :) So there, sure, use markdown or org-mode formatting conventions. Humans are pretty good at handling messy human protocols.

Capitalization isn't a deep signal.

There are lIsPs like Clojure that argue (> data functions macros). Although I mostly disagree (for example I love Racket macros), I understand and appreciate the sentiment. I have heard it from other people who have worked with a variety of LiSp code bases over the years. TL;DR: Any form of non-trivial DSL needs supporting materials like documentation and a simple, clear design.

Although it is nice to be able to expand macros, fully-expanded macro-generating macros are clear in approximately the same way as assembly language. It is impressive if you can navigate that, but even more impressive if can manage not to need to do so.

Often there's substantial overlap between improving accessibility and helping "power users".

Sometimes that overlap can help convince managers to spend more time on these kinds of features.

(Unless maybe your whole model is herding people to ads or "promoted" stuff.)

Continuations are in the category of things best explained by burrito analogies.

It was magnitudes more effective than any marketing I've ever seen Google do. Ethics aside, you could argue that Lifehacker writers should have gotten Google CMO level stock grants.

On top of that, lately it seems more challenging not to be an oligopoly if you have customers in Europe and/or the US.

I suppose this represents an opportunity for startups to help other startups to manage compliance and payment.

This displays better in the AWS console -- and also it enables better queries than raw text, e.g. `{$.response.code >= 400}`.

Comments URL: https://news.ycombinator.com/item?id=17293742

Points: 1

# Comments: 0

What _can_ be slower is a _mix_ of TR and R. Because TR protects the boundary between the two with runtime contracts. Because it wants safety/soundness.

I'm not any kind of gradual typing expert, but, it seems like you could calibrate speed vs. soundness for boundaries in different ways. TR has prioritized soundness but it seems like you prefer speed.

It can also make sense if you like physical function keys and/or a touch screen larger than a function key row. :)

I used a Chromebook Pixel with Crouton very happily for a year. Granted I spend 95% of my time in Emacs and a web browser.