101–110 of 601 posts
Is it possible for any codebase to NOT eventually (given enough time) become a crufty pile of garbage?
I suspect (but have no real evidence... yet) that SOME of this spaghetti garbage is due to the traits of procedural, OOP, mutable languages. But this would then imply that things like functional-language codebases have much longer lifespans... and I don't have evidence for that... but I'm hoping someone can chime in
My own CMS. Here's the function signature of the heart of it, which depending on circumstance may call itself recursively. function a_nodes_list_trees( $site_url, $base_url, $mode, $site_id, $max_subtree_depth, $nlevels, $node_id = 0, $tree_id = 0, $nleft = 0, $nright = 0, $nlevel = 0, $current_subtree_depth = 0, $flags = 0, $order = 'tree', $inline = false, /* needed when loading stuff via ajax*/ $skipped_types = []…
options = NodeBuilder .author({ min: 2 }) .flag({ .. }) .pagitation({ .. })
function a_nodes_list_trees(options) { ... }
Because in the end, if your function is fast and working correctly, it's fine even though it's a little bit messy. The problem is more all the code calling this function and having to pass dozens of params in the right order, and then it's a pain to start adding/changing parameters. Also, when calling this function, you probably need a bunch of temporary variables to "build" all the params; all those temporary variables could instead live inside that builder object.
We have absolutely no idea how to write code. I always wonder if it's like this for other branches of engineering too? I wonder if engineers who designed my elevator or airplane had "ok it's very surprising that it's working, let's not touch this" moments. Or chemical engineers synthesize medicines in way nobody but a rockstar guru understands but everyone changes all the time. I wonder if my cellphone is made by mac…
Solving complex stuff takes a lot of effort, and usually most companies do not have the resources or the motivation to go back and rewrite a product.
Earlier quoted context omitted.
> I wonder if engineers who designed my elevator or airplane had "ok it's very surprising that it's working, let's not touch this" moments. I honestly sometimes do wonder. Judging by the elevators in my building some things even barely work at times. They go down often and require parts replacements that take weeks to arrive. They're barely 3 years old.
> They go down often Isn’t that one of the two main features of the product?
Behold, academia. The only maintainers of this code, ever, have been grad students and postdocs. I estimate there have been about 12-15 generations worth. This code has supported hundreds of publications in its lifespan. A codebase that began life in 1987, in C. First ported to matlab in 1999. First source control was added (as SVN) in 2015. Between 2015 and 2018, there were 6 commits total, yet 3 people graduated ou…
I've worked on a CMS that was partially done in .NET, Iron Python and used an XSLT templating system to generate HTML for the front end. The architecture looked like something from the Early Java days. The system used Iron Python / C# in the following way. 1. A web request would hit the CMS 2. There was a massive switch statement to work out how the query would be rewritten 3. If it the url was prefixed with processo…
Earlier quoted context omitted.
The difference is, an elevator is a precisely defined problem and never needs to have its functionality improved and changed. In fact, you could build the exact elevator almost identically. Software is never like that — it’s dynamic and constantly changing throughout the life cycle of the software.
> an elevator is a precisely defined problem Ha! As a mechanical engineer, no, nothing in reality is ever precisely defined. Consider that every single part in the elevator has a tolerance: none of the parts are exactly the same in every elevator. Did you account for thermal expansion? What about wear? Fatigue? > Software is never like that — it’s dynamic and constantly changing throughout the life cycle of the softw…
There is a person inside me -- whenever this is said -- that wants to shout "No! You can prove correctness of your program!". But this complicates the issue even more, since afaik no elevator's correctness is proven but it just works. Mechanical stuff somehow just magically work without proof whereas it's still debatable if proven software works (did we prove the software that proved it?). I don't know what's the difference. Maybe elevator has a well-defined structure, it goes up and down, opens the door etc, even though implementation can change (as you explained). But maybe software isn't like that. Idk.
Magento.
We have absolutely no idea how to write code. I always wonder if it's like this for other branches of engineering too? I wonder if engineers who designed my elevator or airplane had "ok it's very surprising that it's working, let's not touch this" moments. Or chemical engineers synthesize medicines in way nobody but a rockstar guru understands but everyone changes all the time. I wonder if my cellphone is made by mac…
In my experience, code needs to be re-factored 3 times before it starts to look coherent and clean.
But 99% of projects can't justify that kind of expense.
But good code is very feasible, just takes time.