4 ms·

YAGNI 99% of problems one encounters while programming can be solved in C++ with std::vector and functions taking a vector in and producing a vector out. That'

YAGNI 99% of problems one encounters while programming can be solved in C++ with std::vector and functions taking a vector in and producing a vector out. That's my main problem with FP and many other language making bold claims: oversell. That simple fact is that for most computing tasks, you don't meed much more than simple types.

ryanianian 7y ago
C++ is not a purely functional language, but the type-system is (caveat WIP things like concepts). Even if all you're doing is "vector-in, vector-out", the types of those vectors matters immensely. This is especially true in languages like C++ where the type-system is very deep but also very hard to debug or change at varying levels of abstraction.
talaketu 7y ago
Heck, even a turing machine could solve most of these problems.
- mc3 7y ago
  How highfalutin! It's x86 assembly for me!
  - temp1999 7y ago
    x86 is more complex than a Turing machine.
herbstein 7y ago
Yeah.... You're probably right. Let's not talk about the meta-structures of our programs, but just use those structures. Sure. I might be using a monad and the bind function every single day, but acknowledging any useful repetition of patterns is never useful. That's why no successful programmer has ever even given a thought to design patterns. /s Why is it that people are alright with identifying and naming the pattern of a single global instance of a type - i.e. a singleton, but as soon as you identify a pattern of type signatures you're instantly thought of as looney and overselling?
tel 7y ago
You don't. Of course. Honestly, you don't need much more than a really big chalk board to solve most problems one encounters when programming. Even that's probably strictly optional if you get enough people to double check the work. Sarcasm aside, what you're often doing when you make these transformations of std::vectors are structured algorithms. The structures of these algorithms can often be factored through operations performed on types—even if they're just all different names for the same std::vector! These structures exist to give words and patterns to the stuff we do. To make it easier to talk about, share, reflect upon, improve. To make it easier to judge how different approaches to the same end relate and can improve upon one another. You don't have to go use Haskell to get a LOT of benefit out of algebraic and equational reasoning. And I feel pretty unsure what to think about a philosophy where one would avoid a nice tool merely because it's possible to get along without it? I imagine you're a fan of that Primitive Technology YouTube channel?
mc3 7y ago
I agree with you to some extent, but picking it apart: 1. I think there is value in immutable data structures. Languages like Haskell and Elm make everything immutable by default. A big problem I find in C#, JavaScript (and I'm sure you'd get in C++) is if I return a List of something, even if the list is readonly, the consumer could modify the items, unless I go to some tedious lengths to make sure the list only contains immutable objects. Also if I compute something based on a reference to an object, I cannot be sure that what the reference represents hasn't changed later in the program. 2. The algebraic data type produces very nice tight data structures and makes it easier to create data structures that can't hold invalid values. And where this is not possible you can use techniques to hide/product the data - usually by hiding the constructor, and requiring a function to make the type. You can do this in OO with classes, but the fact that any reference can be null causes issues, also if you return anything from your class that isn't immutable then you are passing out a potential backdoor to f' your state. See React and the hoops you have to jump through to keep things immutable. You can absolutely get stuff done without FP, but I like the abstractions and guarantees it brings. Less to go wrong, and less to think about overall (once you have carefully planned your types). What I don't like about FP, or Haskell in particular is the very complex types people dream up and all the crazy GHC extensions which are hard to understand and produce the most unhelpful of error messages if you make a mistake. Elm is more my kind of thing - very simple type system but still algebraic, no forced nulls etc. Gives you the 80% benefit of FP for 20% of the effort. When I read an Elm program from someone else I don't have to think much. Reading a Haskell program I need to learn a lot to understand it. Maybe Haskell is OK if you are doing it full time and can commit all that stuff to long term memory.
crimsonalucard 7y ago
If you seek to simply solve a problem then there are a number of ways to do so. If you seek to solve a problem with a solution that has the best design, the least technical debt and almost no bugs. Then FP with ADTs is the closest thing I've encountered to such a solution.
gnulinux 7y ago
100% of problems one encounters while programming can be solved with C with goto. What's your point?

ryanianian 7y ago

C++ is not a purely functional language, but the type-system is (caveat WIP things like concepts). Even if all you're doing is "vector-in, vector-out", the types of those vectors matters immensely. This is especially true in languages like C++ where the type-system is very deep but also very hard to debug or change at varying levels of abstraction.

talaketu 7y ago

Heck, even a turing machine could solve most of these problems.

mc3 7y ago
How highfalutin! It's x86 assembly for me!
- temp1999 7y ago
  x86 is more complex than a Turing machine.

herbstein 7y ago

Yeah.... You're probably right. Let's not talk about the meta-structures of our programs, but just use those structures. Sure. I might be using a monad and the bind function every single day, but acknowledging any useful repetition of patterns is never useful. That's why no successful programmer has ever even given a thought to design patterns. /s Why is it that people are alright with identifying and naming the pattern of a single global instance of a type - i.e. a singleton, but as soon as you identify a pattern of type signatures you're instantly thought of as looney and overselling?

tel 7y ago

You don't. Of course. Honestly, you don't need much more than a really big chalk board to solve most problems one encounters when programming. Even that's probably strictly optional if you get enough people to double check the work. Sarcasm aside, what you're often doing when you make these transformations of std::vectors are structured algorithms. The structures of these algorithms can often be factored through operations performed on types—even if they're just all different names for the same std::vector! These structures exist to give words and patterns to the stuff we do. To make it easier to talk about, share, reflect upon, improve. To make it easier to judge how different approaches to the same end relate and can improve upon one another. You don't have to go use Haskell to get a LOT of benefit out of algebraic and equational reasoning. And I feel pretty unsure what to think about a philosophy where one would avoid a nice tool merely because it's possible to get along without it? I imagine you're a fan of that Primitive Technology YouTube channel?

mc3 7y ago

I agree with you to some extent, but picking it apart: 1. I think there is value in immutable data structures. Languages like Haskell and Elm make everything immutable by default. A big problem I find in C#, JavaScript (and I'm sure you'd get in C++) is if I return a List of something, even if the list is readonly, the consumer could modify the items, unless I go to some tedious lengths to make sure the list only contains immutable objects. Also if I compute something based on a reference to an object, I cannot be sure that what the reference represents hasn't changed later in the program. 2. The algebraic data type produces very nice tight data structures and makes it easier to create data structures that can't hold invalid values. And where this is not possible you can use techniques to hide/product the data - usually by hiding the constructor, and requiring a function to make the type. You can do this in OO with classes, but the fact that any reference can be null causes issues, also if you return anything from your class that isn't immutable then you are passing out a potential backdoor to f' your state. See React and the hoops you have to jump through to keep things immutable. You can absolutely get stuff done without FP, but I like the abstractions and guarantees it brings. Less to go wrong, and less to think about overall (once you have carefully planned your types). What I don't like about FP, or Haskell in particular is the very complex types people dream up and all the crazy GHC extensions which are hard to understand and produce the most unhelpful of error messages if you make a mistake. Elm is more my kind of thing - very simple type system but still algebraic, no forced nulls etc. Gives you the 80% benefit of FP for 20% of the effort. When I read an Elm program from someone else I don't have to think much. Reading a Haskell program I need to learn a lot to understand it. Maybe Haskell is OK if you are doing it full time and can commit all that stuff to long term memory.

crimsonalucard 7y ago

If you seek to simply solve a problem then there are a number of ways to do so. If you seek to solve a problem with a solution that has the best design, the least technical debt and almost no bugs. Then FP with ADTs is the closest thing I've encountered to such a solution.

gnulinux 7y ago

100% of problems one encounters while programming can be solved with C with goto. What's your point?