PolyConf 2015 – A multi-disciplinary conference for polyglot programmers

The irony is that one of my Java friends told me that he could pick up any language on a need basis, and that I was ignorant for not knowing design patterns such as Factory, Visitor, Observer/Observable, etc.

But this "one" language would probably have the power to express its own EDSLs for different domains and problems (like Lisps). So in effect, maybe you could say it's many different languages in one. So why not just use many different programming languages instead of one extensible one...?

Because general purpose programming languages seem to end up feeling too monolithic when considering that they might only be used by you for that one thing. Consider two approaches: have one language that solves problems in domain A really well. Then you want to solve problems in domain B really well. But the first language is not suited for that. So you use a totally different language for that. Maybe it has its own interpreter/compiler/library and specification. Maybe you need to interoperate between these languages. What do you do? Inter-language communication seems to be in a sorry state, if the Unix philosophy of "strings anywhere" is the prevailing philosophy. I guess we're supposed to use Json now, perhaps? Corba is dead. I saw a thick old book about it where I work and didn't feel inspired.

Compare that to having a language where you can express domain B more clearly in the first language. It turns out that there was some friction and ceremony with expressing domain B in the first language, but being able to express this as as EDSL -- maybe by using something like macros -- gets you 90-100% of the benefits of using a totally new language. Additionally, there is less underlying complexity -- you have one language derived from the other using constructs from the original language. And ideally you can inspect and unfold this implementation; go through a few layers of macros, perhaps. Contrast this with having two wholly separate languages with their own runtimes, libraries and what have you.

This might be a philosophy of building layers of languages -- actually, probably more like a tree. Or maybe a DAG if you have several implementations that express the same DSL. Contrast this with several distinct implementations of monolithic languages, which probably have no knowledge of each other (languages tend to end up shallowly similar, but subtle in many many small ways; probably Turing Complete which makes analysis tricky or at least not straightforward, certainly not reliable...). But when looked at in isolation they look simple; hey this language is really good at expressing X. It doesn't have that many user-visible constructs. Simplicity! Only when you look at the bigger picture, you see how much effort and code that goes into implementing software that is subtly different, only to give the feeling of simplicity when looked at more in isolation from the whole overarching system.

Some people will look at you in horror if you suggest using a powerful and expressive language. A language that can effectively express a lot of 'languages'. They find things like operator overloading disgusting, because code should look uniform and it should be "obvious" what it is doing. Then they choose to involve 12 different programming languages on a project, because that is obviously good engineering practice. The right tool for the job! The fact that they have to learn and deal with so many languages is apparently trivial to them. The difference between the semantics and ecosystems of a dozen different programming languages is simpler then learning about and judiciously using operator overloading, I guess.

I am not trying to diminish the need for programming languages -- they seem incredibly hard to design, and the more I read about them the more I get convinced of that. There are ever more considerations that they can choose to care about, potentially at the expense of something else immediately next to it or maybe something far away. It doesn't seem like the ones who are designing them are close to converging on designs that express many of the problems that programming languages can/should care about. I look forward to seeing more language (designs) -- hopefully ambitious ones. :-)

tl:dr; I should learn a Lisp. Code truly is data, or it should be. But not even Lisp is able to do everything with sufficiently many macros, it seems.