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 - "possible performance bug?"
-
Hey everyone,
First off, a Merry Christmas to everyone who celebrates, happy holidays to everyone, and happy almost-new-year!
Tim and I are very happy with the year devRant has had, and thinking back, there are a lot of 2017 highlights to recap. Here are just a few of the ones that come to mind (this list is not exhaustive and I'm definitley forgetting stuff!):
- We introduced the devRant supporter program (devRant++)! (https://devrant.com/rants/638594/...). Thank you so much to everyone who has embraced devRant++! This program has helped us significantly and it's made it possible for us to mantain our current infrustructure and not have to cut down on servers/sacrifice app performance and stability.
- We added avatar pets (https://devrant.com/rants/455860/...)
- We finally got the domain devrant.com thanks to @wiardvanrij (https://devrant.com/rants/938509/...)
- The first international devRant meetup (Dutch) with organized by @linuxxx and was a huge success (https://devrant.com/rants/937319/... + https://devrant.com/rants/935713/...)
- We reached 50,000 downloads on Android (https://devrant.com/rants/728421/...)
- We introduced notif tabs (https://devrant.com/rants/1037456/...), which make it easy to filter your in-app notifications by type
- @AlexDeLarge became the first devRant user to hit 50,000++ (https://devrant.com/rants/885432/...), and @linuxxx became the first to hit 75,000++
- We made an April Fools joke that got a lot of people mad at us and hopefully got some laughs too (https://devrant.com/rants/506740/...)
- We launched devDucks!! (https://devducks.com)
- We got rid of the drawer menu in our mobile apps and switched to a tab layout
- We added the ability to subscribe to any user's rants (https://devrant.com/rants/538170/...)
- Introduced the post type selector (https://devrant.com/rants/850978/...) (which will be used for filtering - more details below)
- Started a bug/feature tracker GitHub repo (https://github.com/devRant/devRant)
- We did our first ever live stream (https://youtube.com/watch/...)
- Added an awesome all-black theme (devRant++) (https://devrant.com/rants/850978/...)
- We created an "active discussions" screen within the app so you can easily find rants with booming discussions!
- Thanks to the suggestion of many community members, we added "scroll to bottom" functionality to rants with long comment threads to make those rants more usable
- We improved our app stability and set our personal record for uptime, and we also cut request times in half with some database cluster upgrades
- Awesome new community projects: https://devrant.com/projects (more will be added to the list soon, sorry for the delay!)
- A new landing page for web (https://devrant.com), that was the first phase of our web overhaul coming soon (see below)
Even after all of this stuff, Tim and I both know there is a ton of work to do going forward and we want to continue to make devRant as good as it can be. We rely on your feedback to make that happen and we encourage everyone to keep submitting and discussing ideas in the bug/feature tracker (https://github.com/devRant/devRant).
We only have a little bit of the roadmap right now, but here's some things 2018 will bring:
- A brand new devRant web app: we've heard the feedback loud and clear. This is our top priority right now, and we're happy to say the completely redesigned/overhauled devRant web experience is almost done and will be released in early 2018. We think everyone will really like it.
- Functionality to filter rants by type: this feature was always planned since we introduced notif types, and it will soon be implemented. The notif type filter will allow you to select the types of rants you want to see for any of the sorting methods.
- App stability and usability: we want to dedicate a little time to making sure we don't forget to fix some long-standing bugs with our iOS/Android apps. This includes UI issues, push notification problems on Android, any many other small but annoying problems. We know the stability and usability of devRant is very important to the community, so it's important for us to give it the attention it deserves.
- Improved profiles/avatars: we can't reveal a ton here yet, but we've got some pretty cool ideas that we think everyone will enjoy.
- Private messaging: we think a PM system can add a lot to the app and make it much more intuitive to reach out to people privately. However, Tim and I believe in only launching carefully developed features, so rest assured that a lot of thought will be going into the system to maximize privacy, provide settings that make it easy to turn off, and provide security features that make it very difficult for abuse to take place. We're also open to any ideas here, so just let us know what you might be thinking.
There will be many more additions, but those are just a few we have in mind right now.
We've had a great year, and we really can't thank every member of the devRant community enough. We've always gotten amazingly positive feedback from the community, and we really do appreciate it. One of the most awesome things is when some compliments the kindness of the devRant community itself, which we hear a lot. It really is such a welcoming community and we love seeing devs of all kind and geographic locations welcomed with open arms.
2018 will be an important year for devRant as we continue to grow and we will need to continue the momentum. We think the ideas we have right now and the ones that will come from community feedback going forward will allow us to make this a big year and continue to improve the devRant community.
Thanks everyone, and thanks for your amazing contributions to the devRant community!
Looking forward to 2018,
- David and Tim48 -
https://git.kernel.org/…/ke…/... sure some of you are working on the patches already, if you are then lets connect cause, I am an ardent researcher for the same as of now.
So here it goes:
As soon as kernel page table isolation(KPTI) bug will be out of embargo, Whatsapp and FB will be flooded with over-night kernel "shikhuritee" experts who will share shitty advices non-stop.
1. The bug under embargo is a side channel attack, which exploits the fact that Intel chips come with speculative execution without proper isolation between user pages and kernel pages. Therefore, with careful scheduling and timing attack will reveal some information from kernel pages, while the code is running in user mode.
In easy terms, if you have a VPS, another person with VPS on same physical server may read memory being used by your VPS, which will result in unwanted data leakage. To make the matter worse, a malicious JS from innocent looking webpage might be (might be, because JS does not provide language constructs for such fine grained control; atleast none that I know as of now) able to read kernel pages, and pawn you real hard, real bad.
2. The bug comes from too much reliance on Tomasulo's algorithm for out-of-order instruction scheduling. It is not yet clear whether the bug can be fixed with a microcode update (and if not, Intel has to fix this in silicon itself). As far as I can dig, there is nothing that hints that this bug is fixable in microcode, which makes the matter much worse. Also according to my understanding a microcode update will be too trivial to fix this kind of a hardware bug.
3. A software-only remedy is possible, and that is being implemented by all major OSs (including our lovely Linux) in kernel space. The patch forces Translation Lookaside Buffer to flush if a context switch happens during a syscall (this is what I understand as of now). The benchmarks are suggesting that slowdown will be somewhere between 5%(best case)-30%(worst case).
4. Regarding point 3, syscalls don't matter much. Only thing that matters is how many times syscalls are called. For example, if you are using read() or write() on 8MB buffers, you won't have too much slowdown; but if you are calling same syscalls once per byte, a heavy performance penalty is guaranteed. All processes are which are I/O heavy are going to suffer (hostings and databases are two common examples).
5. The patch can be disabled in Linux by passing argument to kernel during boot; however it is not advised for pretty much obvious reasons.
6. For gamers: this is not going to affect games (because those are not I/O heavy)
Meltdown: "Meltdown" targeted on desktop chips can read kernel memory from L1D cache, Intel is only affected with this variant. Works on only Intel.
Spectre: Spectre is a hardware vulnerability with implementations of branch prediction that affects modern microprocessors with speculative execution, by allowing malicious processes access to the contents of other programs mapped memory. Works on all chips including Intel/ARM/AMD.
For updates refer the kernel tree: https://git.kernel.org/…/ke…/...
For further details and more chit-chats refer: https://lwn.net/SubscriberLink/...
~Cheers~
(Originally written by Adhokshaj Mishra, edited by me. )23 -
//
// devRant unofficial UWP update (v2.0.0-beta)
//
After several concepts, about 11 months of development (keep in mind that I released 20 updates for v1 in the meantime, so it wasn't a continous 11 months long development process) and a short closed beta phase, v2 is now available for everyone (as public beta)! :)
I tried to improve the app in every aspect, from finally responsive and good looking UI on Desktop version to backend performance improvements, which means that I almost coded it from scratch.
There are also of course a few new features (like "go to bottom" in rants), and more to come.
It's a very huge update, and unfortunately to move forward, improve the UI (add Fluent Design) and make it at the same level of new UWP apps, I was forced to drop the supported for these old Windows 10 builds:
- Threshold 1 (10240)
- Threshold 2 (10586)
Too many incompatiblity issues with the new UI, and for 1 person with a lot of other commitments outside this project (made for free, just for passion), it's impossible to work at 3 parallel versions of the same app.
I already done something like that during these 11 months (every single of the 20 updates for v1 needed to be implemented a second time for v2).
During the closed beta tests, thanks to the awesome testers who helped me way too much than I ever wished, I found out that there are already incompatiblity issues with Anniversary Update, which means that I will support two versions:
1) One for Creators Update and newer builds.
2) One for Anniversary Update (same features, but missing Fluent Design since it doesn't work on that OS version, and almost completly rewritten XAML styles).
For this reason v2 public beta is out now for Creators Update (and newer) as regular update, and will be out in a near future (can't say when) also for the Anniversary Update.
The users with older OS versions (problem which on PC could be solved in 1-2 days, just download updates) can download only the v1.5.9 (which probably won't be supported with new updates anymore, except for particular critcal bug fixes).
So if you have Windows 10 on PC and want to use v2 today, just be sure you have Creators Update or Fall Creators Update.
If you have Windows 10 PC with Anniversary Update, update it, or if you don't want to do that, wait a few weeks/months for the update with support for your build.
If you have an older version on PC, update it, or enjoy v1.5.9.
If you have Windows 10 Mobile Anniversary Update, update it (if it's possible for your device), or just wait a few weeks/months for the update with support for your build.
If you have Windows 10 Mobile, and because of Microsoft stupid policy, you can't update to Anniversary Update, enjoy v1.5.9, or try the "unofficial" method (registry hack) to update to a newer build.
I hope it's enough clear why not everyone can receive the update today, or at all. :P
Now I would like to thank a few people who made this possible.
As always, @dfox who is always available for help me with API implementations.
@thmnmlist, who helped me a lot during this period with really great UI suggestions (just check out his twitter, it's a really good person, friend, designer and artist: https://twitter.com/thmnmlist).
And of course everyone of the closed beta testers, that reported bugs and precious suggestions (some of them already implemented, others will arrive soon).
The order is random:
@Raamakrishnan
@Telescuffle
@Qaldim
@thmnmlist
@nikola1402
@aayusharyan
@cozyplanes
@Vivaed
@Byte
@RTRMS
@tylerleonhardt
@Seshpengiun
@MEGADROID
@nottoobright
Changelog of v2.0.0-beta:
- New UI with Fluent Design and huge improvements for Desktop;
- Added native support for Fall Creators Update (Build 16299);
- Changed minimum supported version to Creators Update (Build 15063), support for Anniversary Update (Build 14393) will arrive soon;
- Added mouse support for Pull-To-Refresh;
- Added ability to change your username and email;
- Added ability to filter (by 'Day', 'Week', 'Month' and 'All') the top Rants;
- Added ability to open rant links in-app;
- Added ability to zoom GIFs (just tap on them in the Rant View);
- Added 'go to bottom' button in the Rant View (if more than 3 comments);
- Added new theme ('Total Black');
- ...complete changelog in-app and on my website (can't post it here because of the 5000 characters limit)...
What will arrive in future updates:
- 'Active Discussions' screen so you can easily find rants that have recent comments/discussions;
- Support for 'Collabs';
- Push Notifications (it was postponed and announced too many times...);
- More themes and themes options;
- and more...
If you still didn't download devRant unofficial UWP, do it now: https://microsoft.com/store/apps/...
If you find some bugs or you have feature suggestion, post it on the Issue Tracker on GitHub (thanks in advance for your help!): https://github.com/JakubSteplowski/...
I hope you will enjoy it! ;)56 -
Google sucks!
No, not as e-mail or for privacy reasons. Sure, that too, but it comes with "free" stuff.
It sucks because it's breaking every possible record in the worst, shittiest, most insanely stupid APIs and integrations out there on the entire fucking planet!
It is comically stupid!
Aside from their LOVE of hard-deprecating APIs every few months, requiring constant, time consuming maintenance of every tool that integrates deeply with Google services, some of their APIs, for expensive stuff, look like they've been written by Bobby McFartface from 7th grade.
Take a look at DoubleClick Search (their ad performance reporting tool, that sure does sound like one). To upload custom, additional data, you must pass in a ton of parameter, and they REQUIRE some of them to have a specific, hardcoded value. What's the point in passing that parameter then you dickheads?!
But fine, so you uploaded some stuff using the API. Now you want to delete everything and try again after you fixed a bug - well you fucking CAN'T! You can't delete stuff, you can only mark them as "deleted" using an update call.
Bulk operations? Fuck no!
Can I just add on top? Well of course not! That will raise a ton of exceptions. Same message should be transmitted using the PUT, not POST request, in order to edit.
Can I send everything to PUT? Of course not! You can't edit something that's not there, dummy!
Can I see what's there so that I can update it, and add what's missing?
Well of course not! Why on Earth would you need to see what information is in there after you uploaded it? Who needs that anyway?
Simply send, pray, and hope that everything will be fine (it will not).
Like holy fucking crap, it can't get any more stupid!
Google is a huge pile of idiots who feed on only a single cow - the search engine.
It's times like these when I think that Google right now is the worst thing that exists for everyone in tech. It's dragging everyone down with their monopolies everywhere and complete idiocy in managing them.5 -
Our web department was deploying a fairly large sales campaign (equivalent to a ‘Black Friday’ for us), and the day before, at 4:00PM, one of the devs emails us and asks “Hey, just a heads up, the main sales page takes almost 30 seconds to load. Any chance you could find out why? Thanks!”
We click the URL they sent, and sure enough, 30 seconds on the dot.
Our department manager almost fell out of his chair (a few ‘F’ bombs were thrown).
DBAs sit next door, so he shouts…
Mgr: ”Hey, did you know the new sales page is taking 30 seconds to open!?”
DBA: “Yea, but it’s not the database. Are you just now hearing about this? They have had performance problems for over week now. Our traces show it’s something on their end.”
Mgr: “-bleep- no!”
Mgr tries to get a hold of anyone …no one is answering the phone..so he leaves to find someone…anyone with authority.
4:15 he comes back..
Mgr: “-beep- All the web managers were in a meeting. I had to interrupt and ask if they knew about the performance problem.”
Me: “Oh crap. I assume they didn’t know or they wouldn’t be in a meeting.”
Mgr: “-bleep- no! No one knew. Apparently the only ones who knew were the 3 developers and the DBA!”
Me: “Uh…what exactly do they want us to do?”
Mgr: “The –bleep- if I know!”
Me: “Are there any load tests we could use for the staging servers? Maybe it’s only the developer servers.”
DBA: “No, just those 3 developers testing. They could reproduce the slowness on staging, so no need for the load tests.”
Mgr: “Oh my –bleep-ing God!”
4:30 ..one of the vice presidents comes into our area…
VP: “So, do we know what the problem is? John tells me you guys are fixing the problem.”
Mgr: “No, we just heard about the problem half hour ago. DBAs said the database side is fine and the traces look like the bottleneck is on web side of things.”
VP: “Hmm, no, John said the problem is the caching. Aren’t you responsible for that?”
Mgr: “Uh…um…yea, but I don’t think anyone knows what the problem is yet.”
VP: “Well, get the caching problem fixed as soon as possible. Our sales numbers this year hinge on the deployment tomorrow.”
- VP leaves -
Me: “I looked at the cache, it’s fine. Their traffic is barely a blip. How much do you want to bet they have a bug or a mistyped url in their javascript? A consistent 30 second load time is suspiciously indicative of a timeout somewhere.”
Mgr: “I was thinking the same thing. I’ll have networking run a trace.”
4:45 Networking run their trace, and sure enough, there was some relative path of ‘something’ pointing to a local resource not on development, it was waiting/timing out after 30 seconds. Fixed the path and page loaded instantaneously. Network admin walks over..
NetworkAdmin: “We had no idea they were having problems. If they told us last week, we could have identified the issue. Did anyone else think 30 second load time was a bit suspicious?”
4:50 VP walks in (“John” is the web team manager)..
VP: “John said the caching issue is fixed. Great job everyone.”
Mgr: “It wasn’t the caching, it was a mistyped resource or something in a javascript file.”
VP: “But the caching is fixed? Right? John said it was caching. Anyway, great job everyone. We’re going to have a great day tomorrow!”
VP leaves
NetworkAdmin: “Ouch…you feel that?”
Me: “Feel what?”
NetworkAdmin: “That bus John just threw us under.”
Mgr: “Yea, but I think John just saved 3 jobs. Remember that.”4 -
Okay, story time.
Back during 2016, I decided to do a little experiment to test the viability of multithreading in a JavaScript server stack, and I'm not talking about the Node.js way of queuing I/O on background threads, or about WebWorkers that box and convert your arguments to JSON and back during a simple call across two JS contexts.
I'm talking about JavaScript code running concurrently on all cores. I'm talking about replacing the god-awful single-threaded event loop of ECMAScript – the biggest bottleneck in software history – with an honest-to-god, lock-free thread-pool scheduler that executes JS code in parallel, on all cores.
I'm talking about concurrent access to shared mutable state – a big, rightfully-hated mess when done badly – in JavaScript.
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.
Every time I showed my work to a JavaScript developer, I'd get negative feedback. Like, unjustified hatred and immediate denial, or outright rejection of the entire concept. Some were even adamantly trying to discourage me from this project.
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:
http://nexusjs.com/architecture/
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.
The average JavaScript developer doesn't want a multithreaded server platform for JavaScript because it means a change of the status quo.
And this is exactly why I started this project. I wanted a highly performant JavaScript platform for servers that's more suitable for real-time applications like transcoding, video streaming, and machine learning.
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)?
How about utilising logical CPUs to the fullest extent, and allowing them to execute JavaScript? Something that isn't even possible with the current model implemented by Node?
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?
Good JavaScript programming practices miraculously coincide with the best practices of thread-safety.
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 think that two criterias are important:
- don't block my productivity
- author should have his userbase in mind
1) Some simple anti examples:
- Windows popping up a big fat blue screen screaming for updates. Like... Go suck some donkey balls you stupid shit that's totally irritating you arsehole.
- Graphical tools having no UI concept. E.g. Adobes PDF reader - which was minimalized in it's UI and it became just unbearable pain. When the concept is to castrate the user in it's abilities and call the concept intuitive, it's not a concept it's shit. Other examples are e.g. GEdit - which was severely massacred in Gnome 3 if I remember correctly (never touched Gnome ever again. I was really put off because their concept just alienated me)
- Having an UI concept but no consistency. Eg. looking at a lot of large web apps, especially Atlassian software.
Too many times I had e.g. a simple HTML form. In menu 1 you could use enter. In menu 2 Enter does not work. in another menu Enter works, but it doesn't submit the form it instead submits the whole page... Which can end in clusterfuck.
Yaaayyyy.
- Keyboard usage not possible at all.
It becomes a sad majority.... Pressing tab, not switching between form fields. Looking for keyboard shortcuts, not finding any. Yes, it's a graphical interface. But the charm of 16 bit interfaces (YES. I'm praising DOS interfaces) was that once you memorized the necessary keyboard strokes... You were faster than lightning. Ever seen e.g. a good pharmacist, receptionist or warehouse clerk... most of the software is completely based on short keyboard strokes, eg. for a receptionist at a doctor for the ICD code / pharmaceutical search et cetera.
- don't poop rainbows. I mean it.
I love colors. When they make sense. but when I use some software, e.g. netdata, I think an epilepsy warning would be fair. Too. Many. Neon. Colors. -.-
2) It should be obvious... But it's become a burden.
E.g. when asked for a release as there were some fixes... Don't point to the install from master script. Maybe you like it rolling release style - but don't enforce it please. It's hard to use SHA256 hash as a version number and shortening the hash might be a bad idea.
Don't start experiments. If it works - don't throw everything over board without good reasons. E.g. my previous example of GEdit: Turning a valuable text editor into a minimalistic unusable piece of crap and calling it a genius idea for the sake of simplicity... Nope. You murdered a successful product.
Gnome 3 felt like a complete experiment and judging from the last years of changes in the news it was an rather unsuccessful one... As they gave up quite a few of their ideas.
When doing design stuff or other big changes make it a community event or at least put a poll up on the github page. Even If it's an small user base, listen to them instead of just randomly fucking them over.
--
One of my favorite projects is a texteditor called Kate from KDE.
It has a ton of features, could even be seen as a small IDE. The reason I love it because one of the original authors still cares for his creation and ... It never failed me. I use Kate since over 20 years now I think... Oo
Another example is the git cli. It's simple and yet powerful. git add -i is e.g. a thing I really really really love. (memorize the keyboard shortcuts and you'll chunk up large commits faster than flash.
Curl. Yes. The (http) download tool. It's author still cares. It's another tool I use since 20 years. And it has given me a deep insight of how HTTP worked, new protocols and again. It never failed me. It is such a fucking versatile thing. TLS debugging / performance measurements / what the frigging fuck is going on here. Take curl. Find it out.
My worst enemies....
Git based clients. I just hate them. Mostly because they fill the niche of explaining things (good) but completely nuke the learning of git (very bad). You can do any git action without understanding what you do and even worse... They encourage bad workflows.
I've seen great devs completely fucking up git and crying because they had really no fucking clue what git actually does. The UI lead them on the worst and darkest path imaginable. :(
Atlassian products. On the one hand... They're not total shit. But the mass of bugs and the complete lack of interest of Atlassian towards their customers and the cloud movement.... Ouch. Just ouch.
I had to deal with a lot of completely borked up instances and could trace it back to a bug tracking entry / atlassian, 2 - 3 years old with the comment: vote for this, we'll work on a Bugfix. Go fuck yourself you pisswads.
Microsoft Office / Windows. Oh boy.
I could fill entire days of monologues.
It's bad, hmkay?
XEN.
This is not bad.
This is more like kill it before it lays eggs.
The deeper I got into XEN, the more I wanted to lay in a bathtub full of acid to scrub of the feelings of shame... How could anyone call this good?!?????4 -
Okay. Here's the ONLY two scenarios where automated testing is justified:
- An outsourcing company who is given the task of bug elimination in legacy code with a really short timeframe. Then yes, writing tests is like waging war on bugs, securing more and more land inch after inch.
- A company located in an area where hiring ten junior developers is cheaper than hiring one principal developer. Then yes, the business advantage is very real.
That's it. That's the only two scenarios where automated testing is justified. Other such scenarios doesn't exist.
Why? Because any robust testing system (not just "adding some tests here and there") is a _declarative_ one. On top of already being declarative (opposed to the imperative environment where the actual code exists), if you go further and implement TDD, your tests suddenly begins to describe your domain area, turning into a declarative DSL.
Such transformations are inevitable. You can't catch bugs in the first place if your tests are ignorant of entities your code is working with.
That being said, any TDD-driven project consists of two things:
- Imperative code that implements business logic
- Declarative DSL made of automated tests that also describes the same business logic
Can't you see that this system is _wet_? The tests set alone in a TDD-driven project are enough to trivially derive the actual, complete code from it.
It's almost like it's easier to just write in a declarative language in the first place, in the same way tests are written in TDD project, and scrap the imperative part altogether.
In imperative languages, absence of errors can be mathematically guaranteed. In imperative languages, the best performance (e.g. the lowest algorithmic complexity) can also be mathematically guaranteed. There is a perfectly real point after which Haskell rips C apart in terms of performance, and that point happens earlier on than you think.
If you transitioned from a junior who doesn't get why tests are needed to a competent engineer who sees value in TDD, that's amazing. But like with any professional development, it's better to remember that it's always possible to go further. After the two milestones I described, the third exists — the complete shift into the declarative world.
For a human brain, it's natural to blindly and aggressively reject whatever information leads to the need of exiting the comfort zone. Hence the usual shitstorm that happens every time I say something about automated testing. I understand you, and more than that, I forgive you.
The only advice I would allow myself to give you is just for fun, on a weekend, open a tutorial to a language you never tried before, and spend 20 minutes messing around with it. Maybe you'll laugh at me, but that's the exact way I got from earning $200 to earning $3500 back when I was hired as a CTO for the first time.
Good luck!6