
Swift: The joy of sequences - ingve
http://ericasadun.com/2016/06/08/swift-the-joy-of-sequences/
======
sago
> meaning you can build functions like this:

Is it just me, or is that code example incredibly byzantine? I know I'm only a
Swift dilettante, but that struck me as the kind of code we want to actively
avoid building.

The conceptual grouping, the syntactic grouping and the line layout grouping
seem to be carrying three contradictory messages about structure, requiring
careful parsing to grok.

~~~
BrutallyHonest
That's the biggest problem with adoption of academic-style (Haskell, OCaml
etc.) functional programming languages.

The proponents believe that 'shorter = more readable'.

And if they would try to make it more readable it would start looking like
Scala and C# (hence their popularity).

~~~
rubiquity
Don't blame Haskell, OCaml, etc. here. 90% of that syntax that is in the
example is Swift specific and I agree it is cluttered and ugly. Swift would do
better to stop trying to be like C/C++ and be more like ML (you can tell the
language wants to be like ML, but I'm guessing there are internal politics to
make it more C/C++-like for adoption reasons. There's even (or there were) a
few design documents hinting at intentionally being C like).

~~~
jlarocco
I don't think the OP was "blaming" Haskell and OCaml as much as he was blaming
the people trying to add Haskell and features and syntax to Swift and C++.

Haskell syntax works great for Haskell, because the whole language has
consistent syntax for things like lazy evaluation and lambda functions. The
problem is when people try to tack on those features to Swift or C++ and make
it work with the ugly syntax from those languages, it ends up making it even
uglier.

To me, the sample code looks like a bastardized mix of C++ and Haskell, and
it's pretty hard to figure out what it's doing, even in the toy code samples.

~~~
rubiquity
Great point. Thank you for bringing out the distinction in OP's post.

------
noelwelsh
Unfold in Swift? Seems like a good step. It's a bit annoying to use raw unfold
but it's easy enough to build utilities on top of it to capture common cases.
Get the primitives right and everything else becomes easy.

------
jdmichal
I'm not very familiar with Swift. If I'm understanding right, the `prefix`
function being defined is equivalent to LINQ's `TakeWhile` [0]. If so, the C#
version seems much easier to read to me:

    
    
        public static IEnumerable<T> TakeWhile<T>(
            this IEnumerable<T> source,
            Func<T, bool> predicate) {
    
            foreach(T value in source) {
                if (predicate(value))
                    yield return value;
                else
                    yield break;
            }
        }
    

Of course, there's a bunch of compiler magic going on here that's basically
creating a state machine, which seems to be explicit in the Swift version. Are
there any similar features in Swift to C#'s `yield`? If not, are any on the
road map?

[0] [https://msdn.microsoft.com/en-
us/library/bb534804%28v=vs.110...](https://msdn.microsoft.com/en-
us/library/bb534804%28v=vs.110%29.aspx)

~~~
fleshweasel
Beyond being a little more explicit about the generator semantics, it's just
_noisier_. "Self.Iterator.Element" is a lot of noise compared to "T".

At the moment, I feel these sequence extensions are just allowing people to
write toy programs with slightly less boilerplate, and are accomplishing
little as far as improving our ability to produce useful software.

