3 ms·
What evidence exists that definitively says JavaScript is better than perl? Or golang is definitively better than python. There is no definitive evidence. You
by crimsonalucard 7y ago
What evidence exists that definitively says JavaScript is better than perl? Or golang is definitively better than python.
There is no definitive evidence.
You can't even prove that rust is definitively better than assembly language.
Hence where no evidence exists, decisions without evidence are made constantly.
You also need to realize that this not baffling. Collecting hard scientific evidence for every freaking detail is incredibally hard and time consuming. It's part of why the medical industry moves so slowly to get medicine out.
In fact any problem with the word design means that you are working on a problem with no definitive evidence pointing to a definitive solution. You are literally designing a possible solution out of thin air. There's a whole segment of people who do this, they are called ux and ui designers and a large portion of the the content they spit out is not evidence based at all.
- buboard 7y agoWhat evidence exists that definitively says JavaScript is better than perl? Or golang is definitively better than python. do people bother to gather the evidence though? like perhaps performance, number of bugs per coding day, quantity and quality of output etc.
- muzani 7y agoIs evidence helpful? At our workplace, it's clear that Cordova hybrid is worse than maintaining both iOS/Swift and Android/Kotlin, in terms of bugs, development time, hiring/retention cost, user experience. But we still do it. Sometimes it's just that there's less unknowns involved. A bug in Cordova might take a week to fix. A bug in Android or iOS might take 1-2 days. Statistically it would be a no brainer. But bugs are dreadful things and there's the possibility that it could take much longer than usual or go unnoticed.
- crimsonalucard 7y agoYou can't really say one piece of evidence is better than another piece of evidence unless you can quantify it in a meaningful way. Agile points are an example of something quantified in a way that isn't meaningful, while performance timing on an algorithm can be meaningful. Many things in programming languages like a for loop vs. recursion cannot be quantified meaningfully.
- ebcode 7y agoSome people do. Check out the works of Victor Basili and Barry Boehm.
- mntmoss 7y agoYou make an argument for empiricism, which is only one way of evaluating the truth of arguments. For example, mathematics traditionally doesn't involve empirical study: It begins with a pragmatic premise instead, like "assume the following..." and then proceeds to expand on that assumption or find its inherent contradictions. One of the "crises of mathematics" is that computerized proofs by exhaustion, by applying brute force to find all possibilities, make the field more empirical in nature and hence subject to experimental error. When pragmatic arguments are used to create a premise like "this design will work best for the software", the question that needs asking is whether all stakeholders can buy into the most core assumptions, and whether all assumptions retain conceptual coherence when taken together. If the UX designer, the developer, the product manager, and the end user agree on a pragmatic theory, and all theories in play align without issue, there isn't an problem as to whether it's "really" true - and with software, the concepts and data are thoroughly enmeshed in pragmatic thinking from the very beginning: numbers are modelled to limited ranges or precisions, strings are encoded according to arbitrary mappings, and so forth.
- thethirdone 7y ago> One of the "crises of mathematics" is that computerized proofs by exhaustion, by applying brute force to find all possibilities, make the field more empirical in nature and hence subject to experimental error. I would not describe using computer aided proofs as "more empirical in nature". Generally such proofs are held to the same standard as human proofs; there is not any "experimental error" that is not present in normal proof review. > When pragmatic arguments are used to create a premise like "this design will work best for the software", the question that needs asking is whether all stakeholders can buy into the most core assumptions, and whether all assumptions retain conceptual coherence when taken together. If the UX designer, the developer, the product manager, and the end user agree on a pragmatic theory, and all theories in play align without issue, there isn't an problem as to whether it's "really" true If your definition of "best" is something measurable in the real world, it doesn't matter what pragmatic theory is agreed upon. Only the systems that "really" achieve the best state are the best. Systems that rely on agreed upon assumptions, but fail to achieve their promises are not relevant. In simple terms, philosophy and mathematics doesn't matter if it fails to match reality.