15 ms·
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
by sixstringtheory 7y ago
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.
- oorza 7y agoWe 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.
- vosper 7y ago> 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?
- sezna 7y agoNot 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.
- mikewhy 7y agoIt shouldn't be much of a concern if you're already writing JS, which usually already comes with judicious use of the linter.
- STRiDEX 7y agoI work at an all typescript shop and I really recommend checking out https://github.com/xojs/eslint-config-xo-typescript#readme 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.
- joshspankit 7y agoI 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.
- zionic 7y agoThis. 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.
- BubRoss 7y agoWhat 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.
- enos_feedler 7y agoI 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.
- augustk 7y agoThe 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 https://www.miasap.se/obnc/oberon-report.html
- thedirt0115 7y agoHow 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.
- Razengan 7y agoThis 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()
- azinman2 7y agoBut 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...
- Razengan 7y agoAgain, 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.
- rhysmorgan 7y agoWhy 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.
- zionic 7y agoPlaying code golf with the language syntax isn't the point, clarity and expressiveness is.
- oaiey 7y agoThat is the point. Swift has a primary usage unlike other languages. That is okay.
- OberstKrueger 7y agoI 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.
- cerberusss 7y ago> 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?
- giornogiovanna 7y ago> 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.
- yAak 7y agoI 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.
- Gorbzel 7y agoHow 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.
- yAak 7y agoYou 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.
- markdog12 7y agoThey'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.
- zionic 7y agoWhat amazes me as a huge Swift fan is that crap like callAsFunction gets priority over things like proper async/await.
- jshier 7y agoYou'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?
- zionic 7y agoIt'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.
- wvenable 7y agoWell 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.
- zionic 7y ago
- sramsay 7y ago> 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."
- favorited 7y agoThe 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.
- zionic 7y agoProgressive 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?
- Razengan 7y agoYou would look it up, as you would for anything else you see for the first time.
- keenmaster 7y agoI 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.
- Someone 7y agoI 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 https://en.wikipedia.org/wiki/Callable_object#In_Python), which, as far as I know, people don’t complain about much.
- jshier 7y agoIt 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.
- edflsafoiewq 7y agoIt's just C++'s operator(), right?
- melling 7y agoI 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 https://github.com/melling/SwiftCookBook
- jshier 7y agoWhat 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.
- melling 7y agoI 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/blob/master/swift/statistics.swift https://github.com/melling/data-science-from-scratch-swift/b...
- NobodyNada 7y ago> 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.
- kbenson 7y ago> 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.
- zionic 7y agoI 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.
- bluebasket 7y agoi 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.
- pixelrevision 7y agoYou can thank limiting the use of pointers and macros for that.
- dep_b 7y agoTo me callAsFunction() looks like the reintroduction of currying, but the naming is pretty magical.
- jarjoura 7y agoThis 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.
- zionic 7y agoOr go full meta and discourage "cleverness" during the Swift Evolution process it seems.
- Cyph0n 7y agoSorry, 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.
- lazyvar 7y agoYou hit the nail on the head. `callAsFunction` was introduced for Swift in order to interop with Python for the TensorFlow project.