I think it's actually National Development Fund of the Executive Yuan, which is a Taiwanese fund.

Do you mind elaborating more on Haskell's types driving code generation? Genuinely curious

The regular type-based polymorphism/overloading, afair. Just like in C++. Typescript has a way to simulate it, but the code remains the same as if there were no types/overloads. https://www.typescriptlang.org/docs/handbook/2/functions.htm...

What about Ruby?

Source code is at https://github.com/pinda-fun/pinda-fun/

I think it’s because in German, sch is one consonant (like sh in English), while in Dutch, sch is a consonant cluster of s-ch, ch as in Loch Ness.

Also, in many dialects of Dutch, including the standard, the long e in the first syllable of Scheveningen is pronounced closer to the English long a than the German long e, and the final -n is silent. So a typical Dutch pronunciation would be (something like) [sxeɪ̯vənɪŋə], vs. German [ʃe̝ːvənɪŋən].

Yes, but presumably you’d learn that when you learn Dutch. I maintain that it is easier for a German speaker to learn the pronunciation of “Scheveningen” than to learn the entire Dutch language, and that L1 German speakers that learned Dutch as a foreign language will pronounce “Scheveningen” correctly, or, at any rate, not make the trivial mistake of analysing “sch” as the trigraph "sch," pronounced [ʃ], rather than as the letter "s" and the digraph "ch", producing the consonant cluster [sx].

>Yes, but presumably you’d learn that when you learn Dutch.

Learning it theoretically (and adapting to it somewhat) and being able to fluidly pronounce it as a native are two different things...

>and that L1 German speakers that learned Dutch as a foreign language will pronounce “Scheveningen” correctly

Technically correctly. Not natively correctly. There would still be differences...

You have some pretty unidiomatic JS in there. For example:

Array.prototype.filter.call(document.querySelectorAll(selector), filterFn);

What's more idiomatic is document.querySelectorAll(selector).filter(filterFn)

The same holds for forEach.

I suggest you look into how javascript prototype based OOP works

.filter() is not a method on the NodeList though, it only has forEach(), and even that is quite recent.

This is why people convert it to an array, and one of many reasons the standard JS API (and the DOM one in particular) are annoying to work with.

There are still more idiomatic methods you can use, ie:

    [...document.querySelectorAll(selector)].filter(filterFn);

That's a significantly newer syntax, so I wouldn't say it's "more idiomatic" than explicitly referencing the original function on the prototype (which is idiomatic to JS) and was the way to do it until the spread proposal, Array.from, and similar additions, what, ~5 years ago?

If anything isn't that code _less_ idiomatic in that it's less specific to JS and more of a generic operation?

In this instance I understood it to be idiomatic as it calls a JS Array constructor and iterates on the passed parameter to create it. It's been more common than the call/apply methods for years—at least as far as I've seen. The use of the array literal is always preferred, AFAIU.

I agree it'll probably become the new idiom in JS, but it probably needs another few years to begin taking over from the idiom that existed for decades before (and still works).

If you've seen that more common than call/apply for years then you probably work almost exclusively on new projects, with people that convert things to bleeding-edge, or with heavy transpilation: The spread operator as used there has only existed in regular released browsers/node for 3-4 years. I don't think it's a stretch to say the vast majority of code out there at this time won't be doing it that way.

Yeah could be. And my client base, as it were, are solely internal to the company I work for at this time and we have some knowledge and some cooperation over what versions of browsers people are using when it comes to web-based software. So support for older systems is largely unnecessary. That and building node backends the ES version doesn’t affect them anyway.

Definitely colours my work, and knowledge base.

I didn't make the site, it's a fork of the original website by Hubspot.

There is no such thing as average Indonesian though. Sure, around 50% of Indonesian population lives in Java Island (where Jakarta is) but I won't call people in Java "average Indonesian".

Keep in mind that Indonesia is a large archipelagic nation so wherever the capital is, chances are its "inaccessible" to the majority of Indonesians.