RSS

Tag Archives: ruby

Ruby – ARGF interesting but destructive

[Update 2012-07-08] I reviewed the ARGF source code and it explicitly closes the file. This is silly nonsense because (a) #close is supposed to perform a File::close and then advance to the next file in the list. (b) #close and #skip are not documented as aliases (c) the doc for #skip does not say anything about side effects.

Thanks to the guys at pragprog I have been rereading pickaxe. And in the process I found the ARGF class. It seemed pretty interesting because it was supposed to process ARGV as if all of the arguments represented files. (state of the files not withstanding).

The problem, however, is that it just feels improperly implemented. The first time you do anything with ARGF is has already opened the first file. And when you are on the last file where is no way to know other than checking closed? or fileno against the previous iteration. For example I would expect something like this:

while ARGF.more?
ARGF.skip
# and then do some stuff to the file
end

Instead you have to do this:

while not ARGF.file.closed?
# do some stuff to the file
ARGF.skip
end

or the while loop could be:

while ARGF.argv.size

I suppose there is no much difference between the first example and the second from a structure perspective, however, there are side effects. Once you start to use ARGF the first file is opened. That might be a good thing and it might be bad. But it may also mean handling exceptions in more than one place. It certainly feels more verbose. Specially if you want to count the number of params by reusing ARGV.

The big floppy issue, however, is that ARGF is destructive.  Since ARGF connects to ARGV via a reference meaning that external code can alter the ARGV and the effects will be reflected in ARGF. The opposite is true too.  When skip’ing over parameters ARGF appears to be removing the file from ARGV. Meaning that you cannot do anything with argv/ARGV after the fact as it has been consumed. (This side effect is never mentioned; in fact the documentation for ARGF never even hints at this.)

The third piece of code makes processing easier but unexpected.

 
Leave a comment

Posted by on 2012/07/08 in ProgLang

 

Tags: ,

The hardest aspect of software development!

The hardest aspect of software development is keeping your systems configured properly. Installing tools like rvm, govm, virtualenv and so on is pretty simple but once you’ve installed the base packages there are any number of dependencies that you have to deal with and getting a consistant install is no less difficult or tedious than TDD (test driven development).

I had a strategy once that included using a VMWare instance that I would use to build a base-line configuration for the target project. Then share that baseline with others on the team. This strategy came to me after years of dependency documents, repository sub-projects, storing dependencies in the project tree, and even dedicated target build/test machines which is the closest to the VM strategy.

I think it would be ideal if there were a script or program (and it might already exist) that would reverse engineer your current dependency list; installed gems or pips etc… and generate an install script that would would work cooperatively with your rvm or virtualenv so that you or a team member could re-build the dev/staging/production environment from scratch as easily as possible.

 

 
Leave a comment

Posted by on 2012/07/07 in architecture

 

Tags: , ,

N-way file merge Perl, Python, Go and Lua [Java, Ruby]- Compared

[Update 2012-06-22] Here is the java version of this assignment. It is/was awful. Once you stray from OO, in java, the code inflates like a sea monkey and clearly OO is over the top overkill.

[Update 2012-06-22] Here is the Ruby version of this assignment. I like it’s compactness although that came at a steep price as accessing hash elements meant clunky dereferencing and string comparisons were just awful. [That was an error on my part; works as you'd expect]

Not to beat a dead horse but I now have 4 example implementations in Perl, Python, Go, and Lua.

I did my complaining about Lua in a previous article, however, in summary here… this example in Lua is verbose and lacks consistency. I’m not expecting to reduce this to a single LOC (line of code) but I would have liked some additional APIs that would have implemented more efficient algorithms based on internals knowledge. Or at least well documented idioms.

The Go example was fun because the version 1.x of the toolset was simple to use. I would regularly execute “go run merge_tick_data_hash.go file1.csv file2.csv” and it would run like a champ. The only challenge is/was that simple errors that most dynamic languages permit until the code would actually execute would cause the compiler to barf. And initially I had no idea they were compiler errors; but it was easy enough to get used too. The compiled version of the code was lightening fast to startup and execute even though it was 1.4M bytes in size.

The Perl version took some doing. I was able to reduce the LOC and optimize the code quite a bit. I think there is still some room for improvement based on the Python implementation which was just a few lines smaller because it had the benefit of being written last. In this case I sacrificed adding the filename to the %ticks hash and that reduced a few LOC but added some de-referencing which “might” be optimized by a good JIT; cannot say for certain.

I’d like to compare these implementations to a Ruby version but I’m just not a fan of RVM this week. As for the remaining candidates. I have to admit that I really liked the Go version, however, I do have a complaint that while “Go” seemed like a good name for the project when it started. (prefix for google) right now it’s hard to do google searches. GO is such a small and common word that there is no way to optimize searches. One strong advantage is the static linking once the project is compiled.

 
Leave a comment

Posted by on 2012/06/21 in ProgLang

 

Tags: , , , , ,

Compare table length in Perl and Lua

In the beginning there Perl; and in Perl was the array and the hash. Later there was Lua; and in Lua there is the table. The table in Lua seems to be both an array and hash, where they are both implemented as a hash. But let’s start with Perl.

In Perl (don’t panic there are idioms that make this less straight forward):

# length of an array
my @a = (4,5,6);
print scalar @a;   #-- prints 3

# length of a hash
my %h = (four=>4, five=>5, six=>6);
print scalar keys %h;    #-- prints 3

In the array example I’m thinking that the number of elements in the array is actually stored in the array and that the function of converting the array to a scalar causes Perl to return the stored value. I really hate the idea that Perl might be counting every element in the array every time this was performed… and if it was then that might justify storing the length locally for the different uses although this get’s funky when multi-threading.

As for the hash version.  The keys() method exports the keys held in the hash as an array which is then converted to a scalar as in the array example.

In Lua (go ahead and panic as the code is ugly):

-- length of an array
local a = { 4, 5, 6}
count = 0
for _ in pairs(a) do count = count + 1 end
print(count)
print(#a)

-- length of a hash
local h = { four = 4, five = 5, six = 6}
count = 0
for _ in pairs(h) do count = count + 1 end
print(count)
print(#h)

In the array example the values 4, 5, 6 are assigned to index’ 1, 2, 3 respectfully. When counting the pairs() we are evaluating each entry in the table just like the perl hash function keys(). However, when we execute #a, unlike the perl array functionality, Lua starts initialized an index counter at ’1′ and increments it so long as the value is not nil. So in the case of the array these two methods are synonyms.

In the hash example the count method works exactly the same, however,  the #h fails completely.

Clearly the language designers did not think this was a big deal. Whether it was because counting the pairs is truly efficient or there is another more efficient way or the reader is actually expected to fill in the gaps with more robust code. After all Lua is not made up of too much code anyway.

I’m not certain that I really care but it is frustrating. Specially when modern languages like Python and Ruby seem to have done away with particular issue. And as a side comment we should do away with idiomatic programming.

 
Leave a comment

Posted by on 2012/06/20 in architecture, ProgLang

 

Tags: , , ,

Ruby Contracts Gem – Contradiction?

I continue to buzz Ruby like an Army Combat Drone. Recently I captured a post that caught my attention. The basic idea is:

The addition of decorators to Ruby methods so that params and return values were of a particular type.

To my knowledge the absence of a “contract” is actually a strength of Ruby, Python and Perl. In fact Python specifically recommends that one should not check the param types and that throwing some sort of type exception is preferred. (it in one of the best practices docs).

The only reason I can fathom for this “Contracts” gem is so that programmers coming from strongly typed languages (java, c, c++) can transition easier. The only problem is that there is no place for this sort of coding when on a team of experienced programmers in that particular language. The establishment is going to have it’s way of doing things and it will be on the new guy to assimilate.

Here is a perl edge case:

sub add($$) {
    my ($a,$b) = @_;
    return $a + $b;
}

And here is the preferred version:

sub add {
    my ($a,$b) = @_;
    return $a + $b;
}
Notice that the difference is that the ($$) has been removed from the first example. The reason being that it is redundant as the first line of the function is

my ($a,$b) = @_;

and it sufficiently describes the function.

“Contracts” is less of a bridge and more of a beaver damn.

 
Leave a comment

Posted by on 2012/06/15 in architecture, ProgLang

 

Tags: , ,

Another killer app for Perl

I’ve written about perldoc and CPAN as being Perl’s killer apps. I’ve also written about Ruby’s RVM and Python’s Virtualenv. Now I get to write about Perl’s perlbrew.

I’ve been tweeting(@rbucker) with a couple of techies today s a result of a comment that one of the made. Something to the effect that virtualenv was going to be made a core python app. Suggesting that it was going to be rolled into the distro.

If you’ve been around a while and you have a little intuition… it should be going off at this very moment. I’m not going to go into the high level discussion that I had with these guys nor am I going to go into the micro details. What I will say, in summary, is that this is a very bad idea and as a result virtualenv should become very unstable as a result.

Which got me thinking about Ruby and Perl. On the one hand I know that Ruby has RVM but is there something for Perl? Yep! As I write this article I have installed perlbrew and I’m installing Perl 5.16.0 at this very moment.

I do not know anything about perlbrew at this point other than it seems to be installing Perl properly and in userspace where I want it. If all goes well and I have the required prerequisites all should be well in the next little while. I really like Perl and Python. The idea of dumping Python feel like jumping the shark. Perl-6 and Python-3 feel unnatural at the moment. I’m just hopeful that virtualenv and perlbrew can keep my world glued together until the rest shakes out.

 
 

Tags: , , , , ,

Java: everything should be public

If not everything then at least all of the methods and classes.

I wish I new the history of this decision and more importantly what is keeping this artifact of the language in place. I suppose from a historical perspective it has not really caused any trouble. The language designers had some ideas that were rooted in commercial software and commercial software libraries. I’m remembering various commercial JDBC drivers, crypto drivers, X.25 drivers, MQ drivers. But in the modern development environment black box development is no longer the norm; so it might be time to change with the times.

Looking at Ruby, Perl, Python, even Groovy. They are all dynamic languages. They are all compiled or processed at runtime and so there is no benefit to private or protected objects. The code is there for the reading if you are so inclined. Java and C++ are compiled languages. Java does have some capability for runtime meta programming. But while historically developers purchased libraries to supplement the core JDK, they are now using Maven repositories like Ruby’s Gems, Python’s PyPi, and Perl’s CPAN.

private and protected are now more for vanity than any “protection” that the Java’s creators had envisioned.

 
Leave a comment

Posted by on 2012/05/09 in ProgLang

 

Tags: , , , , , , , , ,

In defense of dynamic languages

There are a good many truths and there are a better set of likelihoods. Given the current state of dynamic languages today they are less performance than static and functional languages, however, it is also true that dynamic languages are more productive than static and functional languages. (I am not talking about savants)

Don’t optimize your code at the first stage. First make it right, then (if necessary) make it fast (while keeping it right). –erlang programming rules

It is likely that regardless of the size of your project, the size or makeup of your team, or the breakthrough that you think the project represents… that your project is going to have average results at best. The Google’s, FaceBooks and Twitters of the world are extreme edge cases. As proof, look at the iPhone app store. There are over 600,000 apps and only a very small fraction of those apps have the following that Angry Birds does.

So before you go off in a corner reinventing the wheel in your favorite language consider this. WHat is going to be your return on investment? I cannot blame you for learning a new language or tool that would enhance your marketability or even just for hobby sake. But if your intent is to make some money and maybe a little independence they you really need to consider your ROI. And if you’re making money then rewriting your killer app in whatever killer fast programming language is available (and popular) will make make plenty of sense.

This is why I’m hot on python and python’s django, tornadoweb, flask; perl and perl’s mojolicious; ruby and ruby’s sinatra and rails; redis, sqlite, zeromq.

PS: While I’m not a fan of erlang, partly because of what it represents, I really like it’s Programming Rules and Conventions(PRC). By comparison python’s PEP-8 is amateurish. The PRC starts off with ideas like the one quoted above and giving you ideas on how best to approach the problem. This is like python’s PEP-20 but again it’s like signing your name with a crayon instead of a fountain pen.

 
Leave a comment

Posted by on 2012/05/03 in architecture, ProgLang

 

Tags: , , , , , , , , , , , ,

RVM excels over virtualenv… (update) NOT!

[Update 2012-04-21:] What a freakin’ mistake. Rails is such crapware that it defies explanation or description. I had just completed installation of rails on 2 different Macs and an Ubuntu server. I then created my “demo” project to make sure that everything was installed properly. And I discovered that I had not. This was was a pretty good patch and it went flawlessly. When I went back to my project and tried the “bundle install” each of the projects barfed. When I finally got the ubuntu installation to fein completion I ran “rake about” and I now get javascript errors. I get it, I’m missing more prerequisites. This reminds me that I had a complaint about rub, rails and gems. The dependency stack is just too freakin’ deep. There is no way that anyone knows everything from shell to DB. Think about the autoconf tools. It is so long in the tooth these days that it is more magic than  reality. The difference is that the executables there are clear, maintainable and reproducible. Ruby and Rails are no more eliteware than erlang. Show me someone who claims to be a Ruby expert and I’ll show you someone who build vaporware on pretendware. (I’m pissed for spending 100′s of dollars on books and RubyMine; and weeks letting my mind consider that there was some value in Ruby; for taking a Ruby Job in Alabama… which I was converting to anything else… and for scanning the ruby job boards over the last few months) Virtualenv might not support many different versions of python, however, python just freakin’ works and the same can be said for Django.

[Update 2012-04-20:] With RVM you can install just about any version/revision of Ruby that suites you. I am in the process of installed 1.9.3-p194 right now and RVM supports a number of different flavors like MacRuby, ree. Virtualenv, on the other hand, is at the mercy of userspace installation of the target python and even then versions like pypy require patches not yet pulled back into virtualenv. I cannot say that this is the only reason for moving to Ruby from python but it is pretty strong.

… when dealing with the issue of the language versions. RVM gives you direct access to the versions of ruby currently available and installed and virtualenv puts the burden on the user. And installation is a pain in the ass,

 
Leave a comment

Posted by on 2012/04/21 in updates

 

Tags: , , ,

Ruby MetaProgramming? Really?

Let’s tee one up with another visit to PragProg. This time it’s metaprogramming. I do not take issue with the book or the publisher. The book is well written and if I did not like the publisher I would not be buying from them,,, and I have plenty.

In the very first few pages of the book the auth describes metaprogramming:

  • wrappers and “magic”…
  • bend the syntax…
  • remove duplication…
  • stretch and twist ruby…
  • … and code generation

Which inspired me to tweet these:

  • Ruby metaprogramming may be best implemented by ruby l337 but even they move on. It’s not scalable or sustainable.
  • Ruby metaprogramming is unmaintainable in any environment where maintenance is important. Worse than read-only Perl!!!
  • Ruby metaprogramming = NoRuby

Code generation is reasonable and good. You can leverage data to produce realized code paths instead of completely data driven code paths. In many cases debugging is easier because you test and debug the fragments and how they stitch together instead of every possible combination as driven by data alone.

But that’s where metaprogramming shines.

All of the other meta attributes suggest that Ruby “bend and twist” to be something other than what it is. And that is what drove me to tweet. It’s Ruby but not really Ruby... How much metaprogramming would it take for Ruby to simulate python?

Traditionally metaprogramming was described by code and data… not by adjustment to the syntax or the language. One needs another name for whatever that syntax mangling function is called. But also, good luck to you and your read-only-ruby.

 
Leave a comment

Posted by on 2012/04/18 in architecture, ProgLang

 

Tags: , ,

 
One Page Docs

Creating a library one page at a time.

One Page Bugs

Reducing the friction of writing and fixing bugs or features.

Follow

Get every new post delivered to your Inbox.

Join 223 other followers