Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "logically wrong"
-
When you stare at your syntactically correct but logically wrong code for hours but can't find that little bitch of an error.
And then you call up your colleague, and it doesn't take him 4.3seconds to spot it.
-___________________-5 -
Dogecoin hit USD $0.40 recently, which means it's time for the Crypto Rant.
TL;DR: Dogecoin is shit and is logically guaranteed to eventually fall unless it is fundamentally changed.
===========================
If you know how Crypto works under the hood, you can skip to the next section. If you don't, here's the general xyz-coin formula:
Money is sent via transactions, which are validated by *anybody*.
Since transactions are validated by anybody, the system needs to make sure you're not fucking it up on purpose.
The current idea (that most coins use today) is called proof-of-work. In short, you're given an extremely difficult task, and the general idea is you wouldn't be willing to do that work if you were just going to fuck up the system.
For validating these transactions, you are rewarded twofold:
1) You are given a fixed-size prize of the currency from the system itself. This is how new currency is introduced, or "minted" if you prefer.
2) You are given variable-size and user-determined prize called "transaction fees", but it could be more accurately called a "bribe" since it's sole purpose is to entice miners to add YOUR transaction to their block.
This system of validation and reward is called mining.
===========================
This smaller section compares the design o f BTC to Dogecoin - which will lead to my final argument
In BTC, the time between blocks (chunks of data which record transactions and are added to the chain, hence blockchain) is ten minutes. Every ten minutes, BTC transactions are validated and new Bitcoins are born.
In Dogecoin, the time between blocks is only one minute. In Theory, this means that mining Dogecoin is about ten times easier, because the system expects you to be able to solve the proof of work in an average of one minute.
The huge difference between BTC and Doge is the block reward (Fixed amount; new coins minted). The block reward for BTC is somewhat complicated compared to Doge: It started as 50 BTC per block and every 4 years it is halved ("the great halving"). Right now it's 6.25 BTC per block. Soon, the block reward will be almost nothing until BTC hits it's max of 21 million bitcoins "minted".
Dogecoin reward is 10,000 coins per block. And it will be that way for the end of time - no maximum, no great halving. And remember, for every 1 BTC block mined, 10 Doge blocks are mined.
===========================
Bitcoin and Dogecoin are now the two most popular coins in pop culture. What makes me angry is the widespread misunderstanding of the differences between the two. It is likely that most investors buy Dogecoin thinking they're getting in "early" because it's so cheap. They think it's cheap because it isn't as popular as Bitcoin yet. They're wrong. It's cheap because of what's outlined in section two of this rant.
Dogecoin is actually not very far off Bitcoin. Do the math: there's a bit over 100 billion Dogecoin in circulation (130b). There's about 20 million BTC. Calculate their total CURRENT values:
130b * $0.40 = 52b
20m * $60k = 1.2t
...and Doge is rising much, much faster than BTC because of the aforementioned lack of understanding.
The most common thing I hear about Doge is that "nobody expects it to reach Bitcoin levels" (referring to being worth 60k a fucking coin). They don't realize that if Doge gets to be worth just $10 a coin, it will not just reach Bitcoin levels but overtake Bitcoin in value ($1.3T).
===========================
It's worth highlighting that Dogecoin is literally designed to fail. Since it lacks a cap on new coins being introduced, it's just simple math that no matter how much Doge rises, it will eventually be worthless. And it won't take centuries, remember that 100k new Doge are mined EVERY TEN MINUTES. 1,440 minutes in a day * 10K per minute is 14.4 million new coins per day. That's damn near every Bitcoin to ever exist mined every day in Dogecoin10 -
What.. the actual... fuuuuuck?!
Browsing through changes on TFS (yeah, yeah boo me for using TFS instead of git if you like, I don't care, most people use/prefer TFS here, so I conform 'to the standards'..)
Anyhow, going through changes, looking for the one where some comment appeared..
'a wild comment appeared'.. tadaaah!
Checked the rest of changes.. Hm.. Someone did a validity check.. that returns the 'false' if not passed.
// OK, great! They are finally testing their shit and fixing stuff..
But apparently then they decided it is OK to do all the shit anyways.. so WTF?!
Why even bother validating it?! Oh yeah, forgot... cuz in case it returned false YOU WERE NOT SUPPOSED TO LET SOME STUFF HAPPEN!! But they weren't assigned with that exact task I guess..
TO DO:
- do the validation algo // fml, not going into how fucked up that was written..but it was horrible!
- do validity check where appropriate/needed
- test validity check and that it doesn't break functionality
+ check if the validation actually logically works?! nope, not on my to do list, not my job..
All done, better not actually do something that requires you to think.. :\
How the fuck that happened?! How can one person be assigned to check if something is stupid/wrong?! and when checking (&confirming) still lets the customer do that shit anyways?! What's the point?! O.O13 -
"I don't have any issues with that (OS, code push, software, etc), so I'm not sure why you are having issues." I love reading comments like that, as if that solves the issue. The fuck does it matter if you don't have issues, they are having issues you moron. For a place for developers you'd think they'd be able to think logically, maybe they're in the wrong line of business. Maybe that software had an error parsing some file because some bit got flipped when writing to the HDD because there's an issue with the drive and the ECC failed for some reason, who cares. There's an issue and you saying it works for you makes you sound like a fucking moron... There's an error/crash, it happens, that's software.4
-
I have been debugging for like hours trying to figure out the cause an unknown bug spoiling my UI by making my elements overlap.
I'm working on a Unit Converter that takes kWh and then converts to mWh. (Logical Conversion: 1000 kWh = 1 mWh).
Just an easy shit i thought, using Javascript I just passed the dynamically generated kWh value to a function that takes maximum of 6 chars and multiply it by 0.001 to get the required result but this was where my problem started. All values came out as expected until my App hits a particular value (8575) and outputs a very long set of String (8.575000000000001), i couldn't figure the cause of this until i checked my console log and found the culprit value, and then i change the calculation logic from multiply by 0.001 to divide by 1000 and it came out as expected (8.575)
My question is that;
Is my math logically wrong or is this another Javascript Calculation setback?13 -
I freaking hate slow IDEs, especially ones made in Java.
I used to use an IDE/text editor called geany, and it was great, you could do almost every language in it and it worked great. It was fast, and efficient, it was a no-nonsense editor. That was when I was a kid, but I got in univ and got a job, so I had to start using big boy """""enterprise""""" IDEs like eclipse.
Eclipse, netbeans, and intellij (basically every Java based IDE except BlueJ) are exactly what is wrong with IDEs. They are clunky editors that frankly would be better off gone. They are slow, eat RAM like crazy (like most Java software). You just CANNOT have eclipse open for extended periods of time, because it WILL take up too much resources and get slow as heck. Android Studio (based on intellij) is a nightmare to work with. It just does not want to cooperate with you (I will agree they have improved a lot though).
I cannot believe I am saying this, but even the electron based IDEs like atom and code-oss are better than them. They are very easily expandable, something that Java was supposed to be, but is not. They have tons of plugins. Even if its not there, you can make one without having to spend a lifetime making the plugin! They look good. I never thought that going from IDEs with """""enterprise""""" UIs to something modern like code-oss would feel this great. Its ridiculous, I don't want to create a darn project for every single file that I want to edit, I just want syntax highlighting for a single .sh file that I want to edit right now. A project is just a way to logically define what is one "unit" or a "container for multiple files", you know what else is that? A simple directory.
Also I don't want 9 billion .xml files for the IDE to store its crap. Just make a .vscode like folder to hide your shit.11 -
React Native testing is hair pulling.
Every test needs to have 100 different mocks in place and there are: 3 different methods to mock a function (mock, mockImplementation, and fn), 3 different types of query methods to get elements (get, find, and query), and 5 different selectors to query on (accessibility label, testId, accessibility hint, accessibility value, etc.)
And after reading all this, being diligent and learning the difference between stupid, synonymously-named functions which have wildly different side effects like "getByA11yHint" and "findByA11yHint" (ugh...), after all that, you write out a test with all the appropriate mocks and you want to do something simple and it beats you up all over again.
Button enabled or button disabled. Simple right? Logically the former is "expect(elem).toBeEnabled()" and the latter is "expect(elem).not.toBeEnabled()", right?
Wrong! You're an imbecile. Your tests will fail and never tell you that ".not.toBeEnabled()" and ".toBeDisabled()" don't do the same thing even though they look and sound exactly the same. Only the latter will work. The former makes all your tests fail. Where is this written in the docs? Nowhere?! Great!
👌😄🔫3