ILoggable

A place to keep my thoughts on programming

July 6, 2010 .net, geek, Promise , , , ,

I made this half-pony half-monkey monster to please you

I made this half-pony half-monkey monster to please you
But I get the feeling that you don’t like it
What’s with all the screaming?
You like monkeys, you like ponies
Maybe you don’t like monsters so much
Maybe I used too many monkeys
Isn’t it enough to know that I ruined a pony making a gift for you?

Jonathan Coulton – Skullcrusher Mountain

I'm primarily a C# developer these days, but tinker in various other languages to see what others are doing better or worse. I am clearly biased towards static languages, despite lots of features I do like in various dynamic languages. This isn't some fear of the unknown, it's preference from extensive experience — before switching to C# by way of Java, I was a perl developer for about 8 years. But I'm not trying to start yet another static vs. dynamic flame war here.

Playing with lots of languages got me thinking about what i'd ideally like to see in a programming language. So over the next couple of posts are going to be largely a thought experiment in designing that language. I do this not because i think there aren't enough languages, but to gain getter insights into how I work, how language design works and what goes into good usability design.

The conclusion of these posts may be that I find a language that already offers what I am looking for or that I start prototyping the new language in the DLR, since that's another skill i want to expand on.

Promise

The primary feature of this language, which I'm calling Promise for now, is that it's a dynamic language with a duck-typing system to allow declaration of contracts both for discoverability and compile time (AOT or JIT) verification, but without forcing strict class inheritance hierarchies on the programmer. Its mantra is "I promise that you will get an instance that does what you expect it to do".

Below are the top-level features I find desirable:

Optional Type Annotation

Some things can be completely dynamic, but I find it a lot more useful if a method can express the type of instance it expects, rather than having that information out-of-band in the documentation. As I said, I want it to be pure duck-typing: Classes aren't types and Types aren't classes, a class can be cast to a type if it satisfies the contract. This attaching the Types at the consumption rather than the declaration side I've previously written about and it's one thing i really like about Go. I want types to aid in discovery and debugging, not be the yoke it can become in purely statically typed languages

Runs in a virtual machine

I like virtual machines that can host many languages. It allows you to write in your favorite language but still take advantage of features and libraries written in other languages without complicated and platform specific interop stories. It took a while for this promise to come to fruit but both the JVM and CLR are turning into pretty cool polyglot ecosystems. So the language must run in one of those two environments (pending the emergence of another VM that has as much adoption).

Just-in-Time compilation

While I am a big fan of compiling and deploying bytecode, for rapid development and experimentation, I really want the language to be able to run either as bytecode or as loose files that are compiled just in time.

Object-Orientation

I will continue to structure logical units as work as classes with state and methods and pass around complex data in some kind of entity for a fair amount of the work I do. So organizing code in classes that are instantiated is a fundamental building block I rely oh.

Lambdas

But just as much as object-orientation is useful for organization of responsibilities, defining anonymous functions with closures for callbacks, continuations, etc. are another essential to way I code and a fundamental building block for asynchronous programming.

Mix-ins

While C# 3.5 extension methods are a decent way of extending existing classes and attaching functionality to interfaces, I would prefer the mix-in style of attaching functionality to a class or instance without going down the multiple inheritance path.

Language level Inversion of Control

Having to know how to construct dependency hierarchies by hand or knowing about and managing the lifetime scopes of instances is, imho, an imperative programming concept that just needlessly complicates things. I just want to get an instance that I can work with and not have to deal with a myriad of constructors or have to know how to initialize a fresh instance otherwise. Nor do I want to deal with knowing when to get my own instance vs. a shared one. All that is plumbing that is common and fundamental enough that it should move into the language itself, rather than having to build an IoC framework that takes over constructors for you, or using Service Location to self-initialize.

With the 10k foot overview out of the way…

From these qualities, I have started to define the syntax for Promise and next time I'll go into some detailed specifications and start working through various syntax examples.

If you want to skip ahead and see my brainstorm notes, they can be found here.

If you think there already is a language that satisfies most if not even all my requirements, I'd love to hear about it as well.

More about Promise

This is a post in an ongoing series of posts about designing a language. It may stay theoretical, it may become a prototype in implementation or it might become a full language. You can get a list of all posts about Promise, via the Promise category link at the top.

4 to “I made this half-pony half-monkey monster to please you”

Trackbacks/Pingbacks

  1. […] data without sharing data state I'm taking a break from Promise for a post or two to jot down some stuff that I've been thinking about while discussing future […]

  2. […] Promise IoC in C# Another diversion before getting back to actual Promise language syntax description, this time trying to reproduce the Promise IoC syntax in C#. Using […]

  1. Leon Breedt says...

    I really like the null behaviour. In a dynamic language you typically don’t care as much which thing was null, and coalescing down to null if anything in an expression is null, could lend itself to some really nice constructs.

    Optional type annotation is also useful. I find when defining “API” in a dynamic language I sometimes want to be able to add some constraints, but, internally, most of the times I don’t. Having the option would be great.

    And being able to cast to a “type” if the target matches the contract specified by the “type”, regardless of inheritance, is something I’ve wanted, so many times. If the target implements the methods I care about, and its arguments are compatible, it should just be pluggable wherever I expect “type”. Without requiring a target code change.

    Look forward to seeing progress.

  2. arne says...

    The standard null behavior is so tedious, because it means that calling a graph chain like foo.Bar.Baz.Ping() is always a risk, since you should null check each piece of the chain.

    And the whole adding Dynamic to C# but not being able to cast them to an interface just seems like such an obivous oversight. At least that once you can get around with something like Duckpond.

  3. Sharing data without sharing data state says...

    […] data without sharing data state I'm taking a break from Promise for a post or two to jot down some stuff that I've been thinking about while discussing future […]

  4. Reproducing Promise IoC in C# says...

    […] Promise IoC in C# Another diversion before getting back to actual Promise language syntax description, this time trying to reproduce the Promise IoC syntax in C#. Using […]

Leave a comment