Hacker News Reader

Comment by leif | Hacker News Reader

This is tangential, but I've found that ruby's non-standard libs have, for the most part, been horribly named. Recall from the article: curb, nokogiri, syck, psych, home_run. Others: sinatra, rack, thin, unicorn, maruku. None of these give me the slightest clue about what they do, and if I wanted, for example, to parse XML, how on earth would I know that I wanted to find "nokogiri" (or "hpricot")? Could I pick what I wanted out of a lineup?

How do you ruby people find the good libraries when you need to perform a task? Is it all word-of-mouth (word-of-blog I guess)?

View on HN

How do you propose to differentiate between multiple implementations of the same concept otherwise? It is nice that there is a "nokogiri" and "hpricot," unlike the PostgreSQL gems, which are called "postgres", "pg", and "postgres-ruby". The one you actually want to use is "pg" though.

Should "rack" be called standard-http-server-api-with-support-for-middleware, and then "unicorn" be called pre-forking-web-server-using-standard-http-server-api-with-support-for-middleware?

The "-ng" prefix has served the programming community quite well for some time.

> Should "rack" be called standard-http-server-api-with-support-for-middleware, and then "unicorn" be called pre-forking-web-server-using-standard-http-server-api-with-support-for-middleware?

No, but perhaps we could have:

    WebServer = require_any_satisfying_protocol 'http-server/with-middleware-support'
    WebServer.new

where each rubygem installed has a table of protocols each of its classes and modules support. For example, Mongrel would have a table that starts:

    {Mongrel::HttpServer => ['http-server', 'http-server/with-middleware-support']}

There are hints of efforts in this area. See rubyinterfaces.com.

As an example, their proposed HTTP interface can be found here:

http://rubyinterfaces.com/httpi-0.1.0/

There are two problems with that.

1. In practice you almost never want to load a random library that says it supports a certain interface, you will want a specific library. Notable exceptions are glibc where the interfaces are well-defined over several decades but that brings us to...

2. Few libraries implement the same exact interface. Mongrel and Unicorn have totally different interfaces. Phusion Passenger is also a web server but works in a fundamentally different way from either of them. Hpricot and Nokogiri are both XML parsers but their usage API is different.

Thus, I imagine, why djacob's link to HTTPI talks about protocol adapters, rather than expecting the implementations to adhere to the protocols directly. Still, the adapters could come with each protocol-supporting gem, rather than being housed in some third party "interface library." Then we could have something more like this in each class of a gem:

    class Mongrel::HttpServer
      class HttpServerProtocolAdapter < Gem::ProtocolAdapter
        implements 'http-server'
        implements 'http-server/with-middleware-support'
        ...

and the manifests (which would then look more like this:)

    {'http-server'                         => Mongrel::HttpServer::HttpServerProtocolAdapter,
     'http-server/with-middleware-support' => Mongrel::HttpServer::HttpServerProtocolAdapter,
     ...}

would be generated automatically at gem installation by loading the gem and then probing for ProtocolAdapter instances in ObjectSpace.

Of course, if you had a class that matched the protocol exactly, you could just use something like

    class Mongrel::HttpServer
      supports_protocol 'http-server'
    end

and be done with it.

This is all assuming that we don't actually want our protocols to be modules or classes or something else that we have to include in the adapter somehow (because this is Ruby, and we do well without needing IDuck.) Instead, protocols would just be externally specified things, with their name-strings perhaps being the URIs of standards docs. At most, if a Gem::Protocol was a reified type, it would be a unit test suite to determine whether a ProtocolAdapter actually supported its protocol (minimally, via a series of #respond_to?s.)

Same applies to nearly every tool for every language. yacc, for instance, does not give any indication as to what it does (well, until you expand the initialism).

Java is, of course, one place where this is a bit better. log4j and jUnit both tell you what they do quite easily. (But then again, Apache Maven does not.)

We have Google these days, and if that doesn't help you, go on the #ruby IRC channel and ask what they recommend.

Lucene, guice, solr, spring, hibernate, jmx, osi, nailgun, etc.

awk, grep, sed, perl, cat, finger, man, etc

  awk -> I forget what
  grep -> global/regular expression/print
  sed -> stream editor
  perl -> I'll give you this one
  cat -> concatenate
  finger -> I'll give you this one
  man -> manual

A large percentage of them are mnemonics.

I wasn't implying that it's better elsewhere, just that java isn't any better.

http://www.google.com/search?q=ruby+xml+parser&ie=UTF-8&...

Nokogiri is the 5th result for me. How does anyone find libraries and then choose between them? I believe you should always do a little research unless your feeling lucky.

Same goes for just about every library under the sun. The other day I was searching for redis libraries for nodejs, the first one from google by fictorial is maintained by someone who has gone for maternity leave where the current version doesn't even compile against the latest node. The one that you're actually supposed to use doesn't even list on the first 5 pages of the google search. (but is the first one found via npm)

It's much worse than that — ruby's non-standard libs all have at least three potentially-different names:

  $ gem install rack-cache
  $ irb
  irb(main):001:0> require 'rack/cache'
  => true
  irb(main):002:0> Rack::Cache
  => Rack::Cache

Only a japanese person could have come up with this clusterfuck — it's like dealing with Kanji!

I think you are putting too much weight on the name.

Humans brains are by nature powerful association engines. People tend to associate brand names with their purpose and (perceived) quality pretty quickly. If you've heard of that a once and the product turns out to be good then you are likely to remember it in the future. Why do you think Coca Cola is called Coca Cola and not Black Sweet Beverage? Heineken instead of Dutch Beer? Nike instead of Expensive Nice Shoes? Names do not have to be descriptive.

It confuses people for maybe a few minutes. Then they look for information, find it, and they move on. There's absolutely no point giving products generic names because in the long run it hurts the authors by being unable to differentiate themselves from others who do the same thing.

Don't know what "nokogiri" is? Search the internet and the first result will tell you. Looking for an XML parser but don't know its name? Search the internet and the first result likely gives a good recommendation.

Two second google search would suffice http://ruby-toolbox.com/

What was the query?

'gem -r -d search' works pretty well.

not much better in python either, or any language. How does one name an xml parser beautiful soup?

It is an html parser, not an xml parser. It was probably named as a tongue-in-cheek reference to adding some beauty to the tag soup that was state of most (mal-formed) html pages out there at the time of its creation.

Reply on news.ycombinator.com