Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alamofire: HTTP Networking in Swift

github.com

Post reply on HN
Print view View original

1–10 of 29 posts

Re: Alamofire: HTTP Networking in Swift

#4

Post by treve »

Congrats on this release!

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.

Re: Alamofire: HTTP Networking in Swift

#5

Post by mythz »

matttthompson wrote: post #2

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

Looks like a great lib with a nice API, thx.

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?

Re: Alamofire: HTTP Networking in Swift

#6

Post by krschultz »

treve wrote: post #4

Congrats on this release! 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…

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.

Re: Alamofire: HTTP Networking in Swift

#7

Post by realusername »

treve wrote: post #4

Congrats on this release! 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…

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.

Re: Alamofire: HTTP Networking in Swift

#8

Post by Kalium »

realusername wrote: post #7
treve wrote: post #4

Congrats on this release! 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…

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…

Ruby does this too. Thor, God, bluepill, and pony all come to mind.

Re: Alamofire: HTTP Networking in Swift

#9

Post by myko »

matttthompson wrote: post #2

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

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?

Re: Alamofire: HTTP Networking in Swift

#10

Post by treve »

krschultz wrote: post #6
treve wrote: post #4

Congrats on this release! 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…

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.

A better alternative is a combination of both, such as : [fancynoun-purpose]. For example: alamo-http
Post reply on HN