I've just uploaded Date::Tiny 0.01 to the CPAN. It implements an very small date object for use in log file parsing and other light duties where you won't need to manipulate the date, in as little code as possible. If you do need to do anything serious with the date object, it can be automatically inflated into a full DateTime object as needed with a ->DateTime method.
This is the 4th module in the
When I wrote Config::Tiny, the first of the
The uptake and and popularity of Config::Tiny has continued to astonish me.
Obviously there is something very attractive about a small, concise, zero-dependency module that is fast and takes up almost no memory, even if it is a bit hacky and not quite as "pure" as it could be. Config::Tiny is implemented just as a hash of a hash that has been blessed as a convenience, so it's not strictly OO.
It's worth noting I get more positive feedback, both emails and in person, for Config::Tiny than I do for anything else I've written. It even ended up in Perl Best Practices as the Config module of choice for basic config file functionality.
Obviously the concept has struck a chord with the general userbase.
After realising the data structures were almost identical (largely just a HoH), I then cloned it and made CSS::Tiny. And although needed less often than a module for
Surprisingly, early and speculative concepts from the world of non-biological evolution may back up my tactic of shrinking down larger modules in this way. Scientists in this area are trying to answer one very large question.
"What are the general characteristics of evolution, regardless of form, and how do we measure them?"
The holy grail for this area would be one equation to express how "evolved" something (anything) is. The same equation should be able to demonstrate why a human is more evolved than bacteria, why a pre-nova star is more evolved than a new star, and how evolved a human is relative to a star.
One of the early versions of this equation (provided as an example for demonstation purposes, but by no means considered rigourous) would be something like this.
e = i / s / m^3
e - Evolutionary level
i - Unit of effective information processing
s - second
m - metre
That is, where the general evolutionary level of something is based on the amount of information that is processed by that thing per second, per cubic metre.
Since information processing in all forms requires an expenditure of energy, some of which is invariably lost in the form of heat, this also means (loosely of course) that you can use per-volume heat output as a metric to compare two entities for their evolutionary state.
For example, by observing that the human brain generates more heat per cubic centimetre than the Sun (it really does, there's just a lot MORE of the Sun) we can state that the human brain is more evolved than the Sun. Humans are also more evolved than a rock or a stapler.
Whether we are more evolved than a computer is trickier, due to the different natures of the information processing done by our brain and a computer. Things are also complicated by volume constraints. Our brain can't get much bigger without running into heat issues, and chips have similar issues of heat management.
But based on it's higher capacity for heat dispersal, the physical medium of the computer chip certainly looks dangerous as a candidate to ultimately out-evolve biological life in general, if the processing efficiency can only be raised far enough. As long as our brains continue to process information more efficiently per cubic metre however, our future should be safe.
Now I'm doing an awful lot of hand-waving here, but like I said, it's early days for the field of non-biological evolution.
But if we take this concept to software, it allows us to make some interesting predictions about the long term evolution of software.
Software has gotten something of a free ride due to the ever-increasing power of hardware, and there has been very little short term pressure to evolve along the long-term direction of efficiency.
But looking at our e = i / s / m^3 equation, we can fit software into it quite nicely. Assuming equivalent hardware, our per-second becomes per-clock-tick computational efficiency (speed) and our volume becomes memory size.
Thus for any software problem we could well observe that the long-term trend is towards software (in compiled and running form) that is fast and uses very little memory. Which is exactly what the mandate of
Doesn't look good for Perl though, with it's large memory usage.
But of course, these evolutionary trends typically take place of very very long time scales, so it has little relevance to us in the here and now, except at perhaps the level of decades.
The second part of the trend noted above is also interesting however. And that is that one of the indications of more evolved software is heat output per volume. And we can actually translate this as well.
If we assume the software is programmed into a FPGA, then heat output per volume can be taken (at least in part) as the execution density of the code.
That is, how often the average command within a program is run per second, the higher the better. So the first of the two equivalent code blocks below is more evolved, because each command fires more often on average than in the second.
foreach ( 0
print "Hello World!\n";
foreach ( 0
print "Hello ";
Looking a the sort of code we write on a daily basis, this strongly encourages the use of CPAN modules. This is particularly the case where you can get two completely different pieces of code using the same utility module, since those command will fire twice as often then if they were written seperately, and increase your average execution density.
For a large module or framework, where you are less likely to use it twice in two different places, the trend is greatly reduced.
If I were to go out on a very long limb, I'd ask if this might help explain why utility and often-reused components like URI trend towards a single dominant module, while frameworks tend not to survive as long and eventually get replaced.
It's food for thought at least...