Ranges and Intervals in Swift(oleb.net)
oleb.net
Ranges and Intervals in Swift
http://oleb.net/blog/2015/09/swift-ranges-and-intervals/
2 comments
I really want to like Swift. But so much of the language feels like it was tacked on in an attempt to check off of all the admirable features of many great languages. On the surface, this is not inherently bad. But when you dig deeper into the API organization and consider the ideal implementation for many things, like functional programming, you see that the effort was often a bit shallow. For example, functional programming that copies an entire data structure every time you make a minor change or append is a real waste of the power of that paradigm. Or placing stateful actions into the same API set as FP expressions makes little semantic sense and discourages any sense of thoughtful structure to the different paradigms. When/if Swift is meaningfully open sourced and when/if the world at large improves on these things, perhaps the future of the language has promise.
I really want to like Swift.
Why? What does it offer?
Why? What does it offer?
>When/if Swift is meaningfully open sourced and when/if the world at large improves on these things, perhaps the future of the language has promise.
Swift should be open sourced this year[1], though it will be interesting what strategy will apple use for contributions. I mean, who will say which feature should be developed and which not? Because if Apple will continue to do it their way, will open sourcing swift will change anything?
[1] https://developer.apple.com/swift/blog/?id=29
Swift should be open sourced this year[1], though it will be interesting what strategy will apple use for contributions. I mean, who will say which feature should be developed and which not? Because if Apple will continue to do it their way, will open sourcing swift will change anything?
[1] https://developer.apple.com/swift/blog/?id=29
I've come to respect highly the "crowd-sourced development" phenomenon of a massive worldwide open community all working to improve a single code base. I have seen the resounding effects of this in other languages. Apple would be silly to assume that its vast wealth could allow an internal-only Swift evolution to compete with the progress of masses. I hope they do open it up for PRs from anyone (with no doubt a simple contributor agreement in place), and a good well-oiled machinery for seriously looking at all community code.
That said, some things are fundamental to the language and its architecture, and those are the things Apple is developing internally before its open-sourcing. So it is possible the most important stuff will not be getting help from the masses.
That said, some things are fundamental to the language and its architecture, and those are the things Apple is developing internally before its open-sourcing. So it is possible the most important stuff will not be getting help from the masses.
If they don't accept many contributions, it's quite likely it'll just be forked.
[deleted]
> For example, functional programming that copies an entire data structure every time you make a minor change or append is a real waste of the power of that paradigm.
What do you mean by this? In the implementation, yes, is a poor optimization strategy, but for the user of the language, shouldn't that be what appears to be happening? Mutable data structures and functional programming mix worse than immutable data structure and functional programming.
> Or placing stateful actions into the same API set as FP expressions makes little semantic sense and discourages any sense of thoughtful structure to the different paradigms.
This is incredibly weird. You cannot get an array in Swift with an item at an index removed. There is a function to remove an item at an index from a mutable array[1], but no way to remove an index and return a new array. You can't do it. But you can "filter(:)", which returns a new array, and you can't "filter(:)" a mutable array to alter it. ...wat?
[1] - a thing that I'd argue shouldn't exist, when we must have mutability, it should be mutable references to constant arrays
What do you mean by this? In the implementation, yes, is a poor optimization strategy, but for the user of the language, shouldn't that be what appears to be happening? Mutable data structures and functional programming mix worse than immutable data structure and functional programming.
> Or placing stateful actions into the same API set as FP expressions makes little semantic sense and discourages any sense of thoughtful structure to the different paradigms.
This is incredibly weird. You cannot get an array in Swift with an item at an index removed. There is a function to remove an item at an index from a mutable array[1], but no way to remove an index and return a new array. You can't do it. But you can "filter(:)", which returns a new array, and you can't "filter(:)" a mutable array to alter it. ...wat?
[1] - a thing that I'd argue shouldn't exist, when we must have mutability, it should be mutable references to constant arrays
You are assuming that copy on write is the only alternative to mutability.
Ok can I just say that having your blog post downloadable as an XCode playground is awesome?
Thank you!