I had to open the desktop app to write this because I could never write a rant this long on the app.

This will be a well-informed rebuttal to the "arrays start at 1 in Lua" complaint. If you have ever said or thought that, I guarantee you will learn a lot from this rant and probably enjoy it quite a bit as well.

Just a tiny bit of background information on me: I have a very intimate understanding of Lua and its c API. I have used this language for years and love it dearly.

[START RANT]

"arrays start at 1 in Lua" is factually incorrect because Lua does not have arrays. From their documentation, section 11.1 ("Arrays"), "We implement arrays in Lua simply by indexing tables with integers."

From chapter 2 of the Lua docs, we know there are only 8 types of data in Lua: nil, boolean, number, string, userdata, function, thread, and table

The only unfamiliar thing here might be userdata. "A userdatum offers a raw memory area with no predefined operations in Lua" (section 26.1). Essentially, it's for the API to interact with Lua scripts. The point is, this isn't a fancy term for array.

The misinformation comes from the table type. Let's first explore, at a low level, what an array is. An array, in programming, is a collection of data items all in a line in memory (The OS may not actually put them in a line, but they act as if they are). In most syntaxes, you access an array element similar to:

array[index]

Let's look at c, so we have some solid reference. "array" would be the name of the array, but what it really does is keep track of the starting location in memory of the array. Memory in computers acts like a number. In a very basic sense, the first sector of your RAM is memory location (referred to as an address) 0. "array" would be, for example, address 543745. This is where your data starts. Arrays can only be made up of one type, this is so that each element in that array is EXACTLY the same size. So, this is how indexing an array works. If you know where your array starts, and you know how large each element is, you can find the 6th element by starting at the start of they array and adding 6 times the size of the data in that array.

Tables are incredibly different. The elements of a table are NOT in a line in memory; they're all over the place depending on when you created them (and a lot of other things). Therefore, an array-style index is useless, because you cannot apply the above formula. In the case of a table, you need to perform a lookup: search through all of the elements in the table to find the right one. In Lua, you can do:

a = {1, 5, 9};
a["hello_world"] = "whatever";

a is a table with the length of 4 (the 4th element is "hello_world" with value "whatever"), but a[4] is nil because even though there are 4 items in the table, it looks for something "named" 4, not the 4th element of the table.

This is the difference between indexing and lookups. But you may say,

"Algo! If I do this:

a = {"first", "second", "third"};
print(a[1]);

...then "first" appears in my console!"

Yes, that's correct, in terms of computer science. Lua, because it is a nice language, makes keys in tables optional by automatically giving them an integer value key. This starts at 1. Why? Lets look at that formula for arrays again:

Given array "arr", size of data type "sz", and index "i", find the desired element ("el"):

el = arr + (sz * i)

This NEEDS to start at 0 and not 1 because otherwise, "sz" would always be added to the start address of the array and the first element would ALWAYS be skipped. But in tables, this is not the case, because tables do not have a defined data type size, and this formula is never used. This is why actual arrays are incredibly performant no matter the size, and the larger a table gets, the slower it is.

That felt good to get off my chest. Yes, Lua could start the auto-key at 0, but that might confuse people into thinking tables are arrays... well, I guess there's no avoiding that either way.

WASM was a mistake. I just wanted to learn C++ and have fast code on the web. Everyone praised it. No one mentioned that it would double or quadruple my development time. That it would cause me to curse repeatedly at the screen until I wanted to harm myself.

The problem was never C++, which was a respectable if long-winded language. No no no. The problem was the lack of support for 'objects' or 'arrays' as parameters or return types. Anything of any complexity lives on one giant Float32Array which must surely bring a look of disgust from every programmer on this muddy rock. That is, one single array variable that you re-use for EVERYTHING.

Have a color? Throw it on the array. 10 floats in an object? Push it on the array - and split off the two bools via dependency injection (why do I have 3-4 line function parameter lists?!). Have an image with 1,000,000 floats? Drop it in the array. Want to return an array? Provide a malloc ptr into the code and write to it, then read from that location in JS after running the function, modifying the array as a side effect.

My- hahaha, my web worker has two images it's working with, calculations for all the planets, sun and moon in the solar system, and bunch of other calculations I wanted offloaded from the main thread... they all live in ONE GIANT ARRAY. LMFAO.If I want to find an element? I have to know exactly where to look or else, good luck finding it among the millions of numbers on that thing.

And of course, if you work with these, you put them in loops. Then you can have the joys of off-by-one errors that not only result in bad results in the returned array, but inexplicable errors in which code you haven't even touched suddenly has bad values. I've had entire functions suddenly explode with random errors because I accidentally overwrote the wrong section of that float array. Not like, the variable the function was using was wrong. No. WASM acted like the function didn't even exist and it didn't know why. Because, somehow, the function ALSO lived on that Float32Array.

And because you're using WASM to be fast, you're typically trying to overwrite things that do O(N) operations or more. NO ONE is going to use this return a + b. One off functions just aren't worth programming in WASM. Worst of all, debugging this is often a matter of writing print and console.log statements everywhere, to try and 'eat' the whole array at once to find out what portion got corrupted or is broke. Or comment out your code line by line to see what in forsaken 9 circles of coding hell caused your problem. It's like debugging blind in a strange and overgrown forest of code that you don't even recognize because most of it is there to satisfy the needs of WASM.

And because it takes so long to debug, it takes a massively long time to create things, and by the time you're done, the dependent package you're building for has 'moved on' and find you suddenly need to update a bunch of crap when you're not even finished. All of this, purely because of a horribly designed technology.

And do they have sympathy for you for forcing you to update all this stuff? No. They don't owe you sympathy, and god forbid they give you any. You are a developer and so it is your duty to suffer - for some kind of karma.

I wanted to love WASM, but screw that thing, it's horrible errors and most of all, the WASM heap32.

aaaaaghh fucking Handlers man. Android is so fucking full of shit, i wonder why am i still doing it. love is pain.

Why can't there be one mother fucking solution to all lazy ass asynchronous programming? handlers, threadpools, asynctask, executers, Broadcasts, intentService, coroutines, rxjava,.... i don't what new stuff are people snorting these days.

Ok , leave everything. A handler is class- no sorry, Handler, alongside some fucking Looper clss (and maybe some more stuff i don't know) other classes is a way of handling inter thread communication. Handlers can:

-send data to ui thread
-recieve data from ui thread
-send "messages" to ui thread
-recieve "messages" from ui thread.
- can be attached to ui thread
- can be attached to any child thread
- can be accessed anonymosly via any view
- can be present in multiple places, working together
- can kill night king with a dagger
- can do porn better than johnny sins
- can run for president of the whole fucking world
- do some more shits that i have yet to discover

And where do i find this? buried deep insides some medium articles or in some guy's horrible accent video.
Is background processing really this much of a toughnut to crack?
earlier i was all about using asynctask or foreground/background services, because these are the most easy to understand abstraction of a fairly difficult topic.
But as i see more projects, i see underlying apis like handlers, threadpools , executers , being directly used.
Why cant there be a fucking single abstraction, that could be "lightly tweaked" to handle every ugly case.

my fist job... i get to edit a c++ code written by a (mind you) programming company that they teamed with for the past(mind you again) 3 years ...
now just for starters, this code was edited by self taught coders that are really good engineers(they are really good), that didnt really know how the code worked before yet they still changed it, and it worked, how ever they wanted some changes.
i get the project files, and there is not one single comment describing what is happening... only code commented out... and no documentation what so ever were done....
so below are some of my comments that i wrote after i finished adding what i had to add, and fixing what i had to fix:

/*first rule of C anything coding, no actual functions in the header, well let me introduce you to a fully functioning thread running program all in the header, enjoy*/

//used to control the thread
// i honestly dont know why, but it worked soooooo yea...

// TG uncommented // for absolutely no reason what so ever...

//used to communicate with the port

//the message to be sent to the inverter, which has a code that will handle it
//hmmmmmm...

//again not usefull since we are using radioButtons
// same ...
// same ...
// same ...
// they said they dont even use this mode, but none the less, same ...
// calculate the checksum for the message
// ....
// one of the things that work, and god forbids i touch
// used for the status displayed on screen
// used for the (censored :P) status in the message
// used for the (censored :P) status in the message
// not used at all, but the message structure contains it and i refuse to edit that abomination
// used for the (censored :P) status in the message
// used for the (censored :P) status in the message
// just dont ask and roll with it, i didnt want to touch this
// saaaaame ...
// if before true this saaaaaame ...
// value of the (censored :P)
// it pains me to say it again, but this is no use
// (censored :P) input
// (censored :P) input
// only place seen , like for real it was just defined,sooooo yea :D
// well you know how it is
// message string
// check sum string
/****below from feed back****/
// (censored :P) coming in
// (censored :P) coming in
// (censored :P) coming in
// (censored :P)
/****below is the output to the receiver ****/
//(censored :P)
// (censored :P)
// (censored :P)
// (censored :P)
//you thought we were done.... nope, no idea. it comes in the feedback
// not used, literally commented out the one time it was used
// same ...
// XD, man this is a blast, same ...
// nope ...
// used to store the port chosen for the communication
// is a static for the number of data we have recorded so far, and as a row indicator for the recording method
// used to indicate the page we are on in the excel file, as well as the point in physical point in the test
// same ... oh look at this a positive same :D
// same ...
// same ...

Lord. Please deliver us from the cycle of unfinished programming languages and code benches that are designed to create more work for us. We beseech thee in thy mercy to transmute all this asynchronous lead that is found in javascript into a purer form of threading that is sensible and can be willfully blocked or not so in a way that works and does not divide us through our ugly code. May also we be given the ability to purge from our midst all child molesters and string them up by barbed wire off a line of telephone poles across the entire continental usa and may there be a sudden increase in the number of ravens and buzzards to feed on them, being nice birdies that I miss seeing so much. May half their positively identified population be kept alive and delivered unto us that we might remove their scrotum with a hook-ed barb and something resembling a serrated metallic spork, amen.

and please fix fucking node js. i agree that its asynchronous methods suck ass for literally everything as there is no use for it that seems to work given its a shitty emulated single thread.

In order to avoid talking bout thing we do to keep living, what's your fav music genre and why is it vaporwave? 😂