Emacs is a bunch older than common lisp.

One of its more idiosyncratic design decisions was using dynamic scope, rather than lexical scope. They did add in per-file lexical scope, though.

It also just doesn’t implement a lot of common lisp’s standard library.

Emacs unfortunately uses Emacs lisp, not common lisp or scheme.

One important thing to realize is that different dialects of English have slightly different grammars.

One place where different dialects differ is around negation. Some dialects, like Appalachian English or West Texas English, exhibit ‘negative concord’, where parts of a sentence must agree in negation. For example, “Nobody ain’t doin’ nothing’ wrong”.

One of the most important thing to understanding a sentence is to figure out the dialect of its speaker. You’ll also notice that with sentences with ambiguous terminology like “he ate biscuits” - were they cookies, or something that looked like a scone? Rules are always contextual, based on the variety of the language being spoken.

English definitely has rules.

It’s why you can’t say something like “girl the will boy the paid” to mean “the boy is paying the girl” and have people understand you.

Less vs fewer, though, isn’t really a rule. It’s more an 18th century style guideline some people took too seriously.

No.

There’s two types of grammar rules. There’s the real grammar rules, which you intuitively learn as a kid and don’t have to be explicitly taught.

For example, any native English speaker can tell you that there’s something off about “the iron great purple old big ball” and that it should really be “the great big old purple iron ball”, even though many aren’t even aware that English has an adjective precedence rule.

Then there’s the fake rules like “ain’t ain’t a real word”, ‘don’t split infinitives’ or “no double negatives”. Those ones are trumped up preferences, often with a classist or racist origin.

Right.

As described, for you to get two books, someone else got zero. For you to get three books, two people got zero.

The median person gets zero books. A few lucky people get 2-36 books.

Edit:

She gives one book to her upline. She then sends out post to 36 more people to give her 36 books. Each one of them then needs to find 36 people each, which is now 1296 people in that level if they each want 36 books. Thus the exponential pyramid.

If sounds like the book goes to your upline, and you only get as many books as you recruit people.

If everyone is putting in one book, for you to get 36 books, 35 other people have to get 0 books.

Prescriptivism is mostly just an unprincipled mishmash of shibboleths someone pulled out of their rear end hundreds of years ago, classism, and knee-jerk reactions against language change.

For example - why do people distinguish less vs fewer to refer to countable vs uncountable nouns? Because someone wrote in 1770 that they thought that distinction was elegant, despite not actually reflecting the way English at the time was spoken.

Why is ain’t “not a word”? Because it originated in the speech of poor people, and was used less commonly by rich people. People roll their eyes at new business-speak because it comes from rich, powerful people, but look down their nose at language innovations from poor hillbillies and other disfavored groups.

And you can find writings from old prescriptivists complaining about literally every change in the language, such as hating the new ambigious use of singular ‘you’ when ‘thou’ was perfectly good and unambiguous or hating phrases like ‘very pleased’.

The fact that they have it on this blatant of a propaganda poster means that unions work.

Not necessarily.

A poster this blatant means unions are bad for management.

It doesn’t prove that unions aren’t bad for both workers and management alike. Business isn’t a zero sum game. To show that something helps workers, you need to demonstrate that it helps workers.

Which is to say, this poster is a bad argument for unions. The success of the writers strike, on the other hand, is a good argument of how unions protect workers from the bad deals management offers.

Being a much better language than Java isn’t exactly a high bar.

Basic stuff like maps aren’t easy to implement either.

This is mostly due to a preference for immutable data structures. That said, the standard library has a balanced tree-based map that’s not too complex.

If you want a good immutable data structure with O(1) find and update, you’re unfortunately looking at something like a hash array mapped trie, but that’s the same in e.g. clojure or Scala.

Haskell started out as an academic language.

The problem Haskell was trying to solve was that in the late 80s, there was a bunch of interest in lazy functional programming but all the research groups had to write their own lazy language before writing a paper on whatever new feature they were interested in. So they banded together to create Haskell as a common research program that they could collectively use.

It’s been remarkably successful for a research language, and has become more practical over the years in many ways. But it’s always had the motto “avoid (success at all costs)”.

There’s a bunch of companies that use Haskell.

Off the top of my head, Mercury is an online bank built on Haskell, Tsuru capitol is a hedge fund built on it, Standard Chartered bank has a big Haskell team in Singapore, and Facebook’s automated rule-based spam detection software is built in Haskell.

There’s also cardano, in the crypto space.

And various other companies might have a project or two written in Haskell by a small team.

From his blog post:

While you may compile dialects into it, you still have to accept the fact that running code in the browser means running JavaScript. So being able to write that, free of any tooling, and free of any strong typing, is a blessing under the circumstances.

By his logic, JS linters are bad because they’re tooling that restricts your access to all of Javascript. But linters mean you don’t have to read PRs with a fine tooth comb to make sure there’s no footguns like using == instead of ===.

Also, you could use that same logic to advocate for writing JVM bytecode directly instead of Java/Kotlin/Scala/Clojure/etc.

The question is really whether tooling pays its way in terms of lower bug rates, code that’s easier for coworkers to read, and code that’s easier to reason about.