Kotlin is quite ...special in this regard.
For certain language features, you have to declare functions as inline.
And when you do that, as far as I can tell, it basically just templates that function at the end of the files where that function is to be used.
Because well, it suddenly starts to report line numbers in exceptions, which are beyond the end of the file. Which is not helpful, at all.
Android has built-in support for a so-called "work profile", so folks can use their personally owned smartphone for work tasks with reasonable isolation. It has a separate file system, separate apps list, separate contacts etc..
Normally, this work profile will be activated and managed by your employer. Shelter (and similar apps, e.g. Insular) allows you to activate the work profile yourself and do basic management, like copying apps and files into there.
From a privacy viewpoint, it's great, if you're e.g. forced to use WhatsApp, but don't want it scraping your contacts.
I'm sure it is, I'm just not terribly happy about that fact.
Thing is, any code you write ultimately starts via input and funnels into output. Those two ends have to be asynchronous, because IO fundamentally is.
That means, if at any point between I and O, you want to write synchronous code, then you have to block execution of that synchronous code while output is happening. And if you're not at least spawning a new thread per input, then you may even block your ability to handle new input.
That can be fine, if your program has only one job to do at a time. But as soon as it needs to do a second job, that blocking becomes a problem and you'll need to refactor lots of things to become asynchronous code.
If you just build it as asynchronous from the start, it's significantly less painful.
But yeah, I guess, it's the usual case of synchronous code being fine for small programs, so tons of programmers never learn to feel comfortable with asynchronous code...
Our upper management paid for consulting a while ago and that consultant was similarly peddling bullshit numbers how much interest there is for the metaverse. Of course, from a survey conducted by that consulting company, so you couldn't even check their methodology etc..
Well, and upper management felt this was so insightful that they made a company-wide announcement with those numbers.
Thing is, we're an IT company. It felt like a quarter of all employees commented under that announcement, that this did not match up with their own observations at all.
Basically, management got scammed and fell for it wholesale, when they could have just talked to their employees.
Ah, are we going back to leet speak, again?
Yeah, don't take the table, barrel or burger as reference for the size. It's one of the jokes in that Spongebob episode that Spongebob prepares a tiny burger for this bug.
I found debuggers practically unusable with asynchronous code. If you've got a timeout in there, it will break, when you arrive at a breakpoint.
Theoretically, this could be solved by 'pausing' the clock that does the timeouts, but that's not trivial.
At least, I haven't seen it solved anywhere yet.
I mean, I'm still hoping, I'm wrong about the above, but at this point, I find it kind of ridiculous that debuggers are so popular to begin with.
Because it implies that synchronous code or asynchronous code without timeouts are still quite popular.
No idea, if there is any guided path into this. Much like the other commenter stumbled into it via music production, I stumbled into it via composing.
Personally, I've mostly dicked around with SurgeXT and MilkyTracker.
SurgeXT is a so-called VST plugin for use in digital audio workstations (DAWs), which is what the big boys & gals use to make electronic music. But it can also be started standalone, as just a digital instrument. And then you can type on your computer keyboard to play your sound like on a piano. SurgeXT is powerful, it will overwhelm you. Still does for me.
MilkyTracker presents an old-school way of making complete songs, generally 8- or 16-bit songs.
It's quite reduced in its features, which makes it a lot less daunting, and does allow playing around with waveforms for instruments rather directly.
Honestly, I don't think, you can really make a wrong start into this field. Lots of modulation methods have been around since the 70s and 80s, which you'll find in basically any music software.
Try to find something that's fun to you, to do with those sounds, so you keep coming back to try out new things.
For example, I'm a musician, so somedays I do just jam out to myself.
But working towards a little 8-bit song and just trying to create pseudo-instruments is also cool.
If you do have fun with it, you can splurge on hardware, like good headphones and a MIDI keyboard, but you don't need those to get into it.
The thing for me is, I did already know large chunks of music theory before getting into sound design, but traditional music theory doesn't concern itself with waveforms.
So, I know that a fourth interval sounds spiritual or that a triad in the base key sounds like 'home', i.e. you probably don't want to return there fully, unless you're concluding the journey / music piece.
But like, these are two completely random, basic examples and I don't know what the waveforms look like for them. Whether there's anything in the waveforms that correlates with that perception.
So, it feels like I learned most of the chemistry without any of the physics. And that I do now need to learn the physics to discover more of the chemistry. That there's potentially even quite large chunks of uncharted territory for music theory, because everyone's so obsessed with chemistry. Will have to see, if I'll discover as grand things as I'm hoping for.
Man, I kind of get why they're using Google Forms, but I can't help but feel like they'll miss out on contributions due to that. Certainly missing out on mine...
Sound engineering. Most people think sound is somehow sine waves and that's it. And well, that's technically correct on some level, but you can layer sound waves on top of each other to create triangle waves or square waves or what specific instruments happen to sound like:
Source
And well, these aspects have implications. Like with an oboe, even the basic waveform is quite interesting, so it's excellent for solos.
On the other hand, with a more boring sound, like a sine wave, you can do relatively wild things in terms of melody or combining them into intervals, and listeners won't feel overwhelmed as quickly.
And then you've got the fun field of drums. You can often just take white noise (or pink noise etc.) and just make its volume drop off rapidly and that already sounds similar to a drum.
Which is again interesting on the boring/interesting spectrum. That noise signal adds a short moment of chaos into the mix. But then we often make drums play quite structured rhythms to entertain a different boring/interesting spectrum over time.
Definitely also depends on the language. Here's e.g. Rust, the goddamn overachiever, pointing arrows and everything:
Often feels like, if you know where it needs to go, why ask me?