blog/content/books/things-i-learnt/languages-are-more/index.md

+++ title = "Things I Learnt The Hard Way - A Language Is Much More Than A Language" date = 2019-06-24

[taxonomies] tags = ["en-au", "books", "things i learnt", "languages", "community", "ecosystem"] +++

Picking a programming language is much more than just picking the words that will generate a code. They come with a community, a leadership, an ecosystem and a thread the binds them all together.

Programming languages, in essence, are simply a bunch of keywords that make things "go". But besides those keywords, they also bring their community, the way the leaders deal with the community, the tools created by the leaders or community to deal with the minutiae of creating a system, the way those tools interact with each other, and a lot more.

While a language may have a simple syntax, it may be that the ones controlling the language actually don't give two shits -- if you pardon my French -- to the community. They focus on solving their problems, not the community problems¹.

Or maybe the community has duplicate tools -- which is not a problem -- but that developers of each tool don't talk to each other. Or worse: They simply refuse to look what other tools are doing, which could be used to improve their own².

And maybe that third language is not as simple as others, but the leadership is always discussing things with the community, being transparent on their decision, allowing the community to discuss the future of the language and even different groups building tools decided to merge efforts to give the community better tools.

That's why you can't "pick" a language by its syntax alone. That's only the surface of what the whole of a language encapsulates and if you ignore the other elements in it, you may find yourself with a cute language in a community that is always fighting and never going forward.

And picking a language for something above the syntax is even worse.

{{ chapters(prev_chapter_link="/books/things-i-learnt/monitoring", prev_chapter_title="Learn To Monitor", next_chapter_link="/books/things-i-learnt/outside-project", next_chapter_title="Don't Mess With Things Outside Your Project") }}

---

1. Yes, this is common, even in larger communities. And yes, I've seen the leadership ignoring requests from the community and, sometimes, just ignoring all the hard work the community did to supply the missing bits because they didn't like it. ↩︎

2. Again, I've seen this before: There was a language that didn't come with a build tool bundled. The community created a tool, which was widely adopted. Later, a new build tool appeared and, in one of the notes, the author of the new tool mentioned a feature. The community came and asked "The previous build tool did something like that, what's the difference between that and your tool?" And the answer was "I never used the first tool." So, basically, the community ignored whatever the community was using. ↩︎