Hacker News Reader

This is an interesting example of emotional frustration pretending to be a technical argument. I'm fascinated by the mechanics of irrational hype and subjective downward spirals of dissatisfaction on technical topics. It's very similar to how many people consider the best music of all time to be the one made by their own generation or what they grew up with through their parents. Most of us are employed by building more and better options and features, but as a community there is a streak of what I call cranky senior developer that is just tired of all the new features and would like it tear it all down. You can also call it "complexity fatigue".

I don't use Swift full time and I had no problem reading that method signature.

This is something that you would write if you were a library author interested in providing generic and flexible data structure. The part after "where" expresses a non-trivial idea: "the type of the first element parameter should be the same as the inner element of the homogenous collection (second parameter), and we need to compare elements to other instances of its type but other than those constraints this code will work on any element and collection". It does that in about 6 swift terms, and the compiler has a full understanding of what you meant and will prevent errors that violate these constraints. Notice that you never have to write this type of code if you're using the library. Swift has decently organized progressive disclosure of language features. For example I never had to write unsafe pointer arithmetic or interop with C, but I'm not going to complain the feature is there for those that need it.

> The Swift Team really needs to take a step back, and actually start removing features and simplifying the language drastically if they want it to succeed. At his point there is a great chance that Swift is becoming a liability for Apple and it may actually impact its app ecosystem negatively in the long term.

So. This. I have been a long time Apple fan. I noticed many years ago that they had a disproportionate representation amongst creative programmer types. I was intrigued and have come to understand why. It's not perfect, and Apple pisses me off some days, but overall the ratio of "It Just Works/WTF?" has been higher for me than other platforms.

As a Smalltalk guy, Objective-C was tragically comic, but nevertheless effective. It was like talking cavemen with your partner, and giggling about it, but you could still get stuff done.

When they announced Swift as "without the C", I was originally excited/intrigue. Despite some original surprises, I soon told peers "I've always hated C++, this feels like a decent compromise that I could like."

For quite some time, I've prototyped first on iOS, refined, and then replicated in Android. Because it was easier/better in Apple's stack than it was in Android.

At this point, I've given up. It's as complicated as C++, maybe more so. The Android development story is not all that much easier (Kotlin improves some things, but it's still Android), but Apple has actively lost their edge (for me) due to the added complexity.

I still write Swift on a pretty regular basis (I maintain/evolve 3+ apps with it). But to the point, I no longer want to. I'm actively interested in an alternate method of writing app UIs.

That syntax is important. It's specifying that the the collection `Elements` contains values which are the same type as `Element`. Sure, those are probably bad names for the generic types (though better than `T` and `U`). But you need some way to express that the `Element` type is the same as the contents of the `Elements` collection.

The SQL analogy is a good one– what the function signature is doing is specifying a constraint between 2 otherwise unrelated values. Otherwise you could call the function with an array of `String`s an ask it for the index of an `Int`.

I feel like the example you gave is pretty bad as to me that's a perfectly sensible function definition. I didn't write Swift from the beginning but I believe a function like this would've been valid Swift from the beginning? Just seem like core features of the type system.

That method signature is not that bad to be honest, I actually feel this a bit better than Rust. (Though it might have helped if you added a newline in the middle of that signature). Maybe you're complaining more about the complexity of the type system rather than the syntax.

Or maybe because I'm saying this because I'm already acquainted to the evil monstrosities of C++. Here's the same function: (and this is even with C++20 concepts on):

    // Yes, you need to include some headers to get even the most basic features! Typical C++.
    #include <type_traits>
    #include <optional> 

    template <Collection Elements, Equatable Element,
              typename = std::enable_if_t<std::is_same_v<typename Elements::Element, Element>>>
    std::optional<typename Elements::Index> index(Element element, const Elements& collection) {
        // Function body
    }

I agree with you. I get the problem its trying to solve but its removing the ability to parse that line of code without carefully reading it. SQL is able to have this because we are talking about querying a database, but a modern language should never that hard to mentally parse in my opinion.

> It looks like you are doing SQL statement in just a method signature, which is just insane.

Aside from the `where` keyword, I don't see much similarity with SQL. That said, I'm a big fan of SQL, so I might be blind to the issue.

Several other people have already said it, but I find that definition pretty easy to read, and I've never been paid to write a line of Swift. The most confusing part for me was the fact that the argument names seem to have spaces in them. The type constraints look pretty nice to me, to be honest.