Meta Commentary: that people are still serving blogs out of a database boggles my mind (as I write this the blog is down because of database issues).
Swift Evolution acceptances: The big three
11–20 of 37 posts
Re: Swift Evolution acceptances: The big three
#12Link was down for me here is the google cached version http://webcache.googleusercontent.com/search?q=cache:B3qA4jq...
What's the alternative? I actually thought databases were the cutting edge. Or maybe I've been out of the loop.
Re: Swift Evolution acceptances: The big three
#13Re: Swift Evolution acceptances: The big three
#14Link was down for me here is the google cached version http://webcache.googleusercontent.com/search?q=cache:B3qA4jq...
What's the alternative? I actually thought databases were the cutting edge. Or maybe I've been out of the loop.
Databases are fine, but blogs change infrequently and mostly serve the same static content. Caching the database-generated pages, or just serving static files, if much more efficient, especially when a crowd comes.
Re: Swift Evolution acceptances: The big three
#15I'm basically glad to see the Type suffix removed from the standard library protocols. I'm hoping that they'll have a solution to make it so writing a function over a generic sequence isn't such a mouthful. I'm a little flummoxed by the new effort for first argument labels. Function names often imply the meaning of their first arguments very effectively and the new splits in function names seem arbitrary at times. La…
The function name often includes the name of the first argument just by virtue of it being spelled out. Current Swift function names are usually two parts, one part for the function itself, and one part that indicates the meaning of the first argument. For example, consider removeAtIndex, substringWithRange, or joinWithSeparator. To me, it makes a lot more sense to just call these remove, substring, and join, and lab…
In my brief experience with Swift the first argument convention struck me as a little weird. I ended up adding labels anyhow as it made more sense to me. Glad to see this being embraced.
Re: Swift Evolution acceptances: The big three
#16Meta Commentary: that people are still serving blogs out of a database boggles my mind (as I write this the blog is down because of database issues).
What's the alternative? The blog (according to the HTML source) is pretty stock WordPress, which is database-backed.
Re: Swift Evolution acceptances: The big three
#17Meta Commentary: that people are still serving blogs out of a database boggles my mind (as I write this the blog is down because of database issues).
What's the alternative? The blog (according to the HTML source) is pretty stock WordPress, which is database-backed.
Use a cache plugin or migrate to a static site (works really well for blogs).
Re: Swift Evolution acceptances: The big three
#18Earlier quoted context omitted.
What's the alternative? I actually thought databases were the cutting edge. Or maybe I've been out of the loop.
Databases are fine, but blogs change infrequently and mostly serve the same static content. Caching the database-generated pages, or just serving static files, if much more efficient, especially when a crowd comes.
Can better blogs be built on top of Google's App Engine? I've been building on top of it with Go but I don't use app engine's data store, and I'm not sure that I want to. My little database is a pregenerated Go variable.
http://www.h4labs.com/dev/ios/swift.html
I'd like to add more features but I don't want to reinvent everything. Anyway, Go and App Engine handle the load well and so far it has been free.
Re: Swift Evolution acceptances: The big three
#19Big things missing from Swift IMO: - Higher-kinded types - Strictly-typed "throw" I'm not sure about dropping "Type" from protocols because it's pretty commonly used to separate the protocol definition (which is extended to provide most of the implementation) from the concrete base implementation, e.g. RAC's SignalProducerType/SignalProducer.
Swift protocols are begging for HKTs.
Re: Swift Evolution acceptances: The big three
#20Swift is changing fast. Chris Lattner has stated that Apple will have a good migration solution to update current Swift code. If Apple does it right, Swift will be a major cross platform language within a few years. You can argue that Rust, Nim, or Go are better, for example, but the community and support Apple give Swift give it a big advantage. Simply look at the number of Swift books published in the first 18 mont…
For that to happen, they need to have the compiler target more than just OS X, iOS and GNU/Linux.