Skeime

The rectangle case is just choose(w+h, h), with w, h being the width and height, respectively. (Or choose(w+h, w), which is the same.)

Depending on how well you know binomial coefficients, this can also lead you to the dynamic programming solution. After all, for the rectangle case this is nothing but construction of Pascal's triangle by summing two adjacent numbers in a row to get the number below them. If you recognize this, the solution for paths on grids with holes falls out almost immediately.

Lots of formatters also unify things like trailing commas, so it would be slightly more involved than this.

I feel like you are describing that the parser is too lenient rather than too picky. It could just require you to always put `let` and `in` on their own lines, in which case the indentation makes sense, I think. It's only when trying to keep more stuff on the same line that the details of Haskell's indentation rules come into play.

Isn't the Macintosh desktop (with Cmd as the modifier for standard shortcuts) older than Windows and Linux desktops? So historically, it's not Apple that deviated but the others?

(I did not do an extensive search into this, so there might be Ctrl-based standard shortcuts that predate Apple.)

I think modern browsers are actually quite good here. They show a template in the form TT.MM.JJJJ for me (so the German equivalent of MM/DD/YYYY, with the usual order and separator in German). I can just type the date, including the dots if I want (they're just ignored; there would be extra points for moving me to the next component when typing "2.", but the world's not perfect). If I'm confused about the format, or want to see a calendar view, I can click on the calendar icon (also accessible via tab) and select a date there.

For normal date inputs, I really don't think there is a good reason to use anything else. (Possible exceptions I can think of: Selecting date ranges and/or showing extra data about the dates (like daily prices).)

Mobile keyboards also do have the advantage that they can at least change the label of the button; so writing Submit on the Enter key if it submits.

I am also at the office almost every day because I think it's better for my mental health and food. But I also appreciate that for many, it's different, so actually having the choice individually is nice.

Wouldn't it also be much better to evaluate the Taylor polynomials using Horner's method, instead? (Maybe C++ can do this automatically, but given that there might be rounding differences, it probably won't.)

I wrote "predominant", not "official". And I think that is still true.

Also, from what I can tell using the site, it does not serve as a full dictionary. Rather, it lists the general rules of German orthography (as decided by the Rechtschreibrat) and has some limited tables of special words.

Fun fact: I looked this up in the online version of the Duden (the predominant German dictionary). It does have an entry "Black Hole" (so the English term!) but not for "schwarzes Loch", which is the normal German term for it.

(In the printed versions, you might need to go to the Universalwörterbuch or so to find the English entry, it might not be in the normal "Die deutsche Rechtschreibung"; I have not checked.)

I don't quite get what you mean here. While you need to allow infinite expansions without repeating patterns, you also need to expansions with these pattern to get all reals. Maybe the most difficult part is to explain why 0.(9) and 1 should be the same, though, while no such identification happens for repeating patterns that are not (9).

I think that's basically the same reason, right? XML itself is bloated if you use it as a format for data that is not marked-up text, so it comes with bloated APIs (which where pushed by Java/.NET proponents). I believe that if XML been kept to its intended purpose, it would be considered a relatively sane solution.

(But I don't have a source; I was just stating my impression/opinion.)

This article is weird. It wants to shoot against JSON, but then has to make half of its arguments against YAML instead. JSON has no "ambiguity in parsing", JSON has no indentation-based syntax, and JSON has no implicit typing to turn "no" into false.

XML "lost" because it is also a poor format for structured data. It requires constant choice between whether some content should be conveyed using attributes or child nodes. If you use child nodes, indentation may or may not be relevant (because it can introduce leading/trailing spaces). There is also no standard for data types. (Do you write a boolean attribute foo as foo="foo", foo="true", or foo="yes"? Sure, a schema can describe the allowed values, but whoever interprets the XML still needs to add the right translation to true and false in their programming language by hand, presumably.) Due to the manifold ways of expressing essentially the same data, working with XML is always painful.

This is not really XML's fault. It was designed as a way of marking up text. When that is your goal, XML is not a bad choice, and all of its features make a lot more sense. (For example, this child-attribute distinction: Is this part of the text? If so, it should be represented as child nodes. Otherwise, it should be an attribute.) Here, something like JSON really falls flat.

But most data is not marked up text. And yet, some people and institutions tried to push XML as the universal solution to all data transfer problems. This is the reason for the push-back against it.

This isn't to say that we did not also lose some things. In complex cases, having something like a schema is good. Comments are appreciated when the files are also read and edited by humans. JSON's data types are underspecified. But I firmly believe that the solution to this is not XML.

I assume that "all the different levels" might not exist yet. The author is probably creating them a bit in advance, and will keep going as long as they're motivated. Having a regular schedule for new releases helps, and doing it daily seems as sensible as any other schedule.

There is also the problem that they decided to make all references nullable, so `NullPointerException`s could appear everywhere. This "forced" them to introduce the escape hatch of `RuntimeException`, which of course was way overused immediately, normalizing it.

And here I was, thinking everybody already knew XKCD 1053 ...

But XML was designed as a markup language. That is was often used for configuration is not its fault. (And it works much better for its original purpose, where the otherwise strange distinction between attributes and child nodes actually makes sense.)

MAML seems to be designed as a configuration language, but calls itself a markup language. (YAML did too, but they changed it at some point.)

(Without knowing the precise nature of these laws) I would expect that they don't forbid you to store backups elsewhere. It's just that they mandate that certain types of data be backed up in sufficiently secure and independent locations. If you want to have an additional backup (or backups of data not covered by the law) in a more convenient location, you still can.

I generally agree that treating substrings that are numbers as numbers is a good default for most users in most situations.

However, for hex numbers this simply won't give good results because some of them will just happen to not contain any of the digits A to F and be treated as base-10 numbers by the heuristic while others will include these digits and be sorted differently.

(So, a having a strict lexicographic mode as an alternative in file managers would be nice.)

I did have one or two math professors who would use x_0 and x_1 instead of x_1 and x_2 when they had to name two objects.

But I have also seen places where 1-based indexing was used despite being "obviously wrong". I don't quite recall what it was, but there was sequence of objects A_1, A_2, ... and a natural way of combining A_k and A_l to get A_(k + l - 1). Had the indices been shifted by 1 to be 0-based, the result would have been A_(k + l), which would be much nicer to work with.

Dijkstra is right, of course. However, most math texts still use 1-based indexing. If you want to translate them into code, it's easier when the conventions match.

(Now, if you had a proposal for switching math over to 0-based indexing ...)

But the second interpretation only makes sense if the last item somehow deserves special treatment (over, say, the second-to-last item). Otherwise, you should similarly argue that the previous second-to-last item should also show up in the changes as it has now turned into the third-to-last item. (So maybe every item in the list should be preceded by as many spaces as are items before it and succeeded by as many commas as are items following it. Then, every change to the list will be a diff of the entire list.)

    first item,,,
     second item,,
      third item,
       fourth item

Even with a keyboard shortcut, I never found it to be truly satisfying. I cannot quite recall what was annoying, though. Maybe you cannot space back into the formula after closing it? (I certainly recall having the experience of typing a formula, closing it, noticing a mistake, hitting backspace, and deleting the entire formula.) Maybe there was just a slight delay for the formula editor to open? Also, $ is still more pleasant to type than Alt+=.

I would be willing to try again, but I'm not buying Word for the privilege.

Last time I checked, Word was also basically untenable for math-heavy writing because there was too much procedure involved in setting a formula. This is fine if you need one here and there, but if you have lots of formulas (including many tiny ones, like just using the name of a variable), switching to a dedicated formula mode in the interface is just not pleasant. In LaTeX (or Typst), I just type $, and off I go.

RST disqualifies itself immediately by making inline markup un-nestable, though.

I don't use Haskell nearly enough to call myself a Haskeller but I will still disagree. Yes, operator sections are yet another thing to learn but I find them very intuitive, and actually easier to read than the equivalent lambda expression because I don't have to match up the bound variable.

(For example, (\x -> x ++ y) and (\y -> x ++ y) look pretty similar to me at first glance, but (++y) and (x++) are immediately distinguishable.)

Of course, this is reliant on knowing the operators but that seems like a mostly orthogonal issue to me: You still need to know the operator in the lambda expression. That said, the niceness of sections gives people yet another reason to introduce operators for their stuff when arguably they already are too prevalent.

This is not necessary. Practiced German speakers generally do not struggle with splitting words into their components because syllables follow relatively predictable patterns. You will run into ambiguities from time to time, of course, but the same applies to tons of other features of natural languages as well. (Do you want to outlaw homophones in English?)

Anyway, there is also a perfectly acceptable and established way of making German words easier to parse if need be: hyphens. So Hyphen-Case instead of PascalCase.

Context, maybe just for others: Schiff is ship and Fahrt is ride, so eine Schifffahrt is a cruise (and without the article, it is also the term for seafaring in general). Anyway, you can see that Schiff ends with two Fs and Fahrt starts with one, so if you put them together to form a compound word, you get three Fs in a row, Schifffahrt. In pre-reform German spelling, this was deemed excessive, so one would write Schiffahrt, instead. The German spelling reform in the mid-90s changed this, so now you do the logical thing. (Whether the old way really was confusing and which way is more aesthetic are separate questions.)

Yes, and this is also a mistake, hence the <button> element.

Trying to shoehorn this onto the existing headings was a mistake. They should have introduced a new <h> or maybe <ha> (heading-automatic) element for this. Plus, support in the form of a CSS pseudoclass like :heading(n), which matches <hn> headings and <h> elements nested in n articles/sections/..., would have been great.

Essentially, it was hopeless to expect that designers would adapt their stylesheets to style headings based on the number of sections surrounding them. And if the visual styles don't adapt, nobody will use the outline algorithm to choose their headings.

(Which is sad, because the algorithm makes content nicely nestable. With the algorithm, I can take an article that was independent and use it as a section in a larger work, and the headings will automatically adapt. Though, as a pet-peeve of mine, nested IDs would also be somewhat necessary for this, so that it's fine to have two embedded articles which both have a section with an ID #introduction.)