Hacker News Reader

Comment by sixstringtheory | Hacker News Reader

I frequently am disenchanted with the new sugar the Swift project introduces. They add way too much surface area to the language by allowing too many ways to do a given thing. When you're looking at a particular line of code, it's very difficult to tell what exactly is going on without pulling up declaration sites for multiple involved things because there's too much magic.

This time around it's callAsFunction. Yeah, pretty easy to understand in their toy example. When it's deployed IRL with a ton of other things going on, and larger distances between declaration and usage, it looks like a nightmare.

I love writing Swift for myself, but I write it in a pretty boring way. When I have to work with people who get creative and clever, it's awful.

View on HN

> They add way too much surface area to the language by allowing too many ways to do a given thing.

Not relevant to most situations, but I'll just add that this also makes it extremely difficult to teach a language.

I have taught Ruby -- a language with quite a sweet tooth -- for almost twenty years, and I feel like it gets worse and worse every year. Students run off to look at example code online (as they should), but discover that I have been teaching them what seems to them like a different language.

It really leaves me with no choice but to spend a lot of time in lectures saying, "You can do it this way . . . or this way . . . or this way . . . and by the way, these are all semantically equivalent."

The concept of progressive disclosure means that you shouldn't teach this kind of stuff to beginners. Stuff like callAsFunction, dynamic member lookup, etc. are for people who are writing DSLs, providing rich libraries, etc.

Progressive disclosure does absolutely nothing for your students looking up example code only to be greeted by alien syntax that does the same thing.

Pretend you know nothing about a language, why would you assume .map { $0.thing } and .map(\.thing) are even remotely similar?

You would look it up, as you would for anything else you see for the first time.

I wonder if there's a coding interface for beginners that works as follows:

The beginner types a declaration of "I want to _____" and the interface uses ML to auto-suggest code. The auto-suggest would be context-sensitive and fit in with previously written code. Auto-correct would work similarly. If the declaration isn't specific enough, then the auto-suggest tool would ask a series of questions that illustrate the different choices a programmer can make in achieving their goal. Finally, the tool would output code that reflects the beginner's choices.

This would increase the speed of the think-do feedback loop. Beginners would be able to jump into coding with very minimal education and "make" the application they want straight away. Of course, it would usually behoove them to eventually read some programming books and take classes, but this tool would pique their interest. The power of the auto-complete would scale back as the beginner progresses unless they get stuck. Maybe this would only work on a finite set of projects that the ML was trained on, which is fine because you can just give a lot of projects to choose from. That is until the ML becomes more powerful and generalizable.

Among the drawbacks of excessive syntactic sugar is that it is often difficult or impossible to look up

Do you have examples of that?

Syntax duplication has a huge cognitive overhead.

Scala knows something about this and made a 180-degrees turn recently.

Swift is a lot like Scala. Swift creators, please not repeat Scala's mistakes.

I use Scala everyday (in spark) and generally prefer it over java but I agree that the surface area is too large. This is really evident when you start to import someone else’s libraries. The breadth of the language affords many different paths for the library writer depending On how much of a language sniper they are.

We have the exact same problem with Typescript. We've solved it with an extremely judicious use of the linter, which prohibits certain constructs, certain patterns, and tries its best to get rid of weird features. The first thing I thought when I read `callAsFunction` was "sounds like a new lint rule someone has to write to disable that garbage."

I'm not sure how invested your team is in Swift, but since we do nothing but Typescript, the investment in time (2-3 days for one the lead engineer) tweaking the linter has more than paid off ten-fold in the months since.

> We've solved it with an extremely judicious use of the linter, which prohibits certain constructs, certain patterns, and tries its best to get rid of weird features.

This is one of my concerns with adopting Typescript in my team. Would you please share more info about the kinds of things you prohibit, and why you chose them?

I work at an all typescript shop and I really recommend checking out https://github.com/xojs/eslint-config-xo-typescript#readme as this is a full time open source developer that has to field all kinds of PR's from strangers. So it saves them time if the linter flags things they're trying to avoid.

I have not looked in to Typescript myself yet, but I would say that an “AirBnB style guide”-type linter ruleset could make picking it up much easier.

It shouldn't be much of a concern if you're already writing JS, which usually already comes with judicious use of the linter.

Not the OP but what system are you coming from? If JS, then TS is a great improvement. If anything else...probably not going to be a fun time.

This. I'm already adding callAsFunction to my team's linter, should be a stupid simple match since you can block declaring the capability in anything.

I regularly check the forums for Swift, and am dismayed at a lot of the discussion being interested in adding syntactic sugar over real new features. I fear that Swift will head down the route of C++ where there ends up being so many ways to do one thing that it's not reasonable to keep up with it all.

That's the natural consequence of the heralded Swift Evolution process: being swarmed by language wonks

Are we not there already? Last I checked, I thought Swift had more reserved words than C++.

I was all prepared to disagree with you until I read the details ... and yeah, I agree.

I generally love syntax sugar that makes me more productive, cuts out boilerplate, and reduces cognitive overhead... but for me, callAsFunction and even maybe Key Path Expressions as Functions are going to ADD cognitive overhead.

I suppose if I only used Swift, and used it every day, they would be OK, but otherwise it's just more fiddly things that deviate from existing patterns.

How odd, I was all prepared to come in and find other folks excited about callAsFunction. It seems rather straightforward, although I will admit Swift is my daily driver.

Think most agree expressive syntax while minimizing boilerplate is at times going to require sugar. It's interesting you bring cognitive load into the question – perhaps I come at it more from an architectural light than PL fans, but that load seems largely correlated with one's purposes and patterns in using the language.

On that front, Swift has lofty and broad goals (including DSLs), but that surface area doesn't make the language worse. To take your other example, KeyPath Functions don't change anything about KeyPaths; the concept is and remains no different than anywhere else it's implemented (whether in Swift or in another language). Beginners can still use the concept, skill comes with understanding how/why it works, and mastery comes with knowing when/how to use it simply.

If Swift achieves said goals, one needn't be able to understand the last mile of any specific domain where it's used as a language. But it'll be quicker and easier than coming from another language, and the sugar will still be as sweet.

You make good points, and I think I am overreacting!

Frankly, it's misleading/silly for me to complain about Swift additions since I don't have the opportunity to write much of it, and primarily only read/consume it with Obj-C code. (I have no choice in this matter.) Basically the language already has a high cognitive load for me, so of course any additions feel burdonsome.

Also, I'm unfamiliar with using KeyPaths like that, so I'm clearly way off on my reaction to them.

The general goals of Swift make me want to learn it better and use it, honestly.

> I love writing Swift for myself, but I write it in a pretty boring way. When I have to work with people who get creative and clever, it's awful.

I could (and do) say the same thing about Perl.

I don't think anyone in the Swift community wants the Perl's reputation as a write-only language, but changes like callAsFunction are how we get there.

This kind of magic sugar may have been spurred by the requirements for SwiftUI and its evolution, in which case, I’m all for it.

I can already imagine cases where callAsFunction() would be handy. For example, having a viewTemplate = SomeView(customization: etc) then creating copies via viewTemplate()

But why not just add a method like “.copy()” that’s explicit about what it does? Have to say I’m not a fan of this callAsFunction feature...

Again, because this makes declarative UI cleaner to write, or if you prefer to put it this way: reduces clutter.

I could create button templates then make slightly different copies of those templates without having to subclass Button or attaching .copy()

SwiftUI is all about succinctness.

Why is it all about succinctness? Swift has never been about succinctness - it’s always been about clarity, without over-verbosity. Sometimes, it just takes a decent number of characters to describe something. That’s not necessarily a flaw, especially if it makes something easier to read.

Seeing .copy() makes it much clearer to understand that what I’m receiving is a copy of something.

If you want a Button template, either extend Button with a method taking the parameters you want, or write a curried free function or something. callAsFunction adds absolutely nothing to the language, bar confusion at the call site.

Playing code golf with the language syntax isn't the point, clarity and expressiveness is.

That is the point. Swift has a primary usage unlike other languages. That is okay.

`callAsFunction` is not for Swift's primary usage. It is for Python interop, used by Swift For TensorFlow. Its design is such that you should never need to know it exists unless you're designing your own Python (or other scripting) interop layer.

Then it should be some kind of python-interop module. These kinds of useless syntax hax shouldn't be introduced into the main language. >99% of swift devs will never ever "interop with python", yet they all have to pay the price of this change.

I could see its use in math-heavy code as well. That might be a rather narrow domain, but one where features like this (or operator overloading for another example) do help to reduce syntactic pain.

They've had similar thing to callAsFunction in Dart for many years now (maybe the start). I've written many thousands of lines of Dart code, and I've never used it once, and I don't like it.

What amazes me as a huge Swift fan is that crap like callAsFunction gets priority over things like proper async/await.

You're surprised a relatively easy to implement, one off feature with no dependencies and no impact on the rest of the language can be done before a feature that impacts huge areas of the language and requires underlying runtime and compiler support?

It's easy enough to say things like "well if you don't like it don't use it". Meanwhile as a primarily swift dev I can't stop others (outside of my team) from using this disastrous syntax.

The first time I have to dig into someone's backwards codebase that uses I'm gonna flip.

Objects defining named functions allows you to reason about them logically. Car.tireSizeInches() returns an Int type. Any other developer can see that and know whats up, or type "Car." and explore relevant functionality. What the crap does Car() do? Etc.

This is a huge backwards step for swift syntax. I hope most of the large open source libs ban it.

As for implementation difficulty, see my sibling reply.

Well callAsFunction is extremely simple to implement and test. Where as async/await is a much bigger and more complex feature. It's not amazing, it's totally logical.

I understand the difference in difficulty, my point is any incremental time spent on this is wasted and could have contributed towards something else that's useful.

That's not how software development works.

If I've got a new team member, I'm not going to put him on async/await. I'm going to find him something simpler to work on.

Or maybe I've been working on a feature for a few months and I need a break to clear my head so I'll work on a smaller feature for a while.

Software development isn't just assembling widgets on an assembly line. It's a creative process. Developers aren't chained to their desks pumping out a non-descript streams of "code" that become different features. Likely incremental time spent on this had almost no real impact on more difficult and useful features.

> I'm going to find him something simpler to work on.

Sure, but why should this non-feature which makes code harder to read and reason about even be built in the first place? All to save `.parse` at the call site of a parser, for example?

This syntax already exists in the language. If you want users to be able to use the obj() syntax you can already give them a closure for obj. Allowing it for user-defined types too removes an artificial syntactic distinction.

Async/await might actually help you clean up your codebase. Much better to have more syntactical sugar to keep code reviews lively and add more surprises for future developers!

i happen to be learning swift and, as a newcomer to the language, i have concluded that the level of complexity is pretty much on par with cpp. one thing i have noticed is that swift maintains readability while being complex. that's the surprised to me. complex cpp is simply not pleasant to read.

You can thank limiting the use of pointers and macros for that.

This is where a strong tech-lead and coding style guidelines are a must on any team. There will always be code ramp-up time for any engineer, junior or senior, even if everything was written in plain old C. So you need to adhere to what you consider readable as a team and discourage cleverness.

Or go full meta and discourage "cleverness" during the Swift Evolution process it seems.

I mostly agree with you, but also can that it can be nice whenever you have a class that has some state and only a single method. If you have this, you no longer have to pick separate names for the class and the function.

Chances also are that it is inspired by python’s callable (https://en.wikipedia.org/wiki/Callable_object#In_Python), which, as far as I know, people don’t complain about much.

It was indeed; it was proposed and implemented by engineers working on the Swift For TensorFlow project. The earlier dynamic callable features were as well, in order to offer Python interop.

It's just C++'s operator(), right?

To me callAsFunction() looks like the reintroduction of currying, but the naming is pretty magical.

Sorry, but can someone explain the usecase for callAsFunction?

I have seen something similar before in Python where a class implements __call__, but I have never needed to use it.

You hit the nail on the head. `callAsFunction` was introduced for Swift in order to interop with Python for the TensorFlow project.

> When I have to work with people who get creative and clever, it's awful

Isn't this more like a problem you have with the team, rather than a problem with the language itself?

> Sounds more like a problem with the team, rather than a problem with the language.

That's the same reply that people have to "C++ has too large a surface area". Granted, Swift isn't quite at C++ levels of complexity yet, but ideally, I shouldn't have to cordon off sections of the language I'm using just so my team can stay sane.

What no one seems to be able to do is make a simple language and leave it alone to focus on tools and ecosystem. It always seems to be that the momentum of solving an initial problem with the language is carried into solving more problems with the language instead of tools.

I hope we can get to a point where we don't need to build tools and ecosystems around a single language. It seems there is just an explosion of domain and generic languages and I see that as a good thing. I want more tooling compatibility so that developers can pick and choose what works for them and maybe even mix them together better. Better educational tooling so we can pick them up faster, or read languages we don't understand easier. etc, etc. things like WebAssembly, LLVM/MLIR, python->jupyter notebooks give me hope.

How do you feel about Go? It's almost twice as old as Swift, but hasn't seen the same rise in complexity, imo. Tooling and ecosystem seem pretty solid as well.

The programming language Oberon by Niklaus Wirth is an exception. It has actually become slightly smaller over the years.

https://www.miasap.se/obnc/oberon-report.html

I think any useful language will have features that many people won’t use. Library writers, etc need different functionality, for example.

One thing I wish Swift had was an easy way to add more generic functionality. For example, if I want to add drop(), dropWhile(), take(), takeWhile(),... there’s no nice way to extend Array

    [1,2,3].take(2)
    [“a”,”b”,”c”].take(2)

Btw, I’m working a Swift Cookbook for anyone who quickly wants to come up to speed on Swift. All open source. Feel free to comment or commit.

https://github.com/melling/SwiftCookBook

What do you mean? It's trivial to add extensions to Array, Collection, or Sequence. You can find multiple examples of your additions online right now.

I didn’t say it was impossible. I said “add more generic functionality“

That’s why I provided two examples containing different types to illustrate what I meant.

I don’t believe you can add a generic function to the array to handle this.

In another repo, I’ve used the FloatingPoint protocol with some luck. However, this should also work with Int’s, for instance:

    extension Array where Element: FloatingPoint  {
    
        var sum: Element {
           self.reduce(0, +)
        }
    }

https://github.com/melling/data-science-from-scratch-swift/b...

> I don’t believe you can add a generic function to the array to handle this.

What’s wrong with something like this?

    extension Array {
        func take(_ n: Int) -> ArraySlice<Element> {
            self[0..<n]
        }
    }

For your other example, you can make the function accept an array of Ints by constraining Element to AdditiveArithmetic instead of FloatingPoint.

The example you didn't cover using AdditiveArithmetic is actually covered in the docs here: https://developer.apple.com/documentation/swift/additivearit...

    extension Sequence where Element: AdditiveArithmetic {
        func sum() -> Element {
            return reduce(.zero, +)
        }
    }

I think you’re making my case for me. So, I’ll need a separate function for Ints, Strings, Floats... What if I have an Array of my custom Person objects?

   [1,2,3].take(2)
   [“a”,”b”,”c”].take(2)
   [p1,p2,p3].take(2)

How much logic are we going to need to repeat for all the types for all the functions?

there are holes in Swift's generics system, but this isn't one of them. you don't need separate extensions for int, string, float etc. arrays. the parent post gave you a generic implementation that works with any type of array

Hmmm. I thought ArraySlice had different semantics. Why wouldn’t it be declared returning [Element]?

   extension Array {
          func take(_ n: Int) -> [Element] {
             self[0..<n]
          }
      }

Apple provides this warning for ArraySlice:

“Long-term storage of ArraySlice instances is discouraged. A slice holds a reference to the entire storage of a larger array, not just to the portion it presents, even after the original array’s lifetime ends. Long-term storage of a slice may therefore prolong the lifetime of elements that are no longer otherwise accessible, which can appear to be memory and object leakage.”

https://developer.apple.com/documentation/swift/arrayslice

Would it be acceptable to put these implementations in a Functional library?

Yes, it would. Returning an Array would require take to copy the data, slowing down your nice functional code.

This is because Swift is quite low-level when it comes to storage etc., so [0..<n] returns an ArraySlice.

However, this has nothing to do with generics.If you're willing to sacrifice performance, you could easily write

  extension Array {
      func take(_ n: Int) -> [Element] {
          Array(self[0..<n])
      }
  }

FWIW I'm with you on this. I'm still waiting for the rest of the generics manifesto to, you know, manifest: https://github.com/apple/swift/blob/master/docs/GenericsMani...

That one and the need for generic associatedTypes trip me up all the time.

I think about it every time I see new feature announcements like today's. The opportunity cost of the wasted effort, the new thing that will probably make things harder for everyone. Possibly including those who try to fulfill the generics manifesto.

Reply on news.ycombinator.com