Oleg Andreev

We have Bash already!

	case "$c$2" in
	--*=*) printf %s$'\n' "$c$2" ;;
	*.)    printf %s$'\n' "$c$2" ;;
	*)     printf %s$'\n' "$c$2 " ;;
	esac

Official Git autocompletion script for bash.

Every programming language lacks some useful features, which other languages may provide. Many experienced programmers know several languages and try to port features and semantics from one language to another. It looks terribly wrong and inconvenient when one tries to write Java in Ruby, as well as vice versa. When you try to make a paper-like layout on the web for a newspaper you are shooting right into your foot and get nothing except buggy quirky page behavior and sleepless nights in fixing css bugs.
When you are trying to invent classes in JavaScript you end up with 10 different (incompatible) implementations with bizarre semantics (“where is the ‘this’?”).

The world is overcomplicated already. Meta programming (building all these frameworks, libraries and DSLs) is meant to extract and polish The Knowledge and minimize future efforts. Instead, we have to learn more and more things over time instead of keeping strong focus relying on our past achievements.

The first rule of thumb for a smart programmer: respect your language, choose appropriate tools for each task. Invent your own tools if you have to, but do not break already existing ones.

Thinking Forth helped me to realize the essential part of the Better Language. It is a scripting interface to libffi. That’s it.

The requirements for such interface are: portability, turing-completeness, single thread, simple grammar, no garbage collector (hence, no garbage).

Using this interface we could bootstrap a system environment for a language of our choice and easily connect important libraries like libcoroutine, llvm, libgarbagecollector and many others.

What is the shortest example code which shows great flaw in Ruby comparing to Java, for example? It is a literal “string”. That’s it. Every time interpreter hits the literal string, it creates a brand new object. The only useful thing is that it is already mutable, so you don’t have to copy it in rare cases when you want to modify it. But in reality you end up with such kind of code:

# Yeah, these constants look kind of tacky. Inside of tight loops,
# though, using them makes a small but measurable difference, and those
# small differences add up....
C_asterisk = '*'.freeze
C_empty = ''.freeze
C_header_close = 'HTTP/1.1 200 OK\r\nConnection: close\r\n'.freeze
C_header_keepalive = 'HTTP/1.1 200 OK\r\n'.freeze
C_slash = '/'.freeze
C_slashindex_html = '/index.html'.freeze
C1_0 = '1.0'.freeze
C1_1 = '1.1'.freeze
C_304 = "HTTP/1.1 304 Not Modified\r\n".freeze
Caos = 'application/octet-stream'.freeze
Cat = 'at'.freeze
Ccache_directory = 'cache_directory'.freeze
Ccache_extensions = 'cache_extensions'.freeze
...


The first thing “Better Language” should implement is source code being a first-class object with all the literals instantiated as immutable objects and referenced by this object. This helps to resolve a lot of issues with floats, strings and regexps.

However, the interesting things remain:
1. Complex literals should be recognized: like JSON (Arrays and Hashes) full of other literals should also be an immutable object attached to the source code object.
2. Literals which include variable references should turn into new objects creation on each method call, but only in a case when the variables are not already immutably binded to some values. This brings us to a whole world of functional programming from Lisp to Haskell.

Object-oriented design lets us avoid a bunch of “if-elsif-else” lines of code and use polymorphism instead. Sometimes it is extremely helpful to be able add or replace methods in core classes like strings, numbers and arrays. Ruby has such ability, but sometimes it turns out to be a nightmare. One library may redefine some String method for its own purpose and completely fuck up things in another library. In reality, library needs to redefine String class in that library’s namespace only. Let’s examine the possible ways to achive this:

1. In a pure OO-language only thing we have is message sends. When we write “string.size” we pass a message “size” to an object referenced by the local variable “string”.
Suppose, we have a library doing some low-level byte manipulations which relies on byte count behind “size” method. On the other hand, our application would like to deal with character count (one Cyrillic character is encoded with 2 bytes in UTF-8).
We want to keep the string in a same class (“String”) and also use the very same selector “size” for the different methods. So, how do we determine which method to choose, when class String receives the message “size”? The solution is to keep a thread-local stack of namespaces which is updated on each method call and ask it for a correct version of the “size” method. Maintaining such stack is not that hard, but method call becomes more complicated and slow: late binding overhead sums up with the namespace selection. Finally we have two virtual tables: for the eigenclass and for the namespaced extensions to that class.

2. In a statically typed language we know the type of the object from the lexical context. Thus, it is extremely easy to bind the correct version of the method according to that type using pattern-matching mechanisms, for example (see Haskell).

3. In case of polymorphic types, we have to curry type information with the objects and determine methods based on the lexical scope. However, we may reduce overhead if we use polymorphic virtual machine: such machine which injects itself into a compiled piece of code with its namespace in mind. In such case, message send is executed differently depending on the lexical scope of the code, where the send is performed. This allows us to avoid virtual table scans. But we have to waste memory keeping namespace-specific pieces of executable code.

I use Ruby everyday. I like C and Java for performance, but dislike their lack of expressiveness and build/configuration issues. I like Io’s garbage collector, coroutines and local state, but dislike its awful performance which cannot be optimized by design.
I generally hate Perl, but the idea of extensible grammar is interesting (remember E4X: why not to have an API to the parser to embed other grammars?).

In Ruby i’d like to extend core classes, but i don’t like to pollute other libraries with my helper methods. Thus, i need to narrow scope of some selectors to the lexical context.

I want pthreads, but with no implicit resource sharing: every thread must see only those resources, which are exposed for it explicitly. Communication between threads must be done through the efficient queues/pipes.

I want to compile arbitrary part of source code in runtime with arbitrary explicitly defined context. I want to have both portable bytecode and machine-dependent code and both serializable. Source code and runtime state must be serializable too.

At the core of the language, I want to have an extensible parser/interpreter, FFI and a compiler API.
The language should suit well for object-oriented programming, but should not be purely object-oriented.

I have removed EMRPC project from Rubyforge because it is not fun to work with their fucked up API. Github is much nicer (just update a gemspec and wait for 10 minutes). Add github to your gem sources list (if you haven’t done it already):

$ gem sources -a http://gems.github.com

Remember, that github names gems in form of “username-projectname”, not just a “projectname” as rubyforge does. To install EMRPC:

$ sudo gem install oleganza-emrpc

See also: the list of all gems on github, gems.github.com.

I’m a software developer from St. Petersburg (Russia) currently living in Paris, France.

I work at Pierlis, private software company making websites and apps for Mac, iPhone and iPad.

Contacts

E-mail and jabber/gtalk: oleganza@gmail.com
Skype: olegandreev1986
Twitter: oleganza

Code

— github.com/oleganza
— pastie.org/search/?q=oleganza

936177597035857922347087286803058422491748052844532982535792