4 ms·

Loops make your life worse, really? Loops are trivial code that are nearly impossible to screw up. Writing a loop and writing map/filter probably take nearly t

by NateDad 12y ago

Loops make your life worse, really? Loops are trivial code that are nearly impossible to screw up. Writing a loop and writing map/filter probably take nearly the same time. If this is the biggest problem you have in coding, you're luckier than most.

Touche 12y ago
Loops are very easy to screw up loops because it throws mutation into the mix.
- kyrra 12y ago
  How do you mean exactly? Go has an iterable for map, slices, arrays, strings, channels with the "range"[0] keyword. The values returned by range are copies of whatever is in the structure so they should be immune to mutation (unless you're messing with pointers). [0] http://golang.org/ref/spec#RangeClause http://golang.org/ref/spec#RangeClause
  - rakoo 12y ago
    He means that what you actually want to do is modify some state outside of the loop when you're iterating, which means that your loop doesn't provide a "safe" context where you know what to expect. Are you sure you're modifying the correct outside variable ? Are you sure you really are modifying it: bar[i] = f(foo[i]) and not creating a new one: bar[i] := f(foo[i]) ? Are you sure you're not also modifying another variable that you didn't know was "linked" somehow ? Given the direction Go has taken, it would make very little sense to introduce functional programming bits. But you must admit that the immutability/lack of side effects of the FP gives you a lot of assurance on what to expect.
    - kyrra 12y ago
      I think you need to provide an example of what you're trying to say, as the syntax you showed above is not valid. the := operator is for defining a new variable, not for creating a new instance of some type. The := operator is just shorthand. foo := 5 is shorthand for: var foo int foo = 5 the "range" keyword over an array gives you the index and the value at that index. If you don't need the index or the value, you can put a "_" in it's place (to save on the allocation). http://play.golang.org/p/Z2ejUlN5An http://play.golang.org/p/Z2ejUlN5An You'll notice that foo[i] is still printing "0", because range always creates a copy of the object assigned into v. Unless you start using pointers, you'll never have mutation issues.
    - NateDad 12y ago
      bar[i] := <anything> won't compile. You can only assign to slice/array indices.
- AnimalMuppet 12y ago
  If composability, avoiding mutation, and eliminating loops are the focus of what you want from a language, then Go is definitely not trying to solve your problems. But maybe, rather than just carping, you should wait until you really understand why Go is trying to solve the problems that it is actually trying to solve. Because I don't think you do understand that yet. Go is trying to solve the kinds of problems you run into when you have a multi-million-line code base that you have to maintain over two or three decades. At that scale, you get new problems - not just more of the same old programming-in-the-small problems. I'll give you this much, though: Loops are easier to screw up than the grandparent seems to recognize.
  - Touche 12y ago
    Mutation is a problem that every program must deal with. Map/filter/reduce and company are just a good way to isolate mutation. Your entire application doesn't need be functional to benefit from some functional behavior. Likewise, composability improves readability and isolates code into small parts that can be assembled. This is beneficial to large applications as well. You seem to indicate that concurrency is the only problem worth investing in with large applications but they are not mutational exclusive. Erlang does a good job of both, for example.
    - AnimalMuppet 12y ago
      I never said that concurrency was the only problem with large applications. I never even meant to imply it. For example, one of the big problems is circular dependencies. Go solves this by explicitly prohibiting it - your dependencies must form a directed acyclic graph. You therefore have to work out a solution the moment you would want to introduce a circular dependency. You can't introduce even the first one. That means that you can never build up the kind of nightmarish hairball that large projects often turn into. Is it painful to have to prevent circular dependencies all along the line? Certainly. But it prevents more pain later. Now: Do I know that functional programming, map/filter/reduce, and avoiding mutation cause problems at scale? No, I don't. On the other hand, I doubt many projects have been built using FP at this scale, so one can't assert that FP will scale this far.
findjashua 12y ago
Personal preference, I guess. My experience is that Python/Underscore collections API makes data processing much easier.

by NateDad 12y ago

Touche 12y ago

Loops are very easy to screw up loops because it throws mutation into the mix.

kyrra 12y ago
How do you mean exactly? Go has an iterable for map, slices, arrays, strings, channels with the "range"[0] keyword. The values returned by range are copies of whatever is in the structure so they should be immune to mutation (unless you're messing with pointers). [0] http://golang.org/ref/spec#RangeClause http://golang.org/ref/spec#RangeClause
- rakoo 12y ago
  He means that what you actually want to do is modify some state outside of the loop when you're iterating, which means that your loop doesn't provide a "safe" context where you know what to expect. Are you sure you're modifying the correct outside variable ? Are you sure you really are modifying it: bar[i] = f(foo[i]) and not creating a new one: bar[i] := f(foo[i]) ? Are you sure you're not also modifying another variable that you didn't know was "linked" somehow ? Given the direction Go has taken, it would make very little sense to introduce functional programming bits. But you must admit that the immutability/lack of side effects of the FP gives you a lot of assurance on what to expect.
  - kyrra 12y ago
    I think you need to provide an example of what you're trying to say, as the syntax you showed above is not valid. the := operator is for defining a new variable, not for creating a new instance of some type. The := operator is just shorthand. foo := 5 is shorthand for: var foo int foo = 5 the "range" keyword over an array gives you the index and the value at that index. If you don't need the index or the value, you can put a "_" in it's place (to save on the allocation). http://play.golang.org/p/Z2ejUlN5An http://play.golang.org/p/Z2ejUlN5An You'll notice that foo[i] is still printing "0", because range always creates a copy of the object assigned into v. Unless you start using pointers, you'll never have mutation issues.
  - NateDad 12y ago
    bar[i] := <anything> won't compile. You can only assign to slice/array indices.
AnimalMuppet 12y ago
If composability, avoiding mutation, and eliminating loops are the focus of what you want from a language, then Go is definitely not trying to solve your problems. But maybe, rather than just carping, you should wait until you really understand why Go is trying to solve the problems that it is actually trying to solve. Because I don't think you do understand that yet. Go is trying to solve the kinds of problems you run into when you have a multi-million-line code base that you have to maintain over two or three decades. At that scale, you get new problems - not just more of the same old programming-in-the-small problems. I'll give you this much, though: Loops are easier to screw up than the grandparent seems to recognize.
- Touche 12y ago
  Mutation is a problem that every program must deal with. Map/filter/reduce and company are just a good way to isolate mutation. Your entire application doesn't need be functional to benefit from some functional behavior. Likewise, composability improves readability and isolates code into small parts that can be assembled. This is beneficial to large applications as well. You seem to indicate that concurrency is the only problem worth investing in with large applications but they are not mutational exclusive. Erlang does a good job of both, for example.
  - AnimalMuppet 12y ago
    I never said that concurrency was the only problem with large applications. I never even meant to imply it. For example, one of the big problems is circular dependencies. Go solves this by explicitly prohibiting it - your dependencies must form a directed acyclic graph. You therefore have to work out a solution the moment you would want to introduce a circular dependency. You can't introduce even the first one. That means that you can never build up the kind of nightmarish hairball that large projects often turn into. Is it painful to have to prevent circular dependencies all along the line? Certainly. But it prevents more pain later. Now: Do I know that functional programming, map/filter/reduce, and avoiding mutation cause problems at scale? No, I don't. On the other hand, I doubt many projects have been built using FP at this scale, so one can't assert that FP will scale this far.

findjashua 12y ago

Personal preference, I guess. My experience is that Python/Underscore collections API makes data processing much easier.