Oleg Andreev

The biggest advantage of dynamic languages is interactivity. With dynamic language you can open any part of the running system, change something and see how it behaves under these particular conditions, immediately. This dramatically improves design cycles, completely eliminates compile lags and helps to debug efficiently.

Smalltalk/Self guys got it more than 30 years ago.

It is pity to see how current Ruby/Python/JavaScript/etc. frameworks are less interactive than C++/Java within some modern IDE (like Visual Studio).

If the dynamic VM is a move forward, then next step are highly interactive tools. Everything else is just the same old story.

See also real life benefits of dynamic languages at stackoverflow.

1. Lisp and Smalltalk

2. Immutable state is something I don’t care for, so it worries me that referring to map, filter, etc as “functional programming” may give people the impression that they have to swallow this immutable state business in order to use these things.
The Danger of Equating Map and Filter with Functional Programming

3. Objects vs. Closures

Inspired by You Can’t Get There From Here c2.com article

Every incremental development process suffers from increasing module coupling by definition. Smaller steps give you flexibility to turn around a current point in a development process, but not to jump out of it. With incremental process you are reaching local optimum: the best solution for the problem you are not solving today. But this is not the real issue (at least, you can sell it to someone else). The issue is that you can’t move incrementally from the local optimum due to high coupling. The only way out is to take independent components which are suitable for the new task, jump out of the current point and set up new process based on these components. Efficiency of this jump is measured in total relevance of all these components.

In other words, we need some insurance that some critical amount of investment (1 month, $100K etc.) is not thrown away as a whole thing. To achieve this we should keep the work splitted into small distinct pieces, each of the acceptably low cost.

It is usually recommended to refactor the code in order to extract abstract entities and generalize their API. However, it looks like a stupid game in the same playground: a single project directory tree with 1000 files in it.

Lets take a look at search tree balancing principle: each node should have some optimal number of children. If it has too many children, we have to evaluate linear search in the node. If it has too few, we have to evaluate linear search through the linked list instead of a tree.

Our asset is the code. The efficient evaluation of the code requires to keep it in a good shape. This could mean the following:
- N lines of code per method
- M public methods per class/module (+ M private)
- F modules/files per folder
- L levels of folders per library/dependency
- D libraries/dependency per product/another library.

Each figure is average. You can have 10*N lines method as long as there are ten N/10 line methods. The ultimate goal is to have maximum L*F*M*N lines of code per program (as well as M*N lines per class).

Figures could be something like that: N=7, M=7, F=17, L=3, D=7.

The idea is to limit the amount of code you work with. If you do so you would be pushed to extract least coupled parts out of the project, therefore making them more valuable individually and giving more focus to the essentials.

This implies slightly different mindset comparing to traditional refactoring. You do not look for a way to restructure the program just for making it cleaner: you look for a way to keep as little code as possible by extracting least relevant code into separate external modules.

We assume you had Leopard with standard Ruby shipped with OS, tons of macports and rubygems already installed. Then you install Snow Leopard on top of it (not clean install).

The problem is that standard 10.6 dynamic libraries all went 64 bit and could not be linked with 32 bit code. This could be fixed by rebuilding/reinstalling all the macports and rubygems.

1. Install the latest Xcode shipped with Snow Leopard.

2. “port” command will fail with a message about incompatible Tcl architecture. The proper version of macport is 1.8 which is not released yet. You can obtain it from SVN trunk and built it by hand (./configure && make && sudo make install). I have also added trunk version of ports to sources.conf (see the link above for instructions) to be sure that I have the latest SL-compatible ports in the list. Maybe this is was wrong assumption, but it worked for me just fine.

3. Remove all ports:
$ sudo port -f uninstall installed

4. Update rubygems to 1.3.1 at least (please google for instructions).

5. Remove vendor gems (gem uninstall refuses to remove them and fails to do batch remove):

$ gem list | cut -d" " -f1 > installed_gems
$ sudo mv /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8.bak
$ sudo mkdir /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

Note: installed_gems file contains a list of all installed gems so that you can cat and xarg it for installing all gems back.

6. Uninstall all gems

$ sudo gem list | cut -d" " -f1 | xargs sudo gem uninstall -aIx

7. Make the rubygems use 64 bit architecture.

$ cat installed_gems | xargs sudo env ARCHFLAGS="-Os -arch x86_64 -fno-common" gem install --no-ri --no-rdoc

Note: it is NOT i686 (as I thought it should be), it is x86_64 instead.

Here are convenient aliases for “sudo gem install” for both architectures:

alias sgi32="sudo env ARCHFLAGS=\"-Os -arch i386 -fno-common\" gem install --no-ri --no-rdoc"
alias sgi64="sudo env ARCHFLAGS=\"-Os -arch x86_64 -fno-common\" gem install --no-ri --no-rdoc"

You may also put alias sgi="sgi64" in your .bash_login on snow leopard.

Now we all can proceed doing productive work. \o/

References:
1. http://www.nabble.com/-MacPorts—19446:-openssl-fails-to-compile-on-x86_64-td23247203.html
2. http://jaredonline.posterous.com/got-mysql-to-work-with-rails-in-mac-os-106-sn
3. http://cho.hapgoods.com/wordpress/?p=158

Object interface is a set of messages with defined behavior the object should respond to.

In statically typed languages, interface is required by type declaration. In dynamically typed languages this is done by telling object of unknown type to cast itself to the desired type.

# User's code expects object responding to #to_page
# when casted to page, we expect proper #render and #size behavior
class SomeController
  def process(object)
    page = object.to_page
    page.render
    page.size
  end
end


# 1. Page class with #to_page interface returning self
class Page
  def to_page
    self # return self since it is already a page
  end

  # page public api

  def render 
  end

  def size
  end
end

# 2. Non-page class with #to_page interface
class AtomicBomb
  def to_page
    # return a relevant article
    Page.wikipedia_article("Nuclear weapon")
  end
end

# 3. Class without #to_page, but with #render method
# fails with "object does not respond to #to_page" exception
# and does not cause undesirable side effects
class Foo
  def render
    # very specific nasty rendering method
  end
end

# 4. Class without #render
# fails with "object does not respond to #to_page" exception 
# rather than with less descriptive "object does not respond to #render"
class Baz
end

This technique minimizes duck typing collisions by reducing the number of exposed methods to a single “to_{unique_type_name}” method. It also protects you from inventing obtrusive method names with type prefixes such as “page_render” or “page_size_in_characters” (see example above).

The rule of thumb:

1. When API consists of more than one method, introduce #to_my_type method

2. Whenever you receive an object from an unknown source (e.g. defined in a different file), use explicit type casting with #to_some_type method.

Note: never ever make others ask about the kind of an object using #respond_to?. This method should be used for legacy code and indicates possible duck typing issues.

Also, #is_a?(SomeAbstractInterfaceModule) is considered badly designed compared to #to_* methods.

Parser.js
JSONGrammar.js

The parser enables you to write BNF-like rules directly in JavaScript without need to compile the file (like with Ragel, YACC, Bison, ANTLR etc.)

The grammar is a JS function with 11 arguments (9 rules and 3 hooks). Each rule gets two arguments: text (string) and state (arbitrary value) and returns a tuple of new text and new state (or null if rule was not matched). Parser walks character by character from left to right. text is always a tail of the initial text. Generally, text is empty string when parser finishes.

All(rule1, rule2, …) — a sequence of rules. Example: All(Char(“[”), list, Char(“]”)) defines a JS array.

Any(rule1, rule2, …) — “OR” rule for any number of rules. Example: JSONValue = Any(StringRule, ObjectRule, ArrayRule, …)

Char(alphabet) — character matching rule. Example: digit = Char(“0123456789”)

NotChar(alphabet) — inverse of Char(). Any character — NotChar(“”).

Optional(rule) — tries to match rule and skips it if not matched. Example: optSpace = Optional(Char(“ \t\r\n”))

EOF — matches the end of the text. Fails if text != “”.

Terminator — terminates parser. That is, always returns empty text.

Y — Y-combinator for defining recursive rules. Example: X = Y(function(x) { return abc(x) } ), where x is equal to X. Google for more info on Y-combinator.

Hooks enable you to actually build some structures using your grammars. Every hook returns a new state value to use in further rules. You should avoid mutable state values because some rules may be thrown away if not matched later (remember: this is a recursive parser!). For example, use array.concat([value]) instead of array.push(value).

Capture(rule, function(buffer, state1){ return state2 }) — captures raw string buffer to store in the state2.

Before(rule, function(state1){ return state2 }) — creates a new state for the rule (e.g. creates empty array for array syntax).

After(rule, function(beforeState, afterState){ return newState }) — creates a new state after successful match. You can put nested values to the container if beforeState is a container before rule parsing, afterState is a nested value (after rule match) and newState is a new container with this value.

See usage examples in JSONGrammar.js

See the parser source code in Parser.js