I am jealous of Swift(blog.metaobject.com)
blog.metaobject.com
I am jealous of Swift
http://blog.metaobject.com/2015/05/i-am-jealous-of-swift.html
5 comments
If they're designing a language for the next 20 years, should they have designed in Objective-C compatibility more tightly? Isn't "afterthought" exactly how it should feel if they plan to remove it someday?
They were desperate to release something ASAP. The enemy is at the gates.
Disclaimer: I have a relative good experience in Scala.
Let's see how I can formulate my thoughts about Swift without say something that can be considered trivial.
I think Swift can be basically resumed with this quote:
> Crucially, the vast majority of this is incidental complexity, not essential complexity.
I love Swift, I think is a good language, but is far away from perfection. Sometimes I feel that is half-baked compared to languages like Scala. I can understand the complexity and the obstacles that are part of a development of a new programming language, but some things are really messy.
I truly hate these 3 factors:
> enum cases act like functions, but are not functions.
> Properties act like functions, but are not functions.
> Initializers act like functions, but are not functions.
Plus the fact the language is not homoiconic freaks me out, sometimes.
I like Swift because constantly challenges my skills as engineer, I have to find workarounds to apply all the concepts I know about functional programming, but... this is the current feeling, I don't know if in a long run this would persist, I can't image to fight against the language like I have to do sometimes, would make me still happy in 2-3 years, maybe some day I would get tired.
I like Swift, there's a lot to do to jump from a good language, to an awesome language, but now we are still far away from that.
Let's see how I can formulate my thoughts about Swift without say something that can be considered trivial.
I think Swift can be basically resumed with this quote:
> Crucially, the vast majority of this is incidental complexity, not essential complexity.
I love Swift, I think is a good language, but is far away from perfection. Sometimes I feel that is half-baked compared to languages like Scala. I can understand the complexity and the obstacles that are part of a development of a new programming language, but some things are really messy.
I truly hate these 3 factors:
> enum cases act like functions, but are not functions.
> Properties act like functions, but are not functions.
> Initializers act like functions, but are not functions.
Plus the fact the language is not homoiconic freaks me out, sometimes.
I like Swift because constantly challenges my skills as engineer, I have to find workarounds to apply all the concepts I know about functional programming, but... this is the current feeling, I don't know if in a long run this would persist, I can't image to fight against the language like I have to do sometimes, would make me still happy in 2-3 years, maybe some day I would get tired.
I like Swift, there's a lot to do to jump from a good language, to an awesome language, but now we are still far away from that.
>Swift is a crescendo of special cases stopping just short of the general.
Yeah, a.k.a pragmatic. It's no Scheme and no Smalltalk.
Golang, which others like, is also a huge pool of "because I say so" and special-cases (make, ranges etc), but its restrictive and simplistic to boot.
At least Swift is firing in all pistons...
Yeah, a.k.a pragmatic. It's no Scheme and no Smalltalk.
Golang, which others like, is also a huge pool of "because I say so" and special-cases (make, ranges etc), but its restrictive and simplistic to boot.
At least Swift is firing in all pistons...
I would say that it is volatile mix of very non-pragmatic constructs and lots of real constraints that creates the problem. If you want to see how to build a pragmatic language - look at JAI.
> ... we learn that debug builds are often 100 times slower
> than optimized builds (which themselves don't really
> rival C).
> Sorry, that's not the sign of a language that's
> "designed to be fast".
To have fast compiles be within x2 (or thereabouts) of optimized build is very important for plain productivity reasons. Therefore it's a very valid concern.
For the kind of applications that Swift is intended for now (i.e. iOS / Mac apps), debug-mode runtime doesn't affect productivity very much as long as runtimes are fast enough to respond to UI events. It might affect automated testing times, but not productivity directly.
So, for that particular use-case, debug-mode being within 2x of release-mode build is not a valid concern.
What would affect productivity for this kind of use-case is build times. (Swift isn't great here either.)
So, for that particular use-case, debug-mode being within 2x of release-mode build is not a valid concern.
What would affect productivity for this kind of use-case is build times. (Swift isn't great here either.)