6 ms·
It's acceptable to state, without evidence, that functional programming and static typing make things more reliable. But this isn't a falsifiable claim. We can
by pizlonator 10mo ago
It's acceptable to state, without evidence, that functional programming and static typing make things more reliable.
But this isn't a falsifiable claim. We cannot possibly know if this is true or not.
- Not all of banking and telecom use functional programming or even static typing.
- Functional programming often leads to write-only incomprehensible code; the exact opposite of what you need to have a reliable system.
- There's no hard evidence that static typing improves reliability. Only vibes and feels.
- dionian 10mo agoIt improves reliability at compile time, certainly
- ux266478 10mo ago> There's no hard evidence that static typing improves reliability. I'm curious how you came to that conclusion? https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf https://www.deepdyve.com/lp/springer-journals/an-empirical-study-on-the-impact-of-static-typing-on-software-0ZImQZ508o https://www.deepdyve.com/lp/springer-journals/an-empirical-s...
- rastrian 10mo agoI was searching for the Stefik article to argue here, thank you.
- pizlonator 10mo agoI don't consider a human subjects study to be "hard evidence". So, we can safely disregard these papers. They got exactly the result that they sought out to get, and the papers were published because they confirmed the preexisting groupthink.
- rowanG077 10mo agoInteresting, so you consider the entire scientific field of medicine to work without hard evidence?
- pizlonator 10mo agoYou mean psychology? There’s no hard evidence there. The papers you’re citing are using human subjects in that sort of way. It’s pseudoscience at best Medicine that involves testing human subject response to treatments is very different from the papers you’re citing and does involve falsifiable theses (usually, definitely not always).
- rowanG077 10mo agoI didn't link any studies. I'm not the person you originally replied to. I was trying to engage in your point that studies involving human subjects cannot contain hard evidence. And no I wasn't referring to psychology in my comment.
- pizlonator 10mo agoThen you’re changing context for no reason. My point about human subjects is in the context of the linked studies. I’m not super interested in further debating human subjects in science generally
- zephen 10mo agoIf you're going to start citing research, you should look at the Cooley finding on verilog vs VHDL.
- therealcamino 10mo agoThat's certainly an interesting data point, but it was a 90 minute programming contest, not peer-reviewed research.
- zephen 10mo agoThe second paper shown above is firewalled. The first paper shown above was presented at ICPC, which has a history of bias in reviewing, and typically only assigns one or two reviewers in any case. Which makes it not surprising that the paper itself doesn't really prove anything, except that the authors themselves are good at creating dissimilar situations. Subjects had to modify existing systems, which were provided by the experimenters. The experimenters deliberately removed any semblance of anything that might hint at types (comments, variable names, etc.) and did who the fuck knows what else to the dynamically typed code to make it difficult to work with. They also provided their own IDE and full environment which the participants had to use. Now, of course, we've all seen the graphs which show that for simple problems, dynamic is better, and there's a crossover point, and, of course Cooley's experiment is on the far left of that graph, so it certainly doesn't prove that strict static typing isn't better for large programs, but it's at least honest in its approach and results, using self-selected working practitioners (and there was never any shortage of working practioners swearing by how much better VHDL is). https://danluu.com/verilog-vs-vhdl/ https://danluu.com/verilog-vs-vhdl/
- patrickmay 10mo agoThe benefits of static typing with regard to reliability are unclear, at best: https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/
- threethirtytwo 10mo agoWait. This doesn’t make sense to me. Statically typed programming languages cannot be deployed nor can they run with a type error that happens at runtime. Untyped languages CAN run and error out with a type error AT runtime. The inevitable consequence of that truth is this: In the spectrum of runtime errors statically typed languages mathematically and logically HAVE less errors. That by itself is the definition of more reliable. This isn’t even a scientific thing related to falsifiability. This comes from pure mathematical logic. In science nothing can be proven, things can only be falsified. But in math and logic things can be proven and it is provable that static types are more reliable than untyped. It is definitely not vibes and feels. Not all of banking uses statically typed languages but they are as a result living with a less reliable system then the alternative and that is a logical invariant. There are many reasons why someone would choose untyped over typed but reliability is not a reason why they would do this unless they are ignorant.
- Spivak 10mo ago> Statically typed programming languages cannot be deployed nor can they run with a type error that happens at runtime. This is so completely untrue that I'm confused as to why anyone would try to claim it. Type Confusion is an entire class of error and CVE that happens in statically typed languages. Java type shenanigans are endless if you want some fun but baseline you can cast to arbitrary types at runtime and completely bypass all compile time checks. I think the disagreement would come additionally by saying a language like Ruby doesn't actually have any type errors. Like how it can be said that GC languages can't have memory leaks. And that this model is stronger than just compile time checking. Sure you get a thing called TypeError in Ruby but because of the languages dynamism that's not an error the way it would be in C. You can just catch it and move. It doesn't invalidate the program's correctness. Ruby is so safe in it's execution model that Syntax Errors don't invalidate the running program's soundness.
- akkad33 10mo ago> Java type shenanigans are endless if you want some fun but baseline you can cast to arbitrary types at runtime and completely bypass all compile time checks. For this reason Java is a bad example of a typed language. It gives static typing a bad rep because of its inflexible yet unreliable type system (only basic type inference, no ADTs, many things like presence of equality not checked at compile time etc ) Something like ocaml or fsharp have much more sound and capable type systems.
- wiseowise 10mo ago> Functional programming often leads to write-only incomprehensible code; the exact opposite of what you need to have a reliable system. In what language?
- bonesss 10mo agoFunctional programming makes DSLs easier/possible, so you express your domain in natural domain language/constructs leading to easier comprehension, standardization, reuse, and testing, thereby improving reliability. This is the exact opposite of write-only code, DSLs are comprehensible/editable to non-programmers. With a strong enough type system these benefits accrue while ensuring the program in stays a subset of more correct programs than allowed by other compilers. … I mean, if we’re just making global assertions :) Gimme the “write only” compiler verified exhaustively pattern matched non-mutable clump in a language I can mould freely any day of the week. I will provide the necessary semantic layer for progress backed with compiler guarantees. That same poop pile in a lesser language may be unrecoverable.
- xpe 10mo ago> ... functional programming and static typing make things more reliable. > But this isn't a falsifiable claim. Saying "this isn't falsifiable" is a wild claim. Indeed the claim "functional programming and static typing make things more reliable" is falsifiable, as long as you admit a statistical understanding. The world is messy and experiments have noise, so what would you use if not statistics? Anecdotes?: no. Purely deductive methods?: no; we should not expect any single technique to be a silver bullet. Good studies and analyses lay out a causal model and use strong methodologies for showing that some factor has a meaningful impact on some metric of interest. I recommend this as a starting point [1] [1]: https://yanirseroussi.com/2016/05/15/diving-deeper-into-causality-pearl-kleinberg-hill-and-untested-assumptions/ https://yanirseroussi.com/2016/05/15/diving-deeper-into-caus...
- garethrowlands 10mo agoCitation needed.