Number of languages known [was Re: Python is readable] - somewhat OT

[Devin Jeanpierre]

On Thu, Mar 29, 2012 at 10:03 AM, Chris Angelico <rosuav at gmail.com> wrote:
> You can't merge all of them without making a language that's
> suboptimal at most of those tasks - probably, one that's woeful at all
> of them. I mention SQL because, even if you were to unify all
> programming languages, you'd still need other non-application
> languages to get the job done.

Not really. You can turn SQL (or something equivalent) into a subset
of your programming language, like C# does with LINQ, or like Scheme
does with macros. The Scheme approach generalizes to programming
languages in general with even some fairly alien semantics (e.g. you
can do prolog using macros and first-class continuations). In fact,
for a more difficult target, I even recently saw an implementation of
Python in Common-Lisp that uses reader macros to compile a subset of
Python to equivalent Common-Lisp code:
http://common-lisp.net/project/clpython/

On the other hand, even similar languages are really hard to run in
the same VM: imagine the hoops you'd have to jump through to get
libraries written in Python 2 and 3 to work together. For a more
concrete example, take the attempt to make elisp and guile work
together in guilemacs:
http://www.red-bean.com/guile/notes/emacs-lisp.html

But this has nothing to do with being "suboptimal at most tasks". It's
easy to make a language that can do everything C can do, and also
everything that Haskell can do. I can write an implementation of this
programming language in one line of bash[*]. The easy way is to make
those features mutually exclusive. We don't have to sacrifice anything
by including more features until we want them to work together.

With that in mind, the interesting languages to "merge" aren't things
like SQL or regular expressions -- these are so easy to make work with
programming languages, that we do it all the time already (via string
manipulation, but first-class syntax would also be easily possible).
The hard problems are when trying to merge in the semantics of
languages that only "make sense" because they have drastically
different expectations of the world. The example that comes to mind is
Haskell, which relies incredibly strongly on the lack of side effects.
How do you merge Haskell and Python?

Well, you can't. As soon as you add side-effects, you can no longer
rely on the weak equivalence of things executed eagerly versus lazily,
and the semantics of Haskell go kaput. So the only actual effort (that
I am aware of) to implement side-effects with Haskell *deliberately*
makes mutability and laziness mutually exclusive. Anything else is
impossible. The effort mentioned here is called Disciple, and the
relevant thesis is very fun reading, check it out:
http://www.cse.unsw.edu.au/~benl/papers/thesis/lippmeier-impure-world.pdf

I guess what I really want to say is that the world looks, to me, to
be more optimistic than so many people think it is. If we wanted to,
we could absolutely take the best features from a bunch of things.
This is what C++ does, this is what Scheme does, this is what D does.
They sometimes do it in different ways, they have varying tradeoffs,
but this isn't a hard problem except when it is, and the examples you
mentioned are actually the easy cases. We can merge Python and C,
while keeping roughly the power of both, it's called Cython. We can
merge Python and PHP, in that PHP adds nothing incompatible with
Python technically (it'd be a lot of work and there would be many
tears shed because it's insane) -- but Python Server Pages probably
add the feature you want. We could merge SQL and Python, arguably we
already do via e.g. SQLAlchemy's query API (etc.) or DBAPI2's string
API. These can all becomes subsets of a language that interoperate
well with the rest of the language with no problems. These are
non-issues: the reasons for not doing so are not technical, they are
political or sociological (e.g., "bloat the language", "there should
be one obvious way to do it", "PHP's mixing of business logic with
presentation logic is bad", etc.)

There _are_ times when this is technical, and there are specific areas
of this that have technical difficulties, but... that's different, and
interesting, and being actively researched, and not really impossible
either.

I don't know. This is maybe a bit too rant-y and disorganized; if so I
apologize. I've been rethinking a lot of my views on programming
languages lately. :)  I hope at least the links help make this
interesting to someone.

-- Devin

[*] A "language" is really just a set of programs that compile. If we
assume that the set of haskell and C programs are disjoint, then we
can create a new language that combines both of them, by trying the C
(or Haskell) compiler first, and then running the other if that should
fail. This is really an argument from the absurd, though. I just said
it 'cause it sounds awesome.