I confess I’ve been learning Swift by recreating the Python library calls that I regularly use. Mine was definitely an exploratory work though. I was mainly working in a Playground. Half the code I deleted when I was done.
This library seems much more robust than my Playgrounds. It’s still a little limited though. They didn’t implement string slicing allowing negative slices. But that’s easy to add. They also didn’t add the format function for printing a formatted string from an array. Again not too hard to add though and one could argue it’s not needed given println. Of course what I really want is Python’s itertools library. But that’s not really possible now. I’m sure mine is a minority voice, but I’d love to see datetime ported too – especially with the + and – operators overloaded. NSDate, NSCalendar, and NSCalendarComponents just aren’t as nice in my view. Maybe that should be my next set of learning code.
I confess I prefer to use native methods whenever possible. For less commonly used methods I will even prefer Cocoa methods that aren’t really ideal. So in the Extensions or Categories I write for my own use I strip out anything I know I won’t use regularly. I love brevity, which is why I love Swift when combined with certain Python features. However I also think that only the most used methods should be brief. For lesser used ones I like the self documenting nature of Cocoa. That said, Cocoa was horrible for a lot of commonly used features like strings. That’s where Extensions in Swift along with some limited operator overloading is nice. Brevity where you need it and just where you need it.
- 42I’d mentioned in passing in one of my Swift posts about using it as a scripting language. Someone on Twitter asked me if I’d convert from using Python to Swift for my scripts. It’s an excellent question that I really can’t answer fully at this stage. The language is still…