Hacker News Reader

Comment by melling | Hacker News Reader

Edge case removed:

   for i=0 to 10 {print(a[i])} vs for x in a {print(x)}

With functional programming it gets even better:

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.

View on HN

A lot of those concepts were already in Smalltalk.

    a do: [:x|  Transcript print: x ]
    [] = closure

That is, because Smaltalk was based on Lisp. But the other OO languages removed this concept, but it came back in Scala.

The problem in my domain, games, is the frequent boxing and unboxing of values when using functional iterator interfaces in languages common to the industry, particulalry C#. It just thrashes the heap and forces often too-frequent gc.

While it may or may not be optimal for you/your field for other reasons, I believe Rust does iterators in a 0-cost, no allocation way and generally generates code equivalent to or better than a hand-written for loop.

There are studios moving to rust, and there definitely is a great amount of interest in rust among my peers because of the 0-cost iterator features. The borrow-checking isn't even a big draw, it's the other features!

I was under the impression that the way C# did generics meant that there was no need to box values. (Unlike Java, which treats all values as objects, even value types.)

C# has value types and many things are value types but certain things are not. Core library interfaces are implemented as with Object enumerator types for example. This causes IList.GetEnumerator() to return a boxed type. Its smart enough to use the value type when it knows it can though, such as List.GetEnumerator().

Lambdas have some allocations. I like LINQ but it can have some allocation as well.

These are all tiny allocations but in a game you'd like to strive for 0 allocations.

Two ways to interpret boxing here:

1 Storing a primitive as a first class object

2 packaging and repackaging data

There may be situations where the former is not an issue, but the latter often is. If you don’t have a way to treat filter() as a generator/coroutine it means your traversing one collection and inserting those values into another, only to pass it to map() which iterates again and creates a third. If you’re doing that once a frame, maybe not a big deal. Three times per object per frame? That’s a lot of temporary data structures.

If the other responder is right, I speculate that the borrow checker forced someone’s hand in Rust and they found that a generator keeps the borrowed objects on the call stack where they already had tools to track ownership.

Correct usage of IEnumerable helps a lot, as well as the magic that Linq can do with expressions.

In my experience, the trick is to remove `using Linq` from the entire project.

As someone who has had a mild case of Linq jealousy for some time, I’m curious what makes you averse.

It's too easy to fall into the temporary collection trap you described; on a large project with many developers, allowing Linq is a bit like leaving a toaster plugged in beside the pool.

I program mainly in C++, and I often start off writing things as:

    for (auto x : someContainer) { //do something with x }

But inevitably, I end up needing either an iterator pointing to a particular item at the end, or I need an index to pass to some other function, and this style makes that impossible. Perhaps it's just the domain I work in, but even after years of trying to make this work, it still only works about half the time for what I'm doing.

http://p3rl.org/each

while (my ($index, $value) = each @list) { ... }

https://docs.raku.org/routine/kv#class_List

for @list.kv -> $index, $value { ... }

In Haskell

   map someFunction listOfValue

if you need an index:

   map someOtherFunction (zip [0..] listOfValues)

Python uses 'enumerate' to similar effect. Not sure if C++ has an equivalent?

You can also use:

  zipWith someOtherFunction [0..] listOfValues
  # , since someOtherFunction is likely to be
  # :: (Int -> Value -> Stuff) rather than
  # :: ((Int,Value) -> Stuff) .
  
  zipIndex f = zipWith f [0..]
  # is also often useful.

Yes. I wanted to keep things simpler for people who don't speak Haskell; and show off composition of simpler combinators to build more exciting things at the same time.

In eg OCaml you have to use something like zipIndex (but implemented differently) or mapWithIndex, because they don't do lazy data structures by default. (And in eg Python their lazy sequences come with lots of caveats because they are not referentially transparent.)

Why not just pass the reference instead of an iterator or index? That’s what I do the best majority of the time. It’s rare that I actually need a specific iterator or pointer.

Just change your loop to auto& x.

While it does remove edge cases, the code also becomes more opaque. At least to me, functional style programming seems much harder to read and then reason about.

It's subjective. My experience is exactly the opposite. A pipeline of sequence operations is something I can skim at a glance, but a for-loop is a pile of code that I need to stare at before I understand what it represents.

This does not invalidate your experience. It's common, and with good reason. This sort of dissimilar experience with the same code is why coding standards need to be views as social norms for the team using them, and not just technical things.

The problem with loops is that they are too powerful. They can do almost anything.

The functions map and filter are nice and restricted. If you want more power, you use eg a fold. And if you need even more power, you write a new recursive function.

So a quick look at the code will tell you what to expect.

Personally I've found that although this argument sounds good in theory, in practice I don't find loops harder to read than chains of combinators.

Which languages are you reading them in?

For me the argument holds in practice as well. I'm mostly reading my combinators in Haskell, and the loops in Python or some curly brace language.

If you use a general purpose combinator like mapAccumL that has almost as much power as a loop, you don't get that much extra readability compared to the loop.

It's still a bit better, because that combinator still has to process one element of your list for each run through it's "body"; and it clearly warns you by it's very name that it's not just a filter or map, so there's less possibility of confusing it for something simpler.

And, of course, not all loops are created equal. When applicable, for-each loops are much cleaner than classic C-style for-loops for example.

It takes some time to get used to and change mental model from "program describes step by step what to do" to "program describes logical flow of information".

I moved from first camp to the second one somewhere during my adult life. And IMO: Both are valid, sometimes first one is necessary (because that's how the machines actually work), but second one is clearly better most of the time for humans, especially in business-logic heavy cases.

There's an analogous switch in algebra from notation like f(g(x)) to something more like X_{GF} (where the _{} indicates subscripting, not written symbols). Note the better left-to-right ordering in the terser system.

It's the same dichotomy; are you thinking of f(x) as an instruction to do f to x, or are you thinking of X_F as what happens when X goes through F?

Depends. Though some black-boxing is intended: thanks to enforced information hiding the compiler (and you) can make additional assumptions about what your code can not do.

This is a learning thing, honestly. Once you start thinking in types, it clicks: you're thinking at a higher level of abstraction, so the code is less important than understanding how the programmer put the types together in their head to solve a problem.

But I am already thinking about what the code should do. The problem is that if I read functional code I get bogged down in the details of what limits are set by the operations, because they're usually not as explicit. It's like reading a chain of functions on some element (actually, it quite literally is that).

Reply on news.ycombinator.com