Programming languages: readability vs extendability / means of abstractions

Programming languages …a subject wider than the oceans.

This small post is a summerized draft discussing readability vs extendability / means of abstractions.

– mainstream languages are limited. In their features, their expressivity and their extensibility.
– special languages are useful in particular cases but limited as well since they rarely combine well with other paradigms.
– lisp/scheme are special cases since they are very extensible / stretchable thus able to privide higher level of abstractions/combinations. This is due to the fact that you program directly the abstract syntax tree in some sense, a LISP/Scheme program is data and vice-versa. The drawback is that it is not as readable as usual languages, the code can be harder to understand and the learning curve is longer.
– languages like dylan trying to bridge the gap between infix syntax for convinience and behind the scenes conversion to lispish syntax to enable powerfull means of extending the language. …But well, who knows Dylan?
– languages like xlr / xmf try to be perfectly extensible languages so that you could express everything with them. The constructs you whish with the syntax you wish. …but, this has two drawbacks however. First, two of the strengths of languages are the completeness of their libraries and secondly the size of their communities, which we both loose in this case …Despite the language would be ideal.

Python showed us that an intuitive and clear syntax is utterly important. Indeed:
– it shortens the learning curve
– it increases readability
– it increases productivity
…It is indeed a straightforward language with enough freedom so that anyone can just pick-up the basics relatively quickly.

Yet, it is not necessarily the language we dream of. If all your experience is limited to such mainstream languages, it might seem it is the ideal candidate having everything you want. If you have already played with completely other paradigms you might miss those and find python a little dry.

Python is the culmination of the OO procedural paradigms, nice, straightforward and sweet.
SQL is the defacto standart for handling data.
Haskell is the most beatiful functional language ever.
Prolog for logic.
Erlang for distributed computing.
Scheme is so minimalisticcally fantastic. It combines as lego blocks like no other language ever.
Java helps you to structure and organize things.
C/C++ have the largest codebase ever and constitute a huge amount of libraries which we often have to interface with.

One day, a girl sitting next to me asked me naively “Why can’t you use SQL statements in your C++ code?”. Obviously, because C++ does not support it. And why? Because there is no way to extend the syntax/semantics. On the same way, it is not really possible to add stack traces in exceptions, nor aspect oriented programming, nor anything else that C++ is designed for. Just make nice procedures and objects, that’s all you can do and you have to deal with it.

For instance, C# 3.5, now offers “Language Integrated Native Queries”. Basically, this means that “now” you can perform directly the SQL querries in the code, wether it is performed on persistent data stored in a database or a normal array in your program.

…However, we are still tied by the non-extensibility of languages.
Say, I want to add aspect orientation to add constructs like:

before set var from MyObect.*
print “Variable ” + getName(var) + ” : ” + getValue(var) + ” -> ” + value

…it is simply and plainly not possible in most mainstream and specific languages.

So, we have four choices:
– wait until the next mainstream language incorporate the feature
– take a lispish language which you can extend more or less to what we want
– pick an experimental/academic language that has many feature among which the one we were interested in
– make our own language

And the consequences are:
1. …you may wait forever
2. …good option. But you loose readability, a slightly longer learning curve and it may still not be as expressive/practical as you had wished.
3. …Missing libraries? Missing support?
4. …I guess you don’t assess correctly the size of the task

An idea, for a new language, would be to have “pluggable” constructs. But this is certainly not new though. If you want to use objects, just
import core.objects
If you want to use SQL just
import core.SQL
if you want to use custom constructs, just do so
import myModule.myConstructs

It is important the constructs are cross compatible though and combine well together. Moreover, it should be possible for a foreigner to add construct and extend the language as easy as possible. This often means interracting with the core of the language, it’s internal representation. We propose to do this into two steps:
– one part is to map syntax to the internal representation
– the other part is to interact with the internal representation according to the construct

The farther appart the syntax is from the internal representation, the better expressivity we gain, but the more it becomes difficult to extend the language since we abstract away.

Advertisements

2 Responses to “Programming languages: readability vs extendability / means of abstractions”

  1. Winheim Raulsh Says:

    You should look up Intentional Programming, Language-oriented Programming, and Alan Kay’s VRI work at http://www.vpri.org/pdf/steps_TR-2007-008.pdf.

    Each of these has some good ideas. Also, if you haven’t seen it yet, there’s a language called Katahdin, which looks pretty good.

  2. sidewords Says:

    Yeah, I already knew katahdin. There are also:
    XLR – xlr.sourceforge.net
    XMF – http://www.ceteva.com/xmf.html
    which are completely unrelated but both about “meta languages” and means to implement custom languages more easely. I only had an overview of these 3 and did not dig deeper into either of them yet. I would be curious though about the opinions of people having already used them for a little more than homework.

    …But for now i’ll start reading the article you gave me 😉

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


%d bloggers like this: