16

So, first time ranting, sorry if I mess anything up.
When I first started my current job and got introduced to the system we were coding in, something seemed a little fishy to me. Didn't like the system anyway, but at least the language is a compiler language, so it runs quite quickly, right?
In theory, yeah. If the lead dev liked the IDE that came with it. But he has to REALLY fucking hate it, because rather than using it, he codes in plaintext. No syntax highlighting, no auto-indent, nothing. And he's built the entire damn system around doing that. Sadly the compiler is only integrated into the IDE, so what do we do there? Copy the code from the plaintext file to the IDE to compile it there? No no, why would you. The language has a function you can use to compile some code at runtime.
And so he does. Every. Single. Fucking. Script. There's a single main script that runs and finds the correct textfile to then runtime-compile and execute. So we effectively made a compiler language into a massively unoptimized interpreter lang.
I even mentioned that this might be a problem, but I was completely dismissed, so at that point it's not my problem anymore and I have then switched to a different system anyway.
Couple weeks later I heard the same guy complaining that the scripts were running almost the whole night so we'd probably need some better hardware or something.
Well if only there was a really obvious solution that would improve the performance by probably about a factor of 20 or so...

Comments
  • 4
    maybe download more RAM?

    also, welcome to devrant 🤗
  • 4
    Hell's IT department?
  • 3
    @rantsauce nah, the office has a/c. Otherwise...
  • 1
    Depending upon the language I have seen 300x improvement of compiled vs interpreted.
  • 0
    OK, what the hell now? It's a sad anecdote...
  • 5
    i think he invented LAT compiling.
    Long After Time compiling =D
  • 4
    or TTL - totally too late compiling
  • 1
    Suggest a compiled code cache...
  • 2
    @Oktokolo they said there's no real problem, so I won't come up with real solutions ^^ but yeah, I also thought about something like this... Oh well
  • 1
    cool
  • 0
    @CodingPeasant Whether you would try to improve the environment or not obviously depends on whether you actually like being surrounded by stupid bullshit or not.

    So if you like what you see, don't give helpful advice that could risk them finally seeing their errors...
  • 1
    @Oktokolo as I said, I tried showing them the errors of their way, they just don't see that there's a problem with it. Even after a test that showed that "my way" (or the non stupid way) is way faster, just dismissed it completely. Could I sit down in meeting after meeting explaining and trying to convince them? Sure. Do we even have the time to fix it atm? Nope. So yeah, I've just become apathetic towards it
  • 0
    @CodingPeasant No need to mention it at all meetings - just the ones which deal with performance.

    Maybe, they actually know that they fucked it up and are just too proud to admit. Make sure, that they can experience that shame as often as possible. Maybe, they will finally decide to actually fix it - or fire you, which would be a good opportunity to find a job where they aren't too proud to fix a bug...
Add Comment