Question

Programming languages are not just language. Each one tends to have:

  • Its own IDEs,
  • Its own package managers,
  • Its own set of libraries,
  • Its own build tools,
  • Its own data formats.

If you are writing Java syntax, you will be using Maven packages; if you are writing Haskell syntax, you will be using Cabal packages. What's the connection? Why does each programming language create its own world?

Was it helpful?

Solution

Mostly because it has to. There really is no single, usable, method of interop between all languages. And I doubt there ever will be. The semantic differences between languages vary far too much.

Most of the differences stem from this

  • Libraries are written in the idioms of their language, which carry poorly to many others.

  • Complete build tools might include a notion of package management => libraries => per language

  • IDE's have to talk about their language's syntax, types and semantics. You can't get more language specific than that.

    Though on this point, there are quite a few tools that focus on being "platforms". Some that spring to mind: Emacs, IntelliJ, Eclipse...

The only one on this list I think would be reasonable to share would be package managers. It would be closer to apt-get than anything. The main reason this hasn't happened is just too much effort.

Trying to dislodge decades old package management systems is a hard game to play, and no one has simply done it well enough yet. Additionally it's an uphill struggle since per-language communities are much more tightly bonded than "all programmers", but again this is nontechnical.

OTHER TIPS

Why does each programming language create its own world?

They don't. You're mistaking the direction of correlation, and grouping together two different aspects.

  • Development tools (IDE's, package managers, and build tools) are best categorized by the persons who created them, and for whom they were created. Eclipse and Visual Studio are part of very different tech stacks, but the differences can be clearly identified by who does what. These tend to cluster together with language selection, since the same people have their choice of languages as well.

  • Common Code (libraries, example code, and idioms) are created within a given language, and are only useful if you can include them in the same compiler / runtime as the code of your overall language. Thus, they'd be separate and per-language no matter what.

You can definitely take advantage of the Development Tools and Common Code from one technical stack in another, but doing so is often a less than efficient choice.

  • If you take advantage of a language's turning-completeness, you can definitely write an interpreter within it for any other extant language. But doing so is going to either introduce a heck of a lot of complexity to your final program or limit yourself to the idiosyncrasies of both.

  • All OS's allow some form of communication between running programs, be it via XHR's in JavaScript or COM in the old windows world or direct "command-line" piping in the Linux world. But doing this almost always introduces overhead and runtime complexities, and costs you either RAM or execution speed.

Eclipse, IntelliJ, Visual Studio, and Emacs can all be used for at least C++, Java, and JavaScript. Maven and Ivy can be used with any language.

The .NET framework is a set of libraries that can be used with multiple languages, and there are many languages besides Java that can run on a JVM and thus use the Java core libraries.

GYP, Ant, and Make can be used with pretty much any language. GCC is structured such that you can compile any language to any platform if you install the right bits. JSON, XML, INI are all data formats widely used by many languages.

Basically, the premise of your question is flawed. A programming language is just a language, and all the things you list are separate, though some are more often used together than others.

Licensed under: CC-BY-SA with attribution
scroll top