Notices by 🇳🇴 Thor — backup account (thorthenorseman@octodon.social), page 12

*wakes up with dry eye again*
*gets out of bed*
*makes breakfast*
*cat caught in keyboard cable again*
*tries to remove him*
*gets two deep claw marks in hand*
*keyboard slides into breakfast*
*swears a lot*
*can't open pack of bandages*
*swears some more*
*goes to supermarket*
*buys too much candy*
*goes back*
*dry eye gets worse*
*cat wants attention again*

Fuck this.

*goes back to bed*

*wakes up dry eye*
*gets out of bed*
*makes breakfast*
*cat caught in keyboard cable again*
*tries to remove him*
*gets two deep claw marks in hand*
*keyboard slides into breakfast*
*swears a lot*
*can't open pack of bandages*
*swears some more*
*goes to supermarket*
*buys too much candy*
*goes back*
*cat wants attention again*
Fuck this.
*goes back to bed*

*meowing intensifies* https://octodon.social/media/Km3YHiLZBX5VtTOxFO0

Idea for FLOSS project: Multi-key / bidirectional map implemented as a list of objects with searchable indexes and insert/delete events, with implementations for the most common languages. This type of data structure is one I've needed more times than I can count.

It's less straight forward when storing non-primitive datatypes or references to external objects, but not impossible. You'd just have to make sure that the most basic usage scenario stays easy to configure.

But here we reach another annoyance I've faced in pretty much every language I've used so far: There is never a multi-key map type or class in the standard library. In relational databases, you can add an index to any column you wish to search. In your average OOP language, you can only index one key... and you can't simultaneously treat that key as a value. A sort of in-memory database table is such a universally useful construct that it should really exist in every language.

If you could somehow tell JavaScript that the inner array is sorted by the key you're searching for, and that you're going to be scanning most of the array for results, it could then compile that into a nested loop with two iterators, where the inner loop only performs a search if the elements don't line up.

You could speed up such an algorithm by transforming your inner array into a hash map (associative array), of course...

You'll often have a situation where what you're doing is essentially performing a JOIN on two arrays, and it runs slow as balls, because you're running a find() on one array inside of a map() on the other, and it's performing a linear search on the inner array for every entry in the outer array, and that's not necessary.

One problem I've noticed with JavaScript functional style is that the most elegant construct doesn't offer the best performance. You'd think that, especially for synchronous stateless arrow functions with single-statement bodies nested within array methods like map, reduce or filter, some kind of analysis similar to that done by RDBMSes on SQL queries could be performed in order to produce the same result faster.

object-oriented programming is where you forget your objective and lose your orientation.

object-oriented programming is where you forget your objective and lose you orientation.

basic programming: to develop basic things like Facebook or Candy Crush

basic income: money you make on basic jobs like being a shop clerk or a taxi driver

#misleadingdefinitions

@seagazelle No need to concern yourself with blasphemers. Rest assured, the Messiah hasn't arrived yet. 😆

Not that me, the non-believer, would know what the hell I'm talking about...

One beautiful day, FLOSS apps aimed at consumers might actually get innovative instead of cloning proprietary apps...

...not likely, though.

@crushv XD

@crushv But you know who owns Instagram...

@crushv Why are you browsing Facebook? 🤨

Not sure what opinion to form about laptops with many stickers on them...

Ugh, I fell asleep around 8 o'clock this evening and woke up around midnight. It's 3 o'clock now and it feels like I have a mild hangover.