Haskell is a beautiful language, but in my admittedly limited experience it’s been quite hard to reason about memory usage in deployed software (which is important because programs run on physical hardware. No matter how beautiful your abstract machine, you will run into issues where the assumptions that abstraction makes don’t match reality).
That’s not to say more robust programming languages aren’t possible. IMO rust is quite nice, and easily interoperable with a lot of existing code, which is probably a major factor in why it’s seeing much higher adoption.
But to echo and build off what @ustice said earlier:
The hard part of programming isn’t writing a program that transforms simple inputs with fully known properties into simple outputs that are meet some known requirement. The hard parts are finding or creating a mostly-non-leaky abstraction that maps well onto your inputs, and determining what precise machine-interpretable rules produce outputs that look like the ones you want.
Most bugs I’ve seen come at the boundaries of the system, where it turns out that one of your assumptions about your inputs was wrong, or that one of your assumptions about how your outputs will be used was wrong.
I almost never see bugs like this
My sort(list, comparison_fn) function fails to correctly sort the list”
My graph traversal algorithm skips nodes it should have hit
My pick_winning_poker_hand() function doesn’t always recognize straights
Instead, I usually see stuff like
My program assumes that when the server receives an order_received webhook, and then hits the server to fetch the order details from the vendor’s API for the order identified in the webhook payload, the vendor’s API will return the order details and not a 404 not found”
My server returns nothing at all when fetching the user’s bill for this month, because while the logic is correct (determine the amount due for each order and sum), this particular user had 350,000 individual orders this month so the endpoint takes >30 seconds, times out, and returns nothing.
The program takes satellite images along with Metadata that includes the exact timesamp, which satellite took the picture, and how the satellite was angles. It identifies locations which match a specific feature, and spits out a latitude, longitude, label, and confidence score. However, when viewing the locations on a map, they appear to be 100-700 meters off, but only for points within the borders of China (because the programmer didn’t know about GCJ-02)
Programming languages that help you write code that is “correct” mostly help prevent the first type of bug, not the second.
Another thing that Haskell would not help you at all with is making your application good. Haskell would not force obsidian to have unbreakable references.
Haskell is a beautiful language, but in my admittedly limited experience it’s been quite hard to reason about memory usage in deployed software (which is important because programs run on physical hardware. No matter how beautiful your abstract machine, you will run into issues where the assumptions that abstraction makes don’t match reality).
That’s not to say more robust programming languages aren’t possible. IMO rust is quite nice, and easily interoperable with a lot of existing code, which is probably a major factor in why it’s seeing much higher adoption.
But to echo and build off what @ustice said earlier:
The hard part of programming isn’t writing a program that transforms simple inputs with fully known properties into simple outputs that are meet some known requirement. The hard parts are finding or creating a mostly-non-leaky abstraction that maps well onto your inputs, and determining what precise machine-interpretable rules produce outputs that look like the ones you want.
Most bugs I’ve seen come at the boundaries of the system, where it turns out that one of your assumptions about your inputs was wrong, or that one of your assumptions about how your outputs will be used was wrong.
I almost never see bugs like this
My
sort(list, comparison_fn)function fails to correctly sort the list”My graph traversal algorithm skips nodes it should have hit
My
pick_winning_poker_hand()function doesn’t always recognize straightsInstead, I usually see stuff like
My program assumes that when the server receives an
order_receivedwebhook, and then hits the server to fetch the order details from the vendor’s API for the order identified in the webhook payload, the vendor’s API will return the order details and not a 404 not found”My server returns nothing at all when fetching the user’s bill for this month, because while the logic is correct (determine the amount due for each order and sum), this particular user had 350,000 individual orders this month so the endpoint takes >30 seconds, times out, and returns nothing.
The program takes satellite images along with Metadata that includes the exact timesamp, which satellite took the picture, and how the satellite was angles. It identifies locations which match a specific feature, and spits out a latitude, longitude, label, and confidence score. However, when viewing the locations on a map, they appear to be 100-700 meters off, but only for points within the borders of China (because the programmer didn’t know about GCJ-02)
Programming languages that help you write code that is “correct” mostly help prevent the first type of bug, not the second.
Another thing that Haskell would not help you at all with is making your application good. Haskell would not force obsidian to have unbreakable references.