serichsen's comments

Integer division: I think the best thing to do is to produce an exact rational, like Clojure that was mentioned, and most Lisps, where it got that from.

Lisps do NOT do textual inclusion. Lisp systems are created from code, not text.

I guess that the author only saw the use of `use-package' or the `:use' option of `defpackage', but this is not necessary (and not generally used) to refer to other namespaces.

The actual use of `defpackage' is often quite close to how Clojure does it.

The sport here seems to be which compiler manages to re-write the bad code best.

Tail call optimization is only marginally relevant here, since the tail call is the addition, not one of the recursions.

- Technical decisions from non-technical people (especially management and politics)

- False commitment to up-front design decisions, even in the face of absurdities and architectural violations

- Inability to throw away code

- Overengineering

- Underengineering

From my german perspective, every assumption in this article looks quite gross and barbaric.

Here, everyone is insured. If you break your arm, you get it fixed. If you get cancer, you get therapy. If you get the flu, you get a prescription. The overall cost is paid by the entire population, through the insurance system.

For what is the alternative? Maybe the overall monetary cost would be lower if everyone had to watch the price, but you would pay for it in human lives and suffering, when people have to decide between dying of illness or dying of hunger, or between lifelong pain or clothes for their children.

Given the choice, I would.

The Fisher-Yates shuffle has an off-by-one.

Lisp's problem is rather that so many people play around with it, but not long enough to develop /good taste/ in it, and finally loudly complain about the language when their real problem is their lack of imagination.

You discovered structs, but you should not have stopped there. Structs can be configured. You can declare boa constructors (yes, really, By Order of Arguments). You can configure the names of the accessors. You might even create a little reader macro for creating them. You might want to write a little with-3dvecs macro for quick destructuring. When structs do not have everything you need, maybe go to CLOS classes.

In Python, “there is only one way to do it”. In Perl, “there is more than one way to do it”. In Lisp, there are thousands of ways to do it. If you haven't found a good one for your problem yet, keep looking. I promise, there is at least one.

By the way, you also have no idea of Clojure, but I have only been using it for a few years, so I feel not confident to give meaningful hints.

Common Lisp has “first” and “rest” as aliases for “car” and “cdr” where it makes sense.

Valid points, but not _the_ point. There is a big difference between allowing and supporting something.

OO languages _support_ hidden inputs and outputs as well as programming by mutation. They _allow_ programming in a functional style, but you will have to be inventive for it.

FP languages _support_ immutable values, referential transparency and all that. They _allow_ programming by mutation and hidden inputs and outputs, but you will have to be (sometimes very) inventive for it.

There seems to be a problem with ko: it alerts that retaking is forbidden even though the board has changed. Afterwards, play seems to be ended.

I am not on that mailing list, but I'd like to point out Emacs Lisp, which doesn't have modules (they would rather be called "packages" as in Common Lisp, but anyway, they just are not there).

Instead, the idiom has emerged to prefix every function name with its "package name". I'd take a deep look at the discussions in the Emacs Lisp community, in order to see the matter from the other side.

I see two problems with the basic idea of JSX:

- Parsing is a mess, it is not even obviously unambiguous.

- HTML syntax is horrible, and all templating language attempts building on it are verbose and clumsy.

That is the negative argument (“That is crap”), but there is also a positive argument (“Here is a much better alternative”):

You can express HTML structure in a concise and relatively readable manner in plain JavaScript, and you do not need a 400 kb interpreter nor a separate compilation step for it!

    ['div', {'class': 'foo'},
      'some text',
      ['span', {}, 'yay']]

You also can embed "directives" or "components" in a rather obvious and unambiguous way:

    ['div', {'class': 'container'},
      [MyConstructor, {'arg': foo()}]]

Implementing a robust interpreter for this is a matter of perhaps 50 to 100 lines of plain JavaScript.

OK, so who manages the keys, and how?

I am aware of only two general principles to do this: centralized certificate authorities (possibly chained), and decentralized assurance, a. k. a. web of trust. Their advantages and drawbacks seem pretty clear by now.

So, which is it, and if a CA (which I'd assume), who has the keys and how is crytographic trust obtained?

It seems OK, but it would have been better if it was made by someone with more familiarity and experience with the language.

The question is about defaults. Current default of C and C++ is to cut all corners wherever it is not clearly impossible (sometimes even then). That is the insanity.

Of course you should optimize wherever sensible.

> When those systems aren't well thought out or secure you have security issues.

All evidence says that there are no well thought out and secure systems written in C or C++.

If there is a way to do it, it has not been publicized yet.

Yeah! Or COBOL! PHP! INTERCAL!

> Until very recently, this situation would not have occurred.

Until very recently, people didn't even have smartphones that could have been suspected to contain useful information.

> Apple and Google […] could no longer unlock their own products as a result.

It is not "their own product". It is the customer's. He has bought it.

The rest of the article is based on these false assumptions.

COBOL will never die, either.