serichsen

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.

“I've seen things you people wouldn't believe…”

> XML is just s-exprs

No. That myth has been decisively addressed by Erik Naggum about 12 years ago. His summary:

> They are not identical. The aspects you are willing to ignore are > more important than the aspects you are willing to accept. Robbery > is not just another way of making a living, rape is not just another > way of satisfying basic human needs, torture is not just another way > of interrogation. And XML is not just another way of writing S-exps. > There are some things in life that you do not do if you want to be a > moral being and feel proud of what you have accomplished.

Please read his posting/rant for the arguments. Dude. (I'll just tell you to search for "naggum xml", there are more than enough copies in circulation, and you'll find a few more postings by other people.)

Now, as for XSLT: The big problem is the hairy syntax. It is really (at least) two languages (the XML tags, and the query language that is used inside selectors). In effect, you are writing at least three languages completely intermixed in a single file: the output language (most often some XML or HTML variant), the XSLT tag language (another XML format), and the XSLT query language (an incredibly limited ad hoc micro-language inside some XML attributes).

XSLT is a very limited language, as opposed to Lisp macros, which can use the entire Lisp language.

And yes, I have used XSLT in my job, and I do have reason to think that the XSLT-stylesheets I wrote have an acceptable quality. However, I know that I could have done their job better if I could have used some structured data, an HTML formatter, and a real programming language.

Huh?

Meh. This is not "ahead of the curve" but just the mainstream, maybe a little behind.

12. No! That is not a good shuffle. Search for "javascript shuffle" to find a correct Fisher-Yates implementation.

I would never use a spreadsheet for basing decisions on. It is just too error prone. I do not know how many trillions of euros (and dollars) have been wasted due to some excel sheets having off-by-one errors in marking rows or similar issues.

That is perhaps an excuse for people whose lips move when they are reading.

It seems that the uncertainty is much higher at the end of the blue curve. I wonder why.

It also seems that the red curve has no uncertainty data.

I would not dare draw any conclusion from these curves before I have satisfying explanations for these two questions.

No amount of abstraction will save you from finally having to determine how to represent the end result. That is totally orthogonal to the ability to delay the accumulation of something to be represented that way (which is just one strategy to achieve efficiency for this case anyway).

    s = []
    for x in range(100):
        s = s.append(x)
    format s

In other words, this is something that holds just the same for vectors of any type.

The "philosophical" "argument" is really not relevant, since the difference between characters and "symbols" seems to be just what you want (whatever that is), while words and sentences can be represented by strings themselves. This is just a tangent that adds nothing to the question of how to represent a string.