I think there's a bit of a threshold with language learning. When you know a handful (or just theo necessary ones for your job), there is probably a bit of tendency to be religious about your "stack". When you know a few more than you need, then you're driven to pick between them for any given thing. Then, you start picking languages you don't know and learning them to do some thing you need done, and so on.
I wrote some data automations recently for a client. Here are the languages and DSLs that ended up in the mix: cron, Makefile, bash, sed, regex, jq query, python, R, sql, nginx conf.
I think especially if you're a vertically scaling kind of gal, and you have a fondness for conciseness, parsimony and efficiency; you'll just end up attracted to many language solutions. I just think there is no better way to write less code or keep the semantics of your language more relevant to the task in hand.
For a programmer with a minimal amount of linux experience, it likely takes a week to catch up to what the codebase is doing with these.
> regex
There are good tools to destructure regex.
> python sql jq query
I consider those as "given" or "learnable good enough in a week"
> nginx conf
Don't know this.
Overall, "knowing all these languages" seems overblown in the choice of words for me. Java, Python, Prolog and Clojure? Hell yeah that would take quite a developer to replace! But the above? There is 1 proper general-purpose language in there, the rest are well-known tools with great examples online.
> There is 1 proper general-purpose language in there
That will depend on what the GP has done with SQL. Also, JQuery implies in Javascript. There are up to 3 general-purpose languages in there, one of which nearly any developer will know.
There should be plenty of people capable of taking the codebase, but it's not a trivial single language case. The upside is that good developers will be overrepresented when compared to the population that knows one of Python or Javascript.
> That will depend on what the GP has done with SQL.
I am sure they built their UI with SQL - as opposed for example simply doing some queries, or some joined procedures at best.
> Also, JQuery implies in Javascript.
With uttermost likelyhood, they did not only dynamic changes of some html-documents there, but also their backend and crypthography.
Enough with the snark... ("Language" is such a fuzzy term anyways. You could go as far as to label any interaction with a computer as one - there will always be a protocol according to which the interaction happens.)
> There should be plenty of people capable of taking the codebase, but it's not a trivial single language case. The upside is that good developers will be overrepresented when compared to the population that knows one of Python or Javascript.
I still stand by my point. As far as the cost of polyglotism is concerned, that is a one-general-purpose-language-codebase and the rest being DSLs (apparently R too). There are other codebases where there are really 2+ languages. I.e. some functional lang on top, some performance critical code hand-written in C, some logical programming language to do some constraint programming. Each of those 3 takes quite a lot experience.
Multi language solutions make sense with languages that specialise. So I'd never write in "Go and Java" for example, or "Clojure and C#" or some other pair of general purpose languages.
For me, Python usually ends up being the glue. But otherwise, I use a tonne of special purpose stuff. E.g:
Now if you multiply these hypothetical two or three weeks by the hourly rate of someone who can learn, you'll get the cost of replacing the author with another employee.
My point is that the cost could've been much smaller.
In my eyes, you neglect the opportunity cost of "using one tool for everything": You end up with a solution that is much harder to mantain, since the wheel will have been re-inventend many times over and sprinkled with bugs along the way. Given a problem of fixed complexity, at some point costs will rise when fewer tools are used.
In summary: There is a "too much" and a "too few" when it comes to the number of tools used in a project. Where in that spectrum the OP is falling, we can't possibly know without knowing more details. Maybe the cost could have been smaller, maybe they hit an optimum and costs couldn't have been reduced by fewer tools (or more tools).
From the client's perspective it must be bad because they cannot task their own employee who can program a little bit with making minor changes to your solution.
Not as uncommon as you are suggesting I would think. These particular tools and languages are often learned as a group, because they support each other.
(R is perhaps the exception, but it does actually work really well here, because it's the best tool for certain kinds of table mashing and chart creation.)
Little command line tools, sqlite and short, focused programs all tied together with a makefile is a really nice way to arrange a data processing project.
You end up with lots of intermediate output tables to look at, each of which is produced with a small step. This makes for easy testing and debugging.
I think especially if you're a vertically scaling kind of gal, and you have a fondness for conciseness, parsimony and efficiency; you'll just end up attracted to many language solutions
There's a question I really want to ask HN related to this.
In the compression challenge (how well can you compress this data), the forbidden cheat is to put all of the data inside the "compressor/decompressor" and have the data be a single bit. The way to block that is to mandate that the total size is compressionTool+data size combined so you can't just move the data around.
So is there anything like that for comparing programming languages? If something is "easy" because it's implemented in a large runtime environment you have to ship as well, that's cheating. If it's easy because the language is powerful and well designed, that's not cheating.
If you like "conciseness, parsimony, efficiency", is the entire Python stdlib and the entire R library and a SQL engine and NGINX consise just because you hid all the implementation details in them, and they let you write your "compressed data as as a single bit"?
Well, you’re not maintaining the runtime environment ... if you’d like the minimum bytes for everything then consider writing your next app in assembler :)
The purpose with multi language programming is articulating your solution the the least amount of code .
I wrote some data automations recently for a client. Here are the languages and DSLs that ended up in the mix: cron, Makefile, bash, sed, regex, jq query, python, R, sql, nginx conf.
I think especially if you're a vertically scaling kind of gal, and you have a fondness for conciseness, parsimony and efficiency; you'll just end up attracted to many language solutions. I just think there is no better way to write less code or keep the semantics of your language more relevant to the task in hand.