In general, a programming language determines a general idea (semantics), how input data is transformed to output data, and a syntax, the rules how the the contemplation that adheres to the general idea, is written down. APIs don't usually determine syntax, but they do determine semantics.
Leaving a long introduction to aside, the point of this blog post is to point out that in addition to the number of compulsory semicolons, commas, braces, keywords, etc. the succinctness depends heavily on the statistical profile of the code. The number of characters that a construct, let's say, loop clause, function declaration keyword, call to some API subroutine or operator, etc. contributes to an application code depends on the number of times the construct is used in the application.
For example, a code that is written in Maple or Mathematica probably has considerably more calls to various symbolic calculation routines and statistics routines than software that controls industrial robots or runs a customer self service web site. This means that an inefficient, clumsy, API of more "complex" math routines does not have much of an impact on the succinctness of the code of the web application, but it has heavy impact on math intensive data analysis related code.
The conclusion is that one can not assess the succinctness support of a programming language or API without actually measuring the usage frequencies of its different parts in an "average" real life application.
Secondary conclusion is that API-s have to be updated, changed, after they have been in use for a little while and more is known about their "real life usage".
Third conclusion is that if some party comes up with some new technology, programming language, API, etc., then the aiding capability of that technology probably depends on the application domain. It's a bit like comparing antibiotics with a pain killer: taking a pain killer to treat infection might not give as good results as the antibiotics would give and vice versa.
