On Thu, Mar 29, 2012 at 10:03 AM, Chris Angelico <ros...@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. -- http://mail.python.org/mailman/listinfo/python-list