Still to this day, when I occasionally use Excel/Libre Office Calc I never know wether to write `sum(` or `summe(`. Function names depend on the localization settings of the system I'm working on.
I'm currently starting to learn swedish myself. I was looking for the translation of "facing the west" but I think that was omitted in the translation. (Btw. Why is it facing THE west and not facing west anyways?) if the translation omits such a lot of detail it's not interesting to me.
Given what we've seen so far it wouldn't surprise me if Musk had built a kill switch into these vehicles to stop the police from taking action against him.
I'm currently using AI code completion.
Since then I sometimes have subtle errors in my code that didn't happen before. Here is how that happens:
AI suggests something to me that looks right at a glance. I accept it and move on. Then later I hunt down a strange bug. When I find it I'm like "wait, that line's wrong! I didn't write that".
If you need an example of a germanic language that has a very regular phonetic spelling I think Dutch is a better example than German. German has a lot of idiosyncrasies, because the spelling tries to preserve the etymology of the words. In Dutch they don't bother trying to preserve a word's history, everything is written as it sounds. (With a handful easy to memorize exceptions)
I get it that gnome is nowadays an experimental desktop environment, that tries a lot of new approaches.
I just don't understand why many distributions use it as their default DE.
While the author dislikes extension functions in kotlin they enable one feature that Java doesn't have: With them you can create domain specific languages within kotlin that are quite ergonomic.
- Jetbrains has built a nice reactive js wrapper with them.
- The gradle configuration is written in a kotlin dsl.
They can be used to specify configuration and add meta information and thus replace Java annotations.
That is my kotlin "killer" feature because I personally don't like annotations.
Java's language design has always been "pedagogical" (or patronizing) to not give the developer to much power to create to much abstractions and complexity.
So it's not just its age but also this philosophy that has made Java a rather inelegant language ( compared with e.g. kotlin)
My reason for switching from gnome to KDE was that it was not possible for gnome to manage more than one Bluetooth adapter. A scenario that quickly occurs when you use a docking station. KDE had no problem with that. Another thing is the crusade against tray icons by gnome.
So yeah, I like the cleanliness of gnome actually better than KDE, which is really a bit messy. But when this "cleanliness" comes at the price of stripping away essential functionality, there's no choice.
Great idea. I'd suggest turning the clock 180°. Since we are used to having the clock wrap around on the top not the bottom. There is a saying (at least here in Germany) it's "5 to 12" meaning it's time to act now, which is what your clock is trying to symbolize. That would work better if the "12" was in its usual (top) position.
I have to admit never really dug into Julia.
When it was new I read about it as I was looking for a replacement of python/numpy.
But then I was really repulsed by the fact that array indices don't start at 0.
Of course. So everyone can decide wether to use it or not.
Or even switch this on at some point in the boot sequence
Currently the linux kernel doesn't have an interface for this. But I think it is important to do this within the kernel so no malicious program can bypass it.
Very interesting discussion. Here are my 2 cents:
I agree, that how shell handles filesnames and confuses them with commands is inherently broken.
I would like to focus on whtat filenames are supposed to be.
In my understanding filenames are supposed to be like booktitles or labels on goods like in the supermarket.
So they are not supposed to contain random binary data. That is what file's contents are for. Filenames should however contain any printable character that you expect on a label. And no fake characters like beep or linefeed. But they should be fully international. I mean this is the 21st century! :-)
In order to define printable characters you also need to define a character encoding.
Unicode clearly defines 2 sets of control characters c0 and c1. I would exclude these two sets, but allow any other unicode character.
I now there is an argument about which unicode encoding is better (utf8, utf16, the way apple encodes unicode vs the way everyone else does, ...)
Maybe one could define the filesystem's encoding inside it and even give the kernel a translation layer between the ondisk encoding and the one visible to the user.