Decedural Rules the Roost: Declarative Front with the Power of the Procedural

17 Nov

Had an interesting online chat tonight about Domain Specific Languages
and an article I recently tweeted about: “Language designers in general: You are IN THE
WAY. ” . Good wake-up call rant. /thx @bradneuberg

The article in question
bristles at the lack of ease at creating a new application, the kind
of real-world application we want to build these days.

*REAL WORLD*, modern datatypes, built-in, literal, batteries-included
PLEASE!!! If the following aren’t first-class types with first-class
literal constructors / representations supported *at the language
level* then your new programming language ISN’T EVEN ON THE PLAYING

– symbols AS SUCH
– numbers AS A SINGLE TYPE
– a single, universal aggregate type (cf. Lua tables, more or
less; Rebol blocks)
– e-mail addresses, file / directory paths, and general URI types
– date and time constructions with simple operator arithmetic
– generic markup constructs (cf. Meijer “Unifying Documents [etc.]”)
– domain names and IP addresses
– regexes and structural regular expressions
– generalized patterns for pattern-based dispatch
– quantities — numbers with attached dimensionality
– booleans and *potentially tri-state logic support*
– ranges and slices
– some controlled ability to do open classes
– concurrency constructs AS SUCH

Furthermore, he points out that things like social networking concepts
should be native at some level, e.g. in the core library. I agree

This is about language flexibility, and the old adage that every
language is destined to become more and more like LISP, which in
mythical theory lets you express anything in any way (but in practice,

If I was designing a new language, I’d practice the agile practice of
requirements-driven design, and let requirements as in this article
drive language features.

I’d look at what sort of apps I want people to write, then I’d think
about how I’d write a framework to support those apps, then I’d write
the language. And I wouldn’t just come out with the language, but I’d
evolve the whole stack: language, a couple of key frameworks, and a
few apps built with each of those frameworks. Requirements-driven
design in this context is more than just hand-waving about what kind
of code people should be writing; it means actually providing those
end-programmer applications. Just like the way Rails was evolved with
37Signals’ apps, not as a theoretical soup of nice ideas.

And in making such a language, I’d take inspiration from the kinds of
domain-specific languages Ruby (and other languages like possibly
Perl) makes possible. What Martin Fowler calls Internal DSLs
( These are
“Decedural” – they give you the appearance of a declaration of
business logic, which is great for non-techies to verify and indeed
improve the logic – while still retaining the full power of a
first-class programming language. Nice. You can only do that in a
language like Ruby, which does nice things like making parentheses in
function arguments optional.

There’s plenty of room for improvement IMO. Ruby still has odd ways of
enforcing “something; … ; end” if you want a one-liner in some cases
(e.g. an “if” statement). And the whole meta-programming and
eigenclass concept is much more confusing than it needs to be. Simple
things like adding methods to a class are not as simple as they are in
Java or Javascript. There are probably languages that do all this and
more, but they’re not mainstream, and I hope they do become so.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: