3 ms·
I've always said every line is a liability, its our job to limit liabilities. That has largely gone out the window these days.
by acedTrex 8mo ago
I've always said every line is a liability, its our job to limit liabilities. That has largely gone out the window these days.
- chr15m 8mo ago> every line is a liability, its our job to limit liabilities. Hard agree!
- nomel 8mo agoThe only people I've known that share this perspective are those that hate abstraction. Going back to their code, to extend it in some way, almost always requires a rewrite, because they wrote it with the goal of minimum viable complexity rather than understanding the realities of the real world problem they're solving, like "we all know we need these other features, but we have a deadline!" For one off, this is fine. For anything maintainable, that needs to survive the realities of time, this is truly terrible. Related, my friend works in a performance critical space. He can't use abstractions, because the direct, bare metal, "exact fit" implementation will perform best. They can't really add features, because it'll throw the timing of others things off to much, so usually have to re-architect. But, that's the reality of their problem space.
- johnmwilkinson 8mo agoI believe this is conflating abstraction with encapsulation. The former is about semantic levels, the later about information hiding.
- nomel 8mo agoMaybe I am? How is it possible to abstract without encapsulation? And also, how is it possible to encapsulate without abstracting some concept (intentionally or not) contained in that encapsulation? I can't really differentiate them, in the context of naming/referencing some list of CPU operations.
- Retric 8mo ago> How is it possible to abstract without encapsulation. Historically pure machine code with jumps etc lacked any from of encapsulation as any data can be accessed and updated by anything. However, you would still use abstractions. If you pretend the train is actually going 80.2 MPH instead of somewhere between 80.1573 MPH to 80.2485 MPH which you got from different sensors you don’t need to do every calculation that follows twice.
- nomel 8mo agoI'm using the industry definition of abstraction [1]: > In software, an abstraction provides access while hiding details that otherwise might make access more challenging I read this as "an encapsulation of a concept". In software, I think it can be simplified to "named lists of operations". > Historically pure machine code with jumps etc lacked any from of encapsulation as any data can be accessed and updated by anything. Not practically, by any stretch of the imagination. And, if the intent is to write silly code, modern languages don't really change much, it's just the number of operations in the named lists will be longer. You would use calls and returns (or just jumps if not supported), and then name and reference the resulting subroutine in your assembler or with a comment (so you could reference it as "call 0x23423 // multiply R1 and R2"), to encapsulate the concept. If those weren't supported, you would use named macros [2]. Your assembler would used named operations, sometimes expanding to multiple opcodes, with each opcode having a conceptually relevant name in the manual, which abstracted a logic circuit made with named logic gates, consisting of named switches, that shuffled around named charge carriers. Say your code just did a few operations, the named abstraction for the list of operations (which all these things are) there would be "blink_light.asm". > If you pretend the train is actually going 80.2 MPH instead of somewhere between 80.1573 MPH to 80.2485 MPH which you got from different sensors you don’t need to do every calculation that follows twice. I don't see this as an abstraction as much as a simple engineering compromise (of accuracy) dictated by constraint (CPU time/solenoid wear/whatever), because you're not hiding complexity as much as ignoring it. I see what you're saying, and you're probably right, but I see the concepts as equivalent. I see an abstraction as a functional encapsulation of a concept. An encapsulation, if not nonsense, will be some meaningful abstraction (or a renaming of one). I'm genuinely interested in an example of an encapsulation that isn't an abstraction, and an abstraction that isn't a conceptual encapsulation, to right my perspective! I can't think of any. [1] https://en.wikipedia.org/wiki/Abstraction_(computer_science) https://en.wikipedia.org/wiki/Abstraction_(computer_science) [2] https://www.tutorialspoint.com/assembly_programming/assembly_macros.htm https://www.tutorialspoint.com/assembly_programming/assembly...
- jahsome 8mo agoI don't see how the two are related, personally. I'm regularly accused of over-abstraction specifically because I aspire to make each abstraction do as little as possible, i.e. fewest lines possible.
- nomel 8mo agoI call that lasagna code! From what I've seen, developers start with spaghetti, overcompensate with lasagna, then end up with some organization more optimized for the human, that minimizes cognitive load while reading. To me, abstraction is an encapsulation of some concept. I can't understand how they're practically different, unless you encapsulate true nonsense, without purpose or resulting meaning, which I can't think of an example of, since humans tend to categorize/name everything. I'm dumb.
- galaxyLogic 8mo ago"Abstracting" means extracting the commnon parts of multiple instances, and making everything else a parameter. The difficulty for software is that developers often start by writing the abstraction, rather than having multiple existing instances and then writing code that collects the common parts of those multiple instances into a single abstraction. I guess that is what "refactoring" is about. In sciences and humanities abstraction is applied the proper way, studying the instances first then describing multitude of existing phenomena by giving names to their common repeating descriptions.
- nomel 8mo agoThis matches my "ideal" way of writing software, which is something close to "reverse waterfall". Start with the non-negotiable truths at the lowest level, then work your way up towards the goal, which is sufficiently defined. As you go, the patterns became apparent, collapsing into nice abstractions. The code always ends up nice and clean and modular. And, since I'm working towards the idea, I can say "here are the modular pieces I have to work with, dictated the fundamentals beneath, how do I use them to accomplish the task?". When working from the idea, I think it's easier to want to write something to achieve the immediate task, in a "not see the forest for the trees" kind of way (abstractions are about the goal, rather than the reality under). Of course, both directions are required, but I get the best "separation of concerns" going in reverse.
- cs_sorcerer 8mo agoFollowed by even better is code is no code, and best is deleting code. It’s one of those things which has always strikes me funny about programming is how less usually really is more
- elgenie 8mo agoNo code is as easy to maintain as no code. No code runs as fast as no code.
- doug_durham 8mo agoA better formulation is "every feature is a liability". Taking it to the line of code level is too prescriptive. Occasionally writing more verbose code is preferable if it makes it easier to understand.
- phi-go 8mo agoThis sounds wrong, features have to be the value of your code. The required maintenance and slow down to build more features (technical debt) are the liability, which is how I understood the relationship to "lines of code" anyway.
- TeMPOraL 8mo agoWrong or not, the industry embraced it. I can sort of understand it if I squint: every feature is a maintenance burden, and a risk of looking bad in front of users when you break or remove it, even if those users didn't use this feature. It's really a burden to be avoided when the point of your product is to grow its user base, not to actually be useful. Which explains why even Fischer-Price toys look more feature-ful and ergonomic than most new software products.
- catdog 8mo ago> A better formulation is "every feature is a liability". Taking it to the line of code level is too prescriptive. Amount of code is a huge factor but maybe not the best wording here. It's more a thing of complexity where amount of code is a contributing metric but not the only one. You can very easily have a feature implemented in a too complex way and with too much code (esp. if an LLM generated the code but also with human developers). Also not every feature is equal. > Occasionally writing more verbose code is preferable if it makes it easier to understand. Think this is more a classic case of "if the metric becomes a goal it ceases to be a metric" than it being a bad metric per se.
- ky3 8mo agoEWD 1036: On the cruelty of really teaching computing science (1988) “My point today is that, if we wish to count lines of code, we should not regard them as ‘lines produced’ but as ‘lines spent’: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.”
- ramraj07 8mo agoAgreed, every line you ship,whether you wrote it or not, you are responsible. In that regard, while I write a lot of code completely with AI, I still endeavor to keep the lines as minimal as possible. This means you never write both the main code and the tests using AI. Id rather have no tests than AI tests (we have QA team writing that up). This kinda works.