3 ms·

I'm a Perl dev for less than 5 years. Since last week I changed the company I work for. The new company has a project which is 12+ years old. This project has

I'm a Perl dev for less than 5 years. Since last week I changed the company I work for. The new company has a project which is 12+ years old. This project has a code base written in Perl which seemingly violates all programming best practices: files of 50k LoC,functions of several thousands of lines, there are frequently 5-6+ levels of nested ifs. It contains all the technical debt it acquired during these 12+ years. However, it took me less than an hour from the moment I got access to a working vm to make the first fix - display the correct currency on invoices which were not paid in usd. And this, in the context that it was the first time I logged into the app and I also had to find such a buggy invoice. Now, tell me again how unreadable and hard to understand Perl is?

mattmanser 11y ago
You can do that in any language. I've done that kind of thing in an hour in languages I've never even used before (uncompiled ones, obviously). Perversely your first fixes are often easier than your later ones as you're not trying to make things better, you want to show off his good you are to your new boss/client. The problems with bad code come when you have to make bigger changes and you're constrained by the existing design like a straight jacket. Adding a £ or a $ or a € is really easy for any experienced programmer.
chipsy 11y ago
I'm increasingly forgiving of that kind of "primitive" code with giant, heavily nested functions, because the worst that can go _wrong_ with it from a maintenance standpoint is heavy duplication and overreliance on mutable state. Those are knowable quantities, and you can attack them systematically. Otherwise, everything is laid out for you in straight-line order. You can just read it and see "this happens before that" without having to run the program or a debugger, and nobody even has to burden themselves with giving "this" and "that" an explicit name(although a comment can be a real boost to finding what you want). Codebases that are cleverly factored to within an inch of their life are much, much worse. There's no guarantee that the original factoring successfully decoupled anything, and all the additional content allows for new bugs to slip in "between the cracks" - parameters left accidentally unset, a hierarchy of functions getting called in the wrong order, etc. The original programmer has to spend more time coming up with ways to name and enumerate these details, allowing their eyes and thoughts to be taken off of the domain problem. Because more powerful programming tools are used, more powerful debugging techniques become necessary. And when the architecture breaks, the call stacks just get deeper as the heavy metaprogramming guns are brought out to make increasingly clever workarounds to the resulting issues - after all, nobody really wants to try to disentangle the code after it hits the point of architectural meltdown. Of the two, copy-paste coding is definitely the lesser evil. So I allow some of that first and then clean up the low-hanging fruit.
- deleted 11y ago
  [deleted]
- anaolykarpov 11y ago
  Surprisingly, I still have to find duplicated code. They've warned me it is there, but I haven't seen it yet

mattmanser 11y ago

You can do that in any language. I've done that kind of thing in an hour in languages I've never even used before (uncompiled ones, obviously). Perversely your first fixes are often easier than your later ones as you're not trying to make things better, you want to show off his good you are to your new boss/client. The problems with bad code come when you have to make bigger changes and you're constrained by the existing design like a straight jacket. Adding a £ or a $ or a € is really easy for any experienced programmer.

chipsy 11y ago

I'm increasingly forgiving of that kind of "primitive" code with giant, heavily nested functions, because the worst that can go _wrong_ with it from a maintenance standpoint is heavy duplication and overreliance on mutable state. Those are knowable quantities, and you can attack them systematically. Otherwise, everything is laid out for you in straight-line order. You can just read it and see "this happens before that" without having to run the program or a debugger, and nobody even has to burden themselves with giving "this" and "that" an explicit name(although a comment can be a real boost to finding what you want). Codebases that are cleverly factored to within an inch of their life are much, much worse. There's no guarantee that the original factoring successfully decoupled anything, and all the additional content allows for new bugs to slip in "between the cracks" - parameters left accidentally unset, a hierarchy of functions getting called in the wrong order, etc. The original programmer has to spend more time coming up with ways to name and enumerate these details, allowing their eyes and thoughts to be taken off of the domain problem. Because more powerful programming tools are used, more powerful debugging techniques become necessary. And when the architecture breaks, the call stacks just get deeper as the heavy metaprogramming guns are brought out to make increasingly clever workarounds to the resulting issues - after all, nobody really wants to try to disentangle the code after it hits the point of architectural meltdown. Of the two, copy-paste coding is definitely the lesser evil. So I allow some of that first and then clean up the low-hanging fruit.

deleted 11y ago
[deleted]
anaolykarpov 11y ago
Surprisingly, I still have to find duplicated code. They've warned me it is there, but I haven't seen it yet