The general value of typed functional programming lies in leaving no edge cases
1–10 of 172 posts
Re: The general value of typed functional programming lies in leaving no edge cases
#2Edge case removed:
for i=0 to 10 {print(a[i])} vs for x in a {print(x)}
a.filter {}.map{print}
Pseudo code, of course. I list several “functional“ examples in Swift here:
https://github.com/melling/SwiftCookBook/blob/master/functio...
Functional programming is also a higher level language. map, reduce,filter, flatten, flapMap, drop, take, zip, ...
Learn the concepts in one language and they can be used in another functional language.
Re: The general value of typed functional programming lies in leaving no edge cases
#3The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements.
I've seen this over and over in my career; tools can make people lazy in certain areas, it can put them on auto-pilot. Often, this can be a bad thing.
I like coding with dynamic languages because they get out of my way and shift the full responsibility for correctness on me. This creates a certain mental tension which helps me to perform. Keeps me alert and mindful.
I particularly try to avoid languages that make me wait for code to compile (which is more common with statically typed languages); this is for the same reason why don't like it when someone distracts me while I'm "in the zone" while coding.
Re: The general value of typed functional programming lies in leaving no edge cases
#4Forget the performance or the fancy memory management stuff, this is one of the best things about Rust: it makes you deal with edge cases by default (while allowing you to write code in a largely imperative or functional-lite style).
It's why I think it competes for market share with some of what is currently Java/C# and similar languages. A lot of people who use those languages care about correctness, and Rust is big step up in this regard.
Re: The general value of typed functional programming lies in leaving no edge cases
#5The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements. I've seen this over and over i…
Isn't this akin to saying I don't like wearing seatbelts because it makes me more complacent in my driving?
Re: The general value of typed functional programming lies in leaving no edge cases
#6The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements. I've seen this over and over i…
This is the opposite of my experience. In practice, being forced to deal with edge cases makes you find implementations that eliminate them because dealing with each is painful.
Re: The general value of typed functional programming lies in leaving no edge cases
#7The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements. I've seen this over and over i…
This is a wrong and surface-level reading of the original post. If there are "cases" in a system, then there are going to be "edge-cases" as well. The problem is in classifying certain cases as "edge" and others as regular. We do this because the regular cases are very obvious and are either the perfect happy-path, or a failure condition that we would immediately consider.
But between these two exist a permutation of conditions that exists in the domain and often manifest in production. Either we can actively manage them thanks to types, or we can let it end up in production with hard-to-track bugs.
Re: The general value of typed functional programming lies in leaving no edge cases
#8The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements. I've seen this over and over i…
Or perhaps it forces you to be alert and mindful of things that add no value, such as manually remembering to handle every edge case, and takes away focus from the problem in question?
Re: The general value of typed functional programming lies in leaving no edge cases
#9The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements. I've seen this over and over i…
[deleted]
Re: The general value of typed functional programming lies in leaving no edge cases
#10The goal of software development should be about reducing the number of edge cases to the absolute minimum. If a tool makes it easier to keep track of all edge cases, it is bound to encourage developers to write code which contains more edge cases. But fundamentally, it still reduces code quality. Code with more edge cases is less flexible and not good at handling changing requirements. I've seen this over and over i…
Isn't this akin to saying I don't like wearing seatbelts because it makes me more complacent in my driving?
It could actually be the case that seat-belts make drivers more complacent but the key difference in the case of coding is that you won't die if you make a typo in your code. If designed correctly, your tests will catch it anyway.