6 ms·

Best practices are basically a sign of an area that lacks formal rigor or scientific analysis. You don't see any "best practices" for making algorithms faster

Best practices are basically a sign of an area that lacks formal rigor or scientific analysis. You don't see any "best practices" for making algorithms faster or more memory efficient. We have complexity theory that tells us the metrics definitively. This just means for algorithm complexity formal rigor has been established. For areas where we use the word "design" or "best practices" or "code organization" it's mostly people just randomly guessing things because there's no quantitative metric to tell people whether or not a guess is actually better or worse. What's the Big O of FP vs. OOP? Who knows? Nobody is clear about what is being measured here. What makes a "bad design" bad and what makes a "good design" good? Once we figure it out you will see that the word "design" will largely exit the field and be replaced with something along the lines of "calculation." It is better to "calculate" the best way to organize code rather then to "design" it because the word "design" is a synonym for "random best guess". The lack of formal rigor or some statistical metric means we can go into circular arguments about these topics forever.

unanswered 6y ago
This puts into words why I get momentarily annoyed whenever I see a programming help type question like "what are best practices to call a function pointer" or some such. The question implicitly suggests that there's no definite answer when in fact it's simply a question of fact, a knowledge question not a wisdom question. I feel that the person asking the question is somehow trying to shield themself from the "shame" of not knowing the answer by framing it as a request for discussion.
boberoni 6y ago
> formal rigor or scientific analysis This may be a bit philosophical, but couldn't "formal methods" and the "scientific method" also be considered a best practice? (and thus susceptible to becoming a cult?) Throughout the history of science, there has been many methods for doing science that have since been revolutionized or abandoned (e.g. cosmology, non-Euclidean geometry, eugenics, quantum mechanics). Thomas Kuhn is a notable writer on such paradigm shifts in the history of science. [1] [1]: https://en.wikipedia.org/wiki/Paradigm_shift https://en.wikipedia.org/wiki/Paradigm_shift
- Geminidog 6y ago
  Yeah, and I openly admit I'm part of the cult. My bias does not allow me to think of a better way of verifying reality by assuming observation, probability and logic is recursively true. Is there anyone here that doesn't share my bias and if you don't, why?
- megameter 6y ago
  Postmodernism explored this in some capacity in the 20th century, because there are links between science, rationalism, and our ability to think rationally in practice: if we do irrational science and don't notice, the results are false but accepted as true - a phenomenon which has indeed occurred countless times, despite mechanisms intended to add rigor to the process. All that has to happen is for an emotional attachment to a concept to settle in, and our sense of causality goes out the window. A lot of our material progress comes simply from selecting different benchmarks and methods of observation.
carlmr 6y ago
When it comes to how to write code we're essentially faced with a usability problem. When we write an API function we want other people to use it. When we write internal functions we want other developers to use it. When we write programs we want some customer to use it. A lot of usability design has been somewhat formalized. We describe design in terms of signifiers, affordances, constraints, mappings and feedback. A lot the bad and best practices can be rephrased in these terms. If your program is "stringly" typed it's unclear which affordances your functions offer, that's bad. In OOP a lot is hidden from the user, if this is well done, you have constraints that keep you from doing something wrong, if it's badly done you have big objects with some state that's unobservable (lack of signifiers) so you can't understand what it does (lack of affordances). In FP you do this through function signatures, purity and strong typing. The type signature together with the function name can show you the affordances of the function. By constraining inputs and making outputs explicit (e.g. result types) you provide constraints and signifiers about their usage. A mapping is what we expect, e.g. from a knob. If you find 4 knobs and 4 hot plates on a stove, you instinctively know what they do. If the hot plates are somewhat shifted laterally against each other it becomes even easier to identify which knob is for each plate. In programming this could be the name of a function. A function called printX() shouldn't do anything except printing, otherwise it breaks the instinctive mapping that you expect. A function named isX() shouldn't return void. It should return a boolean. Of course you can't condense this down to a simple number, but at least you can describe why something is good or bad. The groundwork has been laid already.
domk 6y ago
What about the argument that programming entire large systems (e.g. non-trivial applications as opposed to only algorithms) is way too complex to be described rigorously? At least with our current tools? It's the price we pay for the amount we can do with software. It's very powerful but also orders of magnitude more complex than anything we can reason about formally.
- zokier 6y ago
  That is just a sign that we are trying to run before we can walk. They key is in your own comment: > At least with our current tools We should be aiming more towards making projects with a scope that we can actually manage, instead of trying to build huge castles of sand and failing spectacularly. And of course continue to improve our tools to properly manage more complexity.
  - nine_k 6y ago
    I'm certain that brothers Wright did not have a rigorous mathematical model of their airplane. It is well known that Bell's telephone was invented by accident. I suspect we still lack a comprehensive theory of pizza-making. Sometimes you just hit a mother lode, and keep digging, preferably doing proper geological research along the way. But to postpone practical applications before a complete theory is ready is to lack business sense.
    - zokier 6y ago
      But we are not in Wright era of computing. We are in the 737 era, or should be. But somehow our methods are not tracking that. Experimentation has its place, but it should be followed by rigor which we are very much missing.
      - nine_k 6y ago
        I'm afraid we are still not even in the brothers Wright era of project planning, though. At least, im many areas. In some areas we (humans) have considerable successes, like building oil rigs in the ocean. I suspect we lack a good understanding of software requirements. From it, to my mind, inadequate management practices follow.
mianos 6y ago
This is not true. You see 'best practise' even in formally proven areas. This is because a formal proof does not mean there are not compromises when applied to the real world. What is the best sort? It depends on the size data you expect, locality, initial ordering. What about CAP? Pick two. Best practice is probably choosing a quicksort for now looking what happens. Maybe for CAP give up on immediate consistency. Best practice gives you a direction that will most likely get you to your destination. If you don't care about the destination you can take forever on the path.
- Geminidog 6y ago
  It is true, you're conflating things here. We've formalized how to define the "fastest" algorithm and for that we have definitive answers on what is faster and what isn't. Our notion of what is "best" is the thing here that has not been formalized. "Best" is a vague word it needs to be defined before it can even be formalized.
  - mianos 6y ago
    What is the fastest sort?
    - Geminidog 6y ago
      I don’t know at the moment but the algorithm exists simply because every sorting algorithm we know about has a quantitative speed metric assigned to it called the Big Oh. Keep in mind that my claim is that we know how to define the fastest algorithm which is different from the claim that the field has found the fastest sorting algorithm that will ever exist. Either way for the fastest algorithm out of the set or sorting algorithms that are known.... Most likely it’s a family of algorithms that share the same speed metric of O(N). There may be an algorithm or several algorithms that are faster. Look it up, you might find it. What I can guarantee you can’t find is the best design pattern or style of programming. There is no theory here let alone a definition for “best.” It’s obvious your question is trying to take the conversation in some other direction. Let me try to guess it. Your probably going to talk about other intrinsic downfalls and costs to sorting outside of the speed metric like memory or the domain limitation for O(N) sorting algos. To which I respond memory has nothing to do with the speed of the algorithm and is off topic from my claim. We know the fastest algorithm(s) by definition, because the theory of what is faster and what is not is fully fleshed out. The theory on which is the best algorithm to use in a problem given the speed and memory cost is something we don’t have a theory for yet, hence the usage of best practices, which further proves my point. This is where you conflate things, you didn’t separate aspects of areas described by theory and aspects not yet described by theory. You mistakenly lumped everything together. Hopefully I anticipated your actions correctly and you are the one who is taught a lesson here rather then your intention of teaching me something via your trap question.
robotresearcher 6y ago
> formal rigor has been established. There's the best practice. It's such a strong and useful one that it doesn't feel optional any more.
brundolf 6y ago
I once heard someone say that Software Engineering as a field today is about where Chemistry was 300 years ago: it's just alchemy. Nobody actually knows how it works or what is or isn't best. Some people have tried some stuff out and formed different theories around their anecdotal experiences. Some of those theories sometimes translate to other cases; some of them are completely bonkers. There's no real way to tell one from the other, because there's no concrete shared reality. So instead people argue a lot and the best rhetorician usually wins.
AtlasBarfed 6y ago
Moreover "best" implies all measured domains, not just algorithimic efficiency (which itself can be split into a half-dozen concerns such as linear speed, ability to be distributed, memory use, disk use, suitability to input patterns, i.e. all the reasons there are hundreds of sorting algorithms). Code complexity? Ease of testing? Compatibility/leveraging of tools? Apropos for your programmer ability? Apropos for non-programmers if it crosses out of pure programming? Best practice is definitely a weasel word. Something that should be qualified with what is being optimized, what prompted its adoption, and comparisons to other approaches that highlight/justify its use. It also falsely implies there is no better candidate out there (another computer science irony: your "best practice" has been proven via magical super-turing computation to truly be the best ever?). It assumes false authority. Really, they are only good for setting a reasonable standard and moving forward rather than constant bikeshedding.
rstuart4133 6y ago
I've come across people using "best practice" as the sole justification for doing something in software engineering, but thankfully it's rare. Where it's not rare is medicine. You regularly hear the term spat out like a weapon, particularly in big hospitals. It's a very poor way to justify something. It's a statement of the obvious: everyone agrees you should use the best or most efficient way of doing something. What people don't agree on is what that is. So it's "we all agree we should be doing it the best way, and I say the best way is ...". You get no indication of why it's best practice, or how it's been chosen, or who chose it. Its more an appeal to authority. There is another term in medicine that's also bandied about frequently: "evidence based medicine". Unlike "best practice", it assums the obvious: everyone agrees we should be using the best way. It's telling you how the best way way chosen: from the evidence. More importantly it's also giving you permission to improve on it: find your own evidence. If you asked for to see evidence for "best practice", it's often seen as an attempt to undermine authority. If you asked to see the evidence behind evidence based medicine, the reaction your likely to see is "oh, you get it, here is what I have". When I hear "because it's best practice" or "this is best practice" now, I shudder. It's not an invitation to be part of a team working to produce the best outcome. It's telling you you're a minion, and you'd better follow the rules. But I think you are right in one sense, the reason we see it used far less in software development is we can often shoot something down with a few sentences of tightly reasoned logic. Evidence is often easy to come by. Medicine doesn't have that luxury, the body is too complex to reason about. It does have rigor and scientific analysis, but it takes a big studies and a lot of effort to gather.
- Geminidog 6y ago
  Agreed. There's a dichotomy here that a lot of people don't know about that might help you get a better picture of the distinction you mention. Logic and Science are different in the sense that Logic does not require any evidence. Logic uses simple assumptions called axioms and then theorems derived from those axioms to make broader statements about the system. A computer is basically a system molded around logic so that you can use logical reasoning to derive statements and ignore evidence. This is what I mean by "rigor." Ironically, for convenience, testing (aka science) is used in computer programming even though formal analysis is a stronger (but more challenging) form of proof. Science on the other hand is more evidence based. If evidence contradicts logic than the evidence takes precedence. The medical field is more science than it is logic hence the distinction. A computer programmer can use heavier reliance on axiomatic reasoning to derive statements but the medical field will defer more to the black box statistical results of evidence. The difference is literally the same difference between math and science. Computer Programming blurs the line a bit but overall programming is closer to axiomatic reasoning than it is to science.

unanswered 6y ago

This puts into words why I get momentarily annoyed whenever I see a programming help type question like "what are best practices to call a function pointer" or some such. The question implicitly suggests that there's no definite answer when in fact it's simply a question of fact, a knowledge question not a wisdom question. I feel that the person asking the question is somehow trying to shield themself from the "shame" of not knowing the answer by framing it as a request for discussion.

boberoni 6y ago

> formal rigor or scientific analysis This may be a bit philosophical, but couldn't "formal methods" and the "scientific method" also be considered a best practice? (and thus susceptible to becoming a cult?) Throughout the history of science, there has been many methods for doing science that have since been revolutionized or abandoned (e.g. cosmology, non-Euclidean geometry, eugenics, quantum mechanics). Thomas Kuhn is a notable writer on such paradigm shifts in the history of science. [1] [1]: https://en.wikipedia.org/wiki/Paradigm_shift https://en.wikipedia.org/wiki/Paradigm_shift

Geminidog 6y ago
Yeah, and I openly admit I'm part of the cult. My bias does not allow me to think of a better way of verifying reality by assuming observation, probability and logic is recursively true. Is there anyone here that doesn't share my bias and if you don't, why?
megameter 6y ago
Postmodernism explored this in some capacity in the 20th century, because there are links between science, rationalism, and our ability to think rationally in practice: if we do irrational science and don't notice, the results are false but accepted as true - a phenomenon which has indeed occurred countless times, despite mechanisms intended to add rigor to the process. All that has to happen is for an emotional attachment to a concept to settle in, and our sense of causality goes out the window. A lot of our material progress comes simply from selecting different benchmarks and methods of observation.

carlmr 6y ago

When it comes to how to write code we're essentially faced with a usability problem. When we write an API function we want other people to use it. When we write internal functions we want other developers to use it. When we write programs we want some customer to use it. A lot of usability design has been somewhat formalized. We describe design in terms of signifiers, affordances, constraints, mappings and feedback. A lot the bad and best practices can be rephrased in these terms. If your program is "stringly" typed it's unclear which affordances your functions offer, that's bad. In OOP a lot is hidden from the user, if this is well done, you have constraints that keep you from doing something wrong, if it's badly done you have big objects with some state that's unobservable (lack of signifiers) so you can't understand what it does (lack of affordances). In FP you do this through function signatures, purity and strong typing. The type signature together with the function name can show you the affordances of the function. By constraining inputs and making outputs explicit (e.g. result types) you provide constraints and signifiers about their usage. A mapping is what we expect, e.g. from a knob. If you find 4 knobs and 4 hot plates on a stove, you instinctively know what they do. If the hot plates are somewhat shifted laterally against each other it becomes even easier to identify which knob is for each plate. In programming this could be the name of a function. A function called printX() shouldn't do anything except printing, otherwise it breaks the instinctive mapping that you expect. A function named isX() shouldn't return void. It should return a boolean. Of course you can't condense this down to a simple number, but at least you can describe why something is good or bad. The groundwork has been laid already.

domk 6y ago

What about the argument that programming entire large systems (e.g. non-trivial applications as opposed to only algorithms) is way too complex to be described rigorously? At least with our current tools? It's the price we pay for the amount we can do with software. It's very powerful but also orders of magnitude more complex than anything we can reason about formally.

zokier 6y ago
That is just a sign that we are trying to run before we can walk. They key is in your own comment: > At least with our current tools We should be aiming more towards making projects with a scope that we can actually manage, instead of trying to build huge castles of sand and failing spectacularly. And of course continue to improve our tools to properly manage more complexity.
- nine_k 6y ago
  I'm certain that brothers Wright did not have a rigorous mathematical model of their airplane. It is well known that Bell's telephone was invented by accident. I suspect we still lack a comprehensive theory of pizza-making. Sometimes you just hit a mother lode, and keep digging, preferably doing proper geological research along the way. But to postpone practical applications before a complete theory is ready is to lack business sense.
  - zokier 6y ago
    But we are not in Wright era of computing. We are in the 737 era, or should be. But somehow our methods are not tracking that. Experimentation has its place, but it should be followed by rigor which we are very much missing.
    - nine_k 6y ago
      I'm afraid we are still not even in the brothers Wright era of project planning, though. At least, im many areas. In some areas we (humans) have considerable successes, like building oil rigs in the ocean. I suspect we lack a good understanding of software requirements. From it, to my mind, inadequate management practices follow.

mianos 6y ago

This is not true. You see 'best practise' even in formally proven areas. This is because a formal proof does not mean there are not compromises when applied to the real world. What is the best sort? It depends on the size data you expect, locality, initial ordering. What about CAP? Pick two. Best practice is probably choosing a quicksort for now looking what happens. Maybe for CAP give up on immediate consistency. Best practice gives you a direction that will most likely get you to your destination. If you don't care about the destination you can take forever on the path.

Geminidog 6y ago
It is true, you're conflating things here. We've formalized how to define the "fastest" algorithm and for that we have definitive answers on what is faster and what isn't. Our notion of what is "best" is the thing here that has not been formalized. "Best" is a vague word it needs to be defined before it can even be formalized.
- mianos 6y ago
  What is the fastest sort?
  - Geminidog 6y ago
    I don’t know at the moment but the algorithm exists simply because every sorting algorithm we know about has a quantitative speed metric assigned to it called the Big Oh. Keep in mind that my claim is that we know how to define the fastest algorithm which is different from the claim that the field has found the fastest sorting algorithm that will ever exist. Either way for the fastest algorithm out of the set or sorting algorithms that are known.... Most likely it’s a family of algorithms that share the same speed metric of O(N). There may be an algorithm or several algorithms that are faster. Look it up, you might find it. What I can guarantee you can’t find is the best design pattern or style of programming. There is no theory here let alone a definition for “best.” It’s obvious your question is trying to take the conversation in some other direction. Let me try to guess it. Your probably going to talk about other intrinsic downfalls and costs to sorting outside of the speed metric like memory or the domain limitation for O(N) sorting algos. To which I respond memory has nothing to do with the speed of the algorithm and is off topic from my claim. We know the fastest algorithm(s) by definition, because the theory of what is faster and what is not is fully fleshed out. The theory on which is the best algorithm to use in a problem given the speed and memory cost is something we don’t have a theory for yet, hence the usage of best practices, which further proves my point. This is where you conflate things, you didn’t separate aspects of areas described by theory and aspects not yet described by theory. You mistakenly lumped everything together. Hopefully I anticipated your actions correctly and you are the one who is taught a lesson here rather then your intention of teaching me something via your trap question.

robotresearcher 6y ago

> formal rigor has been established. There's the best practice. It's such a strong and useful one that it doesn't feel optional any more.

brundolf 6y ago

I once heard someone say that Software Engineering as a field today is about where Chemistry was 300 years ago: it's just alchemy. Nobody actually knows how it works or what is or isn't best. Some people have tried some stuff out and formed different theories around their anecdotal experiences. Some of those theories sometimes translate to other cases; some of them are completely bonkers. There's no real way to tell one from the other, because there's no concrete shared reality. So instead people argue a lot and the best rhetorician usually wins.

AtlasBarfed 6y ago

Moreover "best" implies all measured domains, not just algorithimic efficiency (which itself can be split into a half-dozen concerns such as linear speed, ability to be distributed, memory use, disk use, suitability to input patterns, i.e. all the reasons there are hundreds of sorting algorithms). Code complexity? Ease of testing? Compatibility/leveraging of tools? Apropos for your programmer ability? Apropos for non-programmers if it crosses out of pure programming? Best practice is definitely a weasel word. Something that should be qualified with what is being optimized, what prompted its adoption, and comparisons to other approaches that highlight/justify its use. It also falsely implies there is no better candidate out there (another computer science irony: your "best practice" has been proven via magical super-turing computation to truly be the best ever?). It assumes false authority. Really, they are only good for setting a reasonable standard and moving forward rather than constant bikeshedding.

rstuart4133 6y ago

I've come across people using "best practice" as the sole justification for doing something in software engineering, but thankfully it's rare. Where it's not rare is medicine. You regularly hear the term spat out like a weapon, particularly in big hospitals. It's a very poor way to justify something. It's a statement of the obvious: everyone agrees you should use the best or most efficient way of doing something. What people don't agree on is what that is. So it's "we all agree we should be doing it the best way, and I say the best way is ...". You get no indication of why it's best practice, or how it's been chosen, or who chose it. Its more an appeal to authority. There is another term in medicine that's also bandied about frequently: "evidence based medicine". Unlike "best practice", it assums the obvious: everyone agrees we should be using the best way. It's telling you how the best way way chosen: from the evidence. More importantly it's also giving you permission to improve on it: find your own evidence. If you asked for to see evidence for "best practice", it's often seen as an attempt to undermine authority. If you asked to see the evidence behind evidence based medicine, the reaction your likely to see is "oh, you get it, here is what I have". When I hear "because it's best practice" or "this is best practice" now, I shudder. It's not an invitation to be part of a team working to produce the best outcome. It's telling you you're a minion, and you'd better follow the rules. But I think you are right in one sense, the reason we see it used far less in software development is we can often shoot something down with a few sentences of tightly reasoned logic. Evidence is often easy to come by. Medicine doesn't have that luxury, the body is too complex to reason about. It does have rigor and scientific analysis, but it takes a big studies and a lot of effort to gather.

Geminidog 6y ago
Agreed. There's a dichotomy here that a lot of people don't know about that might help you get a better picture of the distinction you mention. Logic and Science are different in the sense that Logic does not require any evidence. Logic uses simple assumptions called axioms and then theorems derived from those axioms to make broader statements about the system. A computer is basically a system molded around logic so that you can use logical reasoning to derive statements and ignore evidence. This is what I mean by "rigor." Ironically, for convenience, testing (aka science) is used in computer programming even though formal analysis is a stronger (but more challenging) form of proof. Science on the other hand is more evidence based. If evidence contradicts logic than the evidence takes precedence. The medical field is more science than it is logic hence the distinction. A computer programmer can use heavier reliance on axiomatic reasoning to derive statements but the medical field will defer more to the black box statistical results of evidence. The difference is literally the same difference between math and science. Computer Programming blurs the line a bit but overall programming is closer to axiomatic reasoning than it is to science.