Define what a micro library is

[solnic]

What's more important - LOC or functionality provided by a given library? I'm leaning towards functionality especially that narrow scope of a library usually comes with a low LOC anyway. I wouldn't set any kind of limits because that would be harmful.

Another thing is dependencies - personally I dislike the argument that if a library has dependencies then it's considered as "big". One of the principles I'd love to highlight via microrb is focusing on interfaces and making it easy to integrate small libraries with each other with a clear separation between lower-level tools and higher-level abstractions built for convenience (think DSLs mostly). This obviously means that I'm in favor of libraries that actually do depend on other libraries.

Thoughts?

[rkh]

Yes, I think SLOC count is an important metric, as more lines of code tend to reflect on complexity, especially when talking about orders of magnitude. But often longer code is better than clever code.

[rkh]

The one advantage of SLOC count is that it's easy to measure.

[pote]

Agree in that there is no shame in a library having a bigger LOC count at all, it's a somewhat useful metric to help somebody gauge the perceived complexity of a library - we shouldn't put it on a pedestal, but neither should we ignore it, just use it as another data point the same way we would with code climate metrics.

[solnic]

I agree that it is an important metric but I'm definitely against setting any kind of global constraints. I can see here libs with 200LOC and 2kLOC. I probably don't see here libs with 20kLOC though.

[soveran]

I think we need to put a limit on LOC, even if it's high, because otherwise the "micro" part is hard to justify. Also, listing the LOC of a library is important, but first I need to clarify what concept of "microrb" I had in mind prior to this conversation. In fact, I'm now realizing we all had slightly different ideas about it.

For me, it was all about minimalism, spartan programming, unix philosophy, or whatever you want to call it. Tools following those ideas serve two purposes: first, they provide power by focusing on a single feature or a single problem. Second, they help people learn. That's why focus and clarity are important and should be highlighted.

As a consequence, a 1 MLOC library is worse as a learning tool than a 1 KLOC one. I'm not saying there's no room in the world for 1 MLOC libraries, I'm only saying that they don't serve the purpose I originally envisioned for this project.

[pote]

The discussion on what exactly to defines complexity is an interesting one as well, I'd like to refer to something I read a while ago on "Worse is Better" against the "MIT approach".

As per what I see on this discussion it seems @solnic might tend to agree with the MIT approach, I myself find the Worse is Better philosophy to resonate more with my thinking, I'll try to explain why briefly as this post is already pretty large.

I'm preparing a talk on the topic of simplicity in software and have been thinking about this a lot - I'm still unsure of a lot of things and can change my mind on pretty much everything - but when trying to define what "simple software" is I found myself thinking that the question only makes sense in the context of what we are trying to do with a library.

In my mind the moment we care about the implementation of a library is the moment we're trying to understand how it functions, at that point what we care about is being able to read the code and see what is happening in a straightforward manner, the Worse is Better approach favours simplicity of implementation over completeness of features which I think makes it easier to understand any given library, I believe that the best programming happens whenever you understand the most about the inner workings of the tools and layers of the system you're developing - which is why I like that point of view better.

I'd love to see your thoughts on all this though.

[solnic]

@soveran I'm actually in complete agreement with you here...

I'm just a bit allergic to strict constraints. Imagine we put a limit of, I dunno, 3k LOC. Then there's somebody with a nice lib with 3009 LOC. What do we do?

I guess we need to find a nice way, a process, of deciding when a library can be listed here. It shouldn't be too strict IMO. I absolutely agree that we should be in favor of libraries that focus on solving just one problem. But even that might be tricky to define sometimes.

[solnic]

@pote I'm somewhere in between those two things :)

[pote]

It's definitely hard to choose, there is merit to both viewpoints.

[soveran]

Let's say we are concerned about focus and clarity. Both are subjective criteria, even if they can be quantified objectively to some degree. We have lots of choices, and I will list some ideas starting with the less restrictive:

1. The website can list the objective metrics we can gather, like number of dependencies, LOC, cumulative LOC, etc. The users can then decide what's important for them. They will still have to look at the code to make sure it's clear and focused.
2. The users can "sponsor" certain libraries by approving their focus and clarity, or by rating them in a scale. As the criteria is subjective, this could be a way to provide some hints to users that share a similar taste. The downsides of this approach are the same that affect any popularity contest.
3. The website can rate libraries in terms of focus and clarity. This removes the crowd from the equation and could bring some degree of favoritism and drama. In all the previous cases, the amount of libraries listed will likely grow to match rubygems.org. In this case, this filtering will shorten the list.
4. The website can provide an explicit filter based on objective metrics, plus the ability to bend those limits in special cases. For example, sinatra might be allowed even if it exceeds some limit, and almost-sinatra could be left out even if it passes.

There are of course many other options we can evaluate.

[plexus]

Great discussion, lots of good points. Some things I'd like to add,

My personal subjective projection of how I saw microrb was simply a way to promote a style of development that deviates from the Rails style. Many libraries are built on the assumption that this big framework is always present. Rails itself has a philosophy of absorbing functionality, look at the recent Timecop example. Sub-parts of Rails are often not, or only with much effort, usable in a non-rails context.

For me the opposite is having isolated but easily composable chunks of functionality, each with a narrow focus. If a library's goals are modest, then it will more quickly reach a point of being correct and complete, and hence stable.

Regarding what constitutes "small" or "simple", I think we have to accept that hard limits will not work, it's simply too subjective. It all depends on what problem you're solving. Sinatra is a very simple web framework, but to be a decent web framework there's still a lot that needs to happen under the hood. I do see value in making lines of code visible, together with flog scores. (The latter disadvantage code that is too clever.) This way you get an idea of the complexity you pull into your app when you pull in a certain library. Also by having those numbers I'm assuming we will see a certain range of what is typical for what we consider "micro". Which projects get the "microrb quality label" can be discussed case by case, with a simple yay/nay vote afterwards.

[soveran]

I think I like the idea of listing the flog score too.

[solnic]

Me too

[soveran]

OK, maybe we can start small and accept submissions. The first goal is to have something up and running in time for @solnic's presentation. An index of libraries with lines of code, dependencies, cumulative lines of code and flog complexity should be a great starting point.

[solnic]

Well that would be a fantastic starting point. I'm hoping to have...an index of libraries. Period. As a good start haha

[CrowdHailer]

Is it easy to measure interface size. perhaps the number of public methods on classes in the namespace. I think I micro library should definitely create objects only in one namespace. so we could use something like

require 'test-lib'

TestLib.constants.inject(0) do |total, object|
    item = TestLib.const_get(object)
    count = (item.new.methods - Object.method).count
    total + count
end

A few issues with the code above but the fact it can be automated has to be worth something.

[jarmo]

I didn't read the whole discussion above, but for me a micro library is some library which does one thing and does it well. Like unix tools usually.

I don't think that following any other metrics (like LOC) would add any value. Sometimes having more LOC is better than less, because the code then might contain less magic making it more readable ;)

TLDR; i don't think that you can "detect" micro library via some automated metrics.