Step One: Insert Foot in Mouth

This is a follow up to my Your Fancy Language is Burdensome and Dangerous post.

Python and Ruby don't have the APL array/vector/matrix syntax built in to the core language. But a little nudge from someone made me do the little bit of research I should have done before I wrote that post. And I rediscovered that I did not originate the idea that these languages need array/matrix math syntax thought.

There is a gem for Ruby called NArray and an egg for Python called Numpy that not only add array syntax but also coherent coercion rules and the ability to apply functions across arrays without calling map. I'm glad I found it because they are easy as pie to use and do exactly what I wanted and a heck of a lot more.

Check out this Python example:

from numpy import *
a = array([1,2,3])
b = array([4,5,6])
print a+b #equals array([5,7,9])
print (a+b)/4
print (a+b)%6

Outputs
[5,7,9]
[1,1,2]
[5,1,3]

As you can see Numpy also replicates the integer type bug/feature which is very C like but is being dropped in Python 3000 in favor of coercing integers to float on divide. You can typecast the divisor to float to get floating point division and float results.

Your Fancy Language is Burdensome and Dangerous

I found this quote about the PL/I language in Wikipedia to be very poignant today. The quote's sentiment and the PL/I language are from the 1960's.

PL/I is considered by some to be a turning point where it was found that large languages with a lot of complexity that allow programmers to do almost anything (such as coerce types with no semantic relationship to one another) are burdensome and dangerous rather than "more powerful."

It echoes my low opinion of most of the toy languages that seem to be escapees from a Compiler 101 college course masquerading as the cure for the inability of some people to program. I find it to be very relevant to the object oriented mass hysteria and popularity of the latest scripting languages of the moment.

My opinion of C++ with the STL and templates and generic algorithms and iterators and iostreams is lower than my original opinion of C++ before it became standardized. What problem does all that junk solve. More to the point, what problem did object oriented programming ever solve beyond speed to delivery?

Object oriented programming is a morass and a tar pit. It's the all promise and no delivery. It eats up 90% of your programming time forcing you to write witty little programming ditties when you should be writing elegant, concise solutions that aren't 90% object oriented overhead.

Object oriented code hides not only the method invocation but also confuses the issue as to which method is actually called. Multiple inheritance in C++ and other languages demonstrated that the only part of multiple inheritance worth saving in other new object oriented implementations was the interface definition which is basically a template which is basically a macro. It saves you the onerous task of cutting and pasting. In C it's called a macro and it's frowned upon because it obfuscates what the final code does and looks like.

In summary. First write code quickly using only 10% of your programming time. Second scratch head and guesstimate what your code actually does and what are it's unintended consequences. Third hope there aren't any bugs that make your invisible untraceable code do something you didn't intend and use more resources then are necessary to do it.

I'm not saying I don't appreciate Python, Ruby, Perl, C++, Java, and the like. I'm just saying it's not that hard to write the little bit of code it takes to implement most software projects. Especially since the main benefit of most new languages is their extensive built in libraries. Not that you couldn't do the same thing in C by including the proper headers and linking in the proper libraries.

To be brutally honest I think in assembler so even C seems a bit like unnecessary overhead and a bunch of macros hiding the actual code.

I've been reading up on a couple of APL like programming languages J and K but after reading some of the original code for the original J implementation all I see it a bunch of nested for loops creating everything on the stack and avoiding calls to the C standard library to allocate memory.

Now I like APL and I hope to write my own version of it one day because it solves a real programming problem through it's expressiveness. The problem it solves is how to communicate complex and simple vector and matrix operations programmatically to a computer without having to jam a for loop into your equation. The analogy would be the poor man's version tacked on to most of the recent programming languages with list comprehensions and regular expressions. Which are not the same thing.

There are some nice examples of K and J at Wikipedia. I'm not recommending checking out APL as anything other than an educational exercise. I could kick myself for not learning it sooner as it shows how a well thought out programming language was written way back in time that blows the doors off all the fancy flavor of the year languages which waste our time by forcing us programmers to learn an unending stream of new syntax with exceptions that can't even express programming logic as simply and concisely as the A language, APL(A Programming Language) could more than half a century before.

Rails Requires RubyGems >= 0.9.4 Error on Mac OS X

Updated 2008-10-08:
Please note that I forgot to mention in this post the fact that Ruby on Rails is installed by default with OS X Leopard. This blog is most helpful to those who had previously installed rails using MacPorts and now want to move to the Apple supported version that comes with OS X Leopard.

I was following along with the Apple Developer Connection article that shows how to update and use the version of Ruby on Rails that comes with Mac OS X Leopard. I followed through the article without a hitch. Successfully creating the Events Rails Site and viewing it at localhost:3000. The only change I made outside of the article's instructions was to add the script/generate and script/console commands to the same place as the article recommends the script/server. I figured keeping the original data model definition commands with the rails project would help if I wanted to make any changes to the data model later. I moved the data model definition commands to a shell script located in the top directory of the project. Which will make a nice portable design convention. I have seen that method mentioned in a blog post before.

While I was browsing around the running instance of the Events rails site I decided to do a full update of all the gem packages on my system by way of "gem update" without the "--system". Big mistake or so I thought when I tried to start my own rails project a day later. I couldn't even get the generate commands to run. The response from every script/ command was the same "Rails requires RubyGems >= 0.9.4. I googled around for the solution which always seemed to say remove the Leopard version and install the MacPorts version. Which I didn't want to do since I was trying to get rid of the duplicate MacPorts packages in the first place. In fact I had thought I had removed all the ruby packages from MacPorts. But on reinspection I found 4 versions of Ruby installed and one active a la "port search ruby and installed". First I did a "port uninstall ruby and inactive" to get rid of the old versions. Then I found a ruby gem I had somehow missed when I had done a "port uninstall rb-* and installed". After removing the lone gem I got rid of the installed and active version of Ruby via "port uninstall ruby". A quick verification of /opt/local/bin verfied that there was no longer a ruby or gem or update_rubygems command left.

Of course I left out the part where I removed all of the manually installed gems under /opt/local/lib/ruby/1.8/rubygems by "rm -fr / opt/local/lib/ruby/1.8/rubygems". Don't quote me on that path as I am writing this post on my iPhone and recalling it from memory. I only know the path because I also reinstalled rubygems manually before I figured out what the real problem was. I would probably have missed the real problem if I hadn't installed rubygems with "ruby setup.rb" after downloading it. The install commands showed RubyGems beings installed to /opt/local/... I had to remove that copy of RubyGems manually. Which wasn't so hard. All the install commands with the full paths of the installed files were still in my scrollback buffer.

I also didn't mention that I had uninstalled all my gem packages from the Leopard side of things. Including the original packages under /System. Luckily one of the articles I'd googled had the complete list. It was easy enough to do a "gem install rails sqlite-ruby capistrano mongrel libxml-ruby ruby-openid ruby-yadis rubynode RedCloth sources ferret acts_as_ferret fcgi termios cgi_multipart_eof_fix daemons dnssd gem_plugin hpricot needle actionwebservice activesupport". The full list of preinstalled gem packages is available here. I abbreviated my gem install command to only include what is necessary as installing rails pulls in some of the other packages in the list like activerecord and rake.
Everything worked like a charm after that. Now on to writing that SFA app. After that I'll have to get back to my holy war to remove redundant MacPorts packages. I think I was up to removing those two verions of Python 2.4 and 2.5. Seeing as how Leopard ships with 2.5 and 2.4 was a buggy beast at best when compared to the speed and bug fixes of version 2.5.