Update to Post Regarding Hacking & Ruby

This will be a very short entry as it is rather late and I'm looking forward to sleep. I would do but I do feel that I have to get some observations off of my chest after the past 6 hours of exploring ruby (for the third time).

#1. Ruby isn't as intuitive as one might suspect. Maybe python and others of similar influence (groovy) have raised the bar too high in terms of dynamic language syntax and expectations. The standard ruby idioms are inconsistent and ill-named in several cases, mostly involving native data sets.

#2. Namespaces in Ruby are an even bigger mess than perl. To some degree, perl's system seemed to make sense yet from what I've read, seen and with which I experimented, I find the namespace setup for Ruby to be subpar and dare I saw far from fluid in implementation details.

#3. Ruby is indeed very slow, especially when working with the Array types in combination with large datasets and continual pre-requisite 'include?' method calls for each datum in said set. I did find that I was able to achieve the same results wanted via Hash population followed by a dump of keys to an Array with a noticable speedup, removing the need for the very slow 'include?' method. Membership tests are a joy of high level languages, but a drain on some resources, ruby more than others though without a doubt.

#4. The novelty of mutable and immutable version of method calls (collect! vs. collect, slice! vs. slice) is just that. A novelty. This is an ambiguity which I believe does not help to further ease of readability and usability. It further necessitates that non-standard library code implement similar idioms and 'practices' for uniformity's sake with the downside being a snowball effect in this area.

#5. Ruby isn't sure if it wants to be perl, c, smalltalk or itself as can be determined by the mix and match of terms, keywords and standard method names. It doesn't feel like a concrete language that was purpose built, but more like an object system with various sources for tacking on the remaining pieces of the language so as to round out the feature range.

These experiences with Ruby (for the third time) may have been different had I not been spoiled by Python (most notably), or were I not coding in the field for the past 15 years. This is not the case nonetheless. I couldn't see myself coding in this language for anything mission critical or heavy duty and after looking at the problems many of the ruby back-ended software systems and/or websites vs. the other high-level dynamic languages have suffered, it becomes quite clear when industry giants such as Google and IBM throw their weight behind Python.

This isn't meant to be an argument starting post about Ruby vs. Python as they can be found elsewhere, though if the shoe fits...

Arc: An evolution of Lisp/Scheme, or a outdated implementation at launch.

So the day has finally come in which prolific geek & insightful essayist Paul Graham along with Robert Morris released Arc, their evolutionary love child of Lisp & Scheme.  I think it is safe to say that many of us have (and will continue to) read Paul's wonderful essays on a multitude of geek and coder centric topics, and generally with much joy and agreement.   Many of us have been following the work that Graham and Morris have been undertaking with the new baby "Arc". 

Now that this day has arrived, we can see that it wasn't as deserving of all the pomp and circumstance to which we were planning for it to be attributed.  Seems that there are a considerable amount of deficiencies and intentional short comings to the language.  Normally this wouldn't be seen as anything out of the ordinary for a 'new' language, and would be generally a non-issue.  

The problem is that this is the year 2008 and people have come to expect more from their languages.  Ignoring established standards along with ignoring the need for designing to meet the needs of developers globally all the while using the cop-out of it being purely for exploratory programming is just bad form.   

The world doesn't need another Lisp, the original is wonderful just as it is, that's part of its beauty.  I don't see anything in Arc that couldn't be done as functions and/or macros in Lisp that required the entire 'creation' of a new language.  The way I see it is this; for prototyping as well as production usage we already have several languages that excel in those domains, specifically Lisp and Python.  

Generally the idea of rewriting existing languages with little difference from their predecessor(s) is a waste of time and effort which could've been better spent elsewhere.   There are exceptions to this scenario such as that of Ruby.  It is a language that in the past I used to dislike because of certain key flexibilities much akin to the reasons for spaghetti perl, but it successfully fixes many of perl's wrongs, and corrects some of Pythons short comings as well.  It serves serves enough of a purpose as that of supplanting perl with a better thought out design, and thanks to Rails, its future looks solid.  

Arc on the other hand is like a still born fetus.  Much was expected and there was potential to be just like its parent(s), but death was announced during a delayed delivery and upon further examination, it was discovered that it wasn't a proper offspring, but a clone in fetal form.  My advice to Paul and Robert is the following:  recall the release, and make it truly something worthy of release, with proper compatibility and compliance with modern norms.  Make it usable to others as opposed to just a few tinkerers interested more in lisp and scheme basics. 

An on a more pleasant note to Paul;  Please keep on writing your essays and providing your viewpoints as they are appreciated, I just wish that your judgement call in the case of 'Arc' was as well thought out as your writings have proven to be over time.