It's not really different than downloading a .msi or .exe installer on Windows and running it. Or downloading a .pkg installer on macOS and running it (or running a program supplied in a .dmg). Or downloading a .deb or .rpm on Linux and running it.
It's all whether or not you trust the entity supplying the installer, be it your package manager or a third party.
At least with shell scripts, you have the opportunity to read it first if you want to.
Because everyone uses airgapped disposable micro VM's for everything, right? No one would be stupid or lazy enough to run them on their development laptop or production server, right? Right!?!
Maybe the good side-effect of LLM's will be to standardize better hygiene and put a nail in the coffin of using full-fat kitchen sink OS images for everything.
No, of course every reasonable developer works with a bag full of disposable e-vapes, each one used to run a single command on and then thrown into a portable furnace.
Console doesn't work for anything but platformers. Competitive online gaming = PC (Aoe2, BF6, Dark and Darker, Swordai, MWO, The Finals, War Thunder, PS2 etc.).
I definitely get the appeal of running FPS and such on PC. I'm much more accurate with a mouse and keyboard combo over a controller, but I'm appealing to the strengths a console does have as well. I own both so I can change up my experience to whichever offers the best one for me.
When I worked at a university's tech support, this was a recurring problem. People made grade lists in Excel, then imported them into the digital learning environment, which occasionally was set to a different language. This meant that the decimal point would be disregarded, and e.g. an 8.5/10 would be imported as an 85 (which got clamped to 10). Maximum grades for everyone, confused students and teachers :')
Even better: grades range from 1.0 (best) to 5.0 (failed) with partial grades (.3, .7) in-between.
Caused a few problems when a 1.3 got interpreted as the first May and converted to the number of days between the epoch and the first ofay of that year.
That sounds correct. This issue would be when the decimal separator matches the argument separator. In that situation =IF(A1 > 42.1, B1, C1) would be equivalent to =IF(A1 > 42,1; B1; C1)
The possibility of incorrect parsing of equation with a variadic function that contains a decimal number in the equation.
However, this is a localization as even the functions change names.
It’s just a locale setting as to which is applied. If you use English (US or UK) then your argument separator will be a comma. If you use other languages, then a semi colon will apply. You’ll find most guidance online referring to English language functions and comma separators, but ultimately it doesn’t really matter. If you ship a spreadsheet to me that you wrote in German functions and syntax that contains:
=SVERWEIS(X2;A:C;3;0)
I’ll open that and find
=VLOOKUP(X2,A:C,3,0)
This suggests client localization that is rendered differently with different language settings.
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).
Nothing like a full rewrite. I migrated multiple projects, but while there is a significant amount of work involved its a tiny fraction of what a full rewrite would require.
Did it a couple of times. Not something you can do with your eyes closed, but not even close to the nightmare of upgrading a JS application or upgrading a rails app.
Every DataFrame library with a significant user base uses function chaining because that's the best workflow for such stuff. Also notebook support / magic cell comments for iterative EDA.
Python: polars-py, pandas, pySpark
JVM: Spark
R: R
Go can't compete with this even with SIMD support.
reply