Hacker News Reader

Comment by gdy | Hacker News Reader

"Here are the languages and DSLs that ended up in the mix: cron, Makefile, bash, sed, regex, jq query, python, R, sql, nginx conf"

And also anyone who could replace you will have to know all these languages. Nice approach to job security.

View on HN

> cron, Makefile, bash, sed

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.

Judging by the surrounding context, they were probably referring to jq[1], the delightful command line DSL for manipulating JSON, not to jQuery.

[1] https://stedolan.github.io/jq/

> 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.

You can actually build your UI with SQL, e.g PL/SQL.

I had a gut feeling you could ;) Interesting.

Check the history of Oracle Forms and APEX products.

Also sorry if I came of as rude, did not mean to!

JQ is a JSON specific query language . Not related to JavaScript.

There is a difference between “knowing a language” and knowing the frameworks, idioms, ecosystems etc.

I could learn Swift in a week but that doesn’t mean I would be a competent iOS developer.

Someone who knew Python couldn’t do anything useful with the type of automation that I do with Boto3 without knowing the intricacies of AWS.

2 general purpose languages: R and Python.

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:

AMPL

Prolog

Lua

SQL

sed/awk/grep/jq/etc

C++

Makefile DSL

cron DSL

Docker DSL

etc.

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).

True.

Still, bash and (most likely) sed could've been easily replaced with Python.

That’s good or bad dependent on the world you want to see.

In my opinion, engineers should have an ample toolbox for much the same reason that a good carpenter has a tool for any given thing.

If well tooled engineers is what you’re after then you’ll be replacing one with another; with few surprises.

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.

Reply on news.ycombinator.com