Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "pointless arguments"
Okay, story time.
This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.
So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.
You can see the responses for yourself here: https://goo.gl/poHKpK
Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is."
While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:
But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.
Because the bottom-line of that entire response is an argument: an argument against change.
Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.
No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.
Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.
Like, how about we talk performance?
How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?
How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?
Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.
That's the point of cooperative multithreading. It is a way to smartly work around these issues.
If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.
If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.
If you only read and never modify globals, no contention will ever occur.
Are you seeing the same trend I'm seeing?
When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?
"To multithread, you need a pair."18
I seriously wanna fucking knofe this guy who says JS is shit and Kotlin is superior well NEWS FLASH YOU FLYING PIECE OF WANK, every fucking language has its pros and cons
If you still think JS is supposed to be in browser well I say to you fucktard this isnt the 80s anymore and we ain't using Java applets and Flash for some limp dicked stuff JS has covered today. A language might have its dark sides but they are all fucking good. There is no superiour language there's only Mother fucking preference. I swear to god this is the worse limp dicked argument I've heard and I have to argue that JS has matured over the years11
The IDE discussion started again today. I am not an advocate of Eclipse but I didn’t find any compelling reason to switch to IntelliJ either. Maybe...just maybe I should try but that would mean just trying to be cool and I don’t know if it actually makes sense. So here’s how it went:
Me: okay give me one big reason why you want me to switch out of Eclipse.
Guy: slams desk and screams: Because Eclipse is slow! IntelliJ is fast and the community edition rocks
Me: in what way
Guy: oh come on. In every single way. I would rather choose notepad than Eclipse.
**curls into a ball and dies**2
I hate arguments for the following reasons:
1) I suck at them
2) they can get out of hand
3) their context may be pointless
4) they cause unnecessary pain
5) they end unresolved (sometimes)
I'm starting to gain a dislike for OOP.
I think classes make it easy for me to think of the entities of a problem and translate them into code.
But when you to attempt to test classes, that's when shit hits the fan.
In my opinion, it is pointless to test classes. If you ever seen test code for a class, you'll notice that it's usually horrible and long.
The reason for this is that usually some methods depend on other methods to be called first.
This results in the usual monolithic test that calls every goddamn method on the class.
You might say "ok, break the test into smaller parts". Ok. But the result of that attempt is even worse, because you end up with several big tests cases and a lot of duplicate code, because of the dependency of some methods on others.
The real solution to this is to make the classes be just glue: they should delegate arguments onto functions that reside on its own file, and, maybe afterwards emit events if you are using events.
But they shouldn't have too much test code classes though. The test code for classes should be running a simple example flow, but never doing any assertions other than expecting no exceptions.
For the most part, you'd be relying on the unit testing that is done for each delegated function.
If you take any single function you'll see that it's extremely easy to write tests for it. In fact, you can have the test right next to the fuction, like <module>.xyz <module>.test.xyz
So I don't think classes shouldn't be used at all, they should just be glue.
As you do normal usage of this software this way, when a bug is discovered you'll notice that the fix and testing code for this bug is very usually applied to the delegated functions instead of being a problem of classes.
I think classes by themselves sound sane in paper, but in practice they turn into a huge fucking messes that become impossible to understand or test.
How can something like traditional classes not get chaotic when a single class can have x attributes and y methods. The complexity grows exponentially. And sometimes more attributes and methods are added.
Someone might say "well, it's just the nature of problems. Problems can have a lot of variables".
Yeah, but cramming all of that complexity into a single 200 lines class is insanity.12