What about supporting using something like PromiseKit for error handling and interoperability with aggregation methods? Would you be willing to consider that?
In the README it looks like using the ObjC AFNetworking is suggested if one wishes to do multipart http requests, I assume this is up to date and Alamofire doesn't support this at this time?
However, I think the library name is a bit of a poor choice. I don't want to take away your thunder, I just picked this post to do my rant :).
There seems to be a lot of new general-purpose libraries with very poor non-descriptive names coming out.
Whenever I need to dive into a new codebase, in a language and ecosystem I'm unfamiliar with, it's extremely hard to figure out which dependency and library does what. I was tasked to dive into a massive RoR application recently, and I ended up having to write a glossary first to remember what every non-descriptive noun implied.
After getting familiar with a particular language's ecosystem, this problem becomes tends to go away, and as a library writer, it becomes easier to fall into the same trap by picking a name that's marketable and distinct.
But I feel we're collectively making it increasingly harder for people to ramp up in new ecosystems and maintain future legacy codebases.
For names of large applications this is not as bad, and some of these applications become household names, but I think we should try to avoid this for general-purpose utilities.
I wonder how much this matters to other developers –
but I, at least subconsciously, when faced with a library choice, take into account things like:
- Simple, pretty name (Alamofire is very nice-sounding and memorable – even feels like overkill, author should've saved it for an iPhone app or something.)
- The pretty logo
- The perfect use of Markdown (I'm so obsessed about using `` around everything that looks like code it feels like a psychological condition)
- Clear structure of README
- Simple examples with syntax highlighting
There must be correlation between the presentation and quality of the source code!
You make some good points, and I agree to caution against names that bear no semantic relationship with their purpose. My justification of Alamofire is that it reflects the history of the project, which traces back from AFNetworking to Gowalla (formerly Alamofire, Inc.), the product for which it was originally developed.
The alternative is non-memorable names. I can't tell you how many android-async-image-loader libraries there are. It's a lot easier to remember 'Picasso'. It's also a lot easier for me to Google for 'Picasso Android' and get relevant results.
I feel this is a trend now with new projects, it's also the case in Node.js, Go and new Python packages.
This can go as absurd as the package named "a" in npm (https://www.npmjs.org/package/a) which is used by a lot other packages. I also had some trouble to figure out what each package is suppose to do when using RoR.
However, I would not say it's necessary easier in older languages when I see the amount of weird acronyms used in the Java world.
Thanks for your great works! I am using Alamofire on my project right now. Do Alamofire support or will support async image loading via URL just like AFNetworking? I can't find the API anywhere on the docs.
matttthompson|11 years ago
qrush|11 years ago
* Is this being used in any apps in the App Store currently by you? (or Panic?)
* Is Alamofire a non-profit or some kind of organization? Curious why it's listed in the README.
* Perhaps a bit deeper: Why a rewrite of AFNetworking's feature set instead of a AFN 3.0?
mythz|11 years ago
Was there any reason why you chose callbacks over a Promise-like pattern for the async responses?
Also do you know of any good HTTP Server libraries that will let you develop simple HTTP JSON services in Swift?
inglor|11 years ago
Thanks for your work by the way.
Void_|11 years ago
myko|11 years ago
ksylvest|11 years ago
treve|11 years ago
However, I think the library name is a bit of a poor choice. I don't want to take away your thunder, I just picked this post to do my rant :).
There seems to be a lot of new general-purpose libraries with very poor non-descriptive names coming out.
Whenever I need to dive into a new codebase, in a language and ecosystem I'm unfamiliar with, it's extremely hard to figure out which dependency and library does what. I was tasked to dive into a massive RoR application recently, and I ended up having to write a glossary first to remember what every non-descriptive noun implied.
After getting familiar with a particular language's ecosystem, this problem becomes tends to go away, and as a library writer, it becomes easier to fall into the same trap by picking a name that's marketable and distinct.
But I feel we're collectively making it increasingly harder for people to ramp up in new ecosystems and maintain future legacy codebases.
For names of large applications this is not as bad, and some of these applications become household names, but I think we should try to avoid this for general-purpose utilities.
Void_|11 years ago
but I, at least subconsciously, when faced with a library choice, take into account things like:
- Simple, pretty name (Alamofire is very nice-sounding and memorable – even feels like overkill, author should've saved it for an iPhone app or something.)
- The pretty logo
- The perfect use of Markdown (I'm so obsessed about using `` around everything that looks like code it feels like a psychological condition)
- Clear structure of README
- Simple examples with syntax highlighting
There must be correlation between the presentation and quality of the source code!
matttthompson|11 years ago
krschultz|11 years ago
realusername|11 years ago
This can go as absurd as the package named "a" in npm (https://www.npmjs.org/package/a) which is used by a lot other packages. I also had some trouble to figure out what each package is suppose to do when using RoR.
However, I would not say it's necessary easier in older languages when I see the amount of weird acronyms used in the Java world.
perishabledave|11 years ago
So... what do those guys at Panic have you working on? ;)
ardfard|11 years ago
jtokoph|11 years ago
spacecadet|11 years ago