Oh, that's something I also did in QBasic ages ago. I since lost the source code, but it basically worked by querying the screen from bottom to top, finding snow pixels (white) and moving them down, unless there was an obstacle. The initial snow on the ground (and the snowman) were using a different color that was almost white so it wouldn't detect as snow. It worked fairly well in 320×200 at the time.
I've tried the same approach in Turbo Pascal with BGI in the hopes of having a faster language and higher resolution available. It turned out to be quite a bit slower, likely because drawing and querying pixels was a bit more involved when using an adapter layer like BGI.
A few weeks ago I tried rewriting all that in TypeScript for fun and also trying to integrate it as an easter-egg with our graph drawing library (which renders with SVG) and first had to figure out how to efficiently support arbitrary obstacles that are initially SVG as well as a potentially changing viewport of the whole scene. I got sidetracked and didn't finish it, but proper collision handling was so easy back then (just look at the pixel color), but now with vector graphics and reading pixels being a very slow operation in many cases, it was surprisingly complicated.
At least from Rostock to somewhat closer destinations you have both options. There's a bi-hourly IC to Hamburg or Berlin and another bi-hourly RE towards the same destinations. They're not terribly different in terms of travel time, but one is a regional train and one is an inter-city train.
Sure, long distances (I had to travel from Rostock to Tübingen last weekend) are typically not taken with regional trains (although you technically can; I did that as a poor student a few times, it just takes 16 hours instead of 10), but over medium distances (around 2–3 hours) you often have both options.
Rebrickable is awesome. One of my children loves building with instructions and will do relatively little free building with Lego, and Rebrickable makes it very easy to find alternative models (often with questionable stability, though) that can be built from the same set. It also features a search of alternative models you can build with all the sets (and bricks) you have.
The way the array is constructed at least leads to holey arrays in V8. Perhaps similar in other implementations. The performance characteristics between different array types may vary significantly as well. Still, the traditional for loop, counting upwards seems to be fastest for me across Chrome and Firefox on Linux. For-of is slowest by a wide margin.
In fact, part of the implementation (or at least ideas) were borrowed from TypeScript. Nullability in C# changes depending on the checks around the code (similar to how the type of expressions in ThpeScript can change depending on prior code).
The use cases are different. While MSBuild tasks run during build (and partially when loading a project), typically the IDE is oblivious what happens there. The source generator runs directly inside the compiler infrastructure and thus you didn't get error highlights for code that would otherwise be only generated during build but not as you type. This makes it much more friendly than pure build-time generation of code.
You don't have to write the method twice. Source generators can only add new code, they cannot take away a method you declared, so it will still be there at runtime when called with non-constant arguments.
The formulae are indeed stored in the same format, regardless of language. For rendering and parsing in the UI they use translated function names and the field separator (commma in English, but semicolon in many other languages because decimal numbers use a comma there).
It does irk me a bit (though not as much as the translated VBA back in the day). But that's probably because I know English, I often look for solutions to my problems in English, not in my native language, and then would have to mentally translate that back. But that's perhaps a burden for programmers more than for typical users.
A few thoughts:
• it's been that way for decades, at this point. So changing it would annoy a lot of users
• the problem with comma and semicolon would remain unless you want entering numbers normally and within a formula to be different. I'm not sure that's good in a product built around numbers (and often numbers that should be written and formatted like any other number in that country).
• making it configurable might work, but that then requires more testing, although sometimes it's not clear how much testing Microsoft is still doing, so that might not be much of a point. But adding options also has UX limits and not just in the length of the settings screen.
LibreOffice Calc has an option to force English function names regardless of the current localization. I guess Excel should have something similar, too¹.
Fun fact: in European and Brazilian Portuguese, the same function names can refer to different things. European SUBSTITUIR² is REPLACE (Brazilian MUDAR), Brazilian SUBSTITUIR³ is SUBSTITUTE (European SUBST).
I've tried the same approach in Turbo Pascal with BGI in the hopes of having a faster language and higher resolution available. It turned out to be quite a bit slower, likely because drawing and querying pixels was a bit more involved when using an adapter layer like BGI.
A few weeks ago I tried rewriting all that in TypeScript for fun and also trying to integrate it as an easter-egg with our graph drawing library (which renders with SVG) and first had to figure out how to efficiently support arbitrary obstacles that are initially SVG as well as a potentially changing viewport of the whole scene. I got sidetracked and didn't finish it, but proper collision handling was so easy back then (just look at the pixel color), but now with vector graphics and reading pixels being a very slow operation in many cases, it was surprisingly complicated.
reply