I've updated a "programming language popularity" post with new "stats"
regarding the number of Google hits for "implemented/written in
<language>".

I found it interesting that nearly half of the languages that rose in
position were Lisp related. Mostly meaningless, but may still be
mildly interesting to some:

http://lojic.com/blog/2009/10/24/programming-language-popularity-part-two/

-- 
Brian Adkins
http://lojic.com/

On Sat, 24 Oct 2009 11:46:27 -0400, Brian Adkins wrote:

> I've updated a "programming language popularity" post with new "stats"
> regarding the number of Google hits for "implemented/written in
> <language>".
> 
> I found it interesting that nearly half of the languages that rose in
> position were Lisp related. Mostly meaningless, but may still be mildly
> interesting to some:
> 
> http://lojic.com/blog/2009/10/24/programming-language-popularity-part-
two/

Language        Apr 09  Oct 09
Common Lisp 	20,600  554,500

A 27-fold increase in 7 months?  I am unwilling to believe that this
happened to Lisp (or any language for that matter).  Something else
must have happened that inflated the numbers (eg Google changed their
algorithm, you made a programming mistake, etc), and I have no prior
reason to believe that this change would affect all languages
proportionally.

Consequently, I suppose that you are "measuring" noise.
Congratulations!

Tamas

On Sat, 24 Oct 2009 11:46:27 -0400, Brian Adkins <lojicdotcom@gmail.com> said:

> I've updated a "programming language popularity" post with new "stats"
> regarding the number of Google hits for "implemented/written in
> <language>".

> I found it interesting that nearly half of the languages that rose in
> position were Lisp related.

  And then some of the languages that fell in position are also
  Lisp-related or Lisp-influenced, but either way, what does that
  really signify?

> Mostly meaningless

  Or does this answer my question?

> ...
> http://lojic.com/blog/2009/10/24/programming-language-popularity-part-two/

  Now, not with regards to the numbers, but the nomenclature, what can
  "Lisp" possibly mean in "Lisp, Scheme, Common Lisp, Arc & Clojure"?

  Other possible names in an enumeration that includes Scheme, Common
  Lisp, Arc, and Clojure, might be e.g. Elisp, Lisp 1.5, and MacLisp
  (to name just three), but what can an unqualified "Lisp" stand for
  except the whole family?

  I suppose occurrences of the phrases "written in Lisp" or
  "implemented in Lisp" must be distributed proportionally into the
  other chosen buckets (note, for example, how SICP uses "Lisp" in
  contexts where it stands for "Scheme").

  ---Vassil.


-- 
"Even when the muse is posting on Usenet, Alexander Sergeevich?"

On 24 Oct 2009 16:02:10 GMT, Tamas K Papp <tkpapp@gmail.com> said:
> ...
> Language        Apr 09  Oct 09
> Common Lisp 	20,600  554,500

> A 27-fold increase in 7 months?  I am unwilling to believe that this
> happened to Lisp (or any language for that matter).  Something else
> must have happened that inflated the numbers (eg Google changed their
> algorithm

  The total number of results reported by Google for a search has
  always been some sort of approximation whose error margin is unknown
  (at least publicly).  Note that Google does not allow listing hits
  beyound the first few hundred or thousand (I forget exactly how
  many, but I don't think it would list as far as the 10,000th result
  or further), and for specific queries where the results are
  sufficiently few and Google does allow listing to the end, results
  are usually exhausted long before the initially announced
  (approximate) total count.

  In any case, when I just did

    <http://www.google.com/search?q=%22implemented+in+Common+Lisp%22>
    <http://www.google.com/search?q=%22written+in+Common+Lisp%22>

  Google gave "about 828,000" for the former and "about 281,000" for
  the latter; sadly, there is no way to ask Google what it would have
  given six months ago...

  ---Vassil.


-- 
"Even when the muse is posting on Usenet, Alexander Sergeevich?"

Tamas K Papp <tkpapp@gmail.com> writes:

> On Sat, 24 Oct 2009 11:46:27 -0400, Brian Adkins wrote:
>
>> I've updated a "programming language popularity" post with new "stats"
>> regarding the number of Google hits for "implemented/written in
>> <language>".
>> 
>> I found it interesting that nearly half of the languages that rose in
>> position were Lisp related. Mostly meaningless, but may still be mildly
>> interesting to some:
>> 
>> http://lojic.com/blog/2009/10/24/programming-language-popularity-part-
> two/
>
> Language        Apr 09  Oct 09
> Common Lisp 	20,600  554,500
>
> A 27-fold increase in 7 months?  I am unwilling to believe that this
> happened to Lisp (or any language for that matter).  Something else
> must have happened that inflated the numbers (eg Google changed their
> algorithm, you made a programming mistake, etc), and I have no prior
> reason to believe that this change would affect all languages
> proportionally.
>
> Consequently, I suppose that you are "measuring" noise.
> [...]

Remarkably consistent "noise" then given how all languages across the
board had significant jumps. It's the relative change in position
that's less noisy. No one asserted that there was a 27-fold increase
in applications written/implemented in Lisp.

-- 
Brian Adkins
http://lojic.com/

Vassil Nikolov <vnikolov@pobox.com> writes:

> On 24 Oct 2009 16:02:10 GMT, Tamas K Papp <tkpapp@gmail.com> said:
>> ...
>> Language        Apr 09  Oct 09
>> Common Lisp 	20,600  554,500
>
>> A 27-fold increase in 7 months?  I am unwilling to believe that this
>> happened to Lisp (or any language for that matter).  Something else
>> must have happened that inflated the numbers (eg Google changed their
>> algorithm
>
>   The total number of results reported by Google for a search has
>   always been some sort of approximation whose error margin is unknown
>   (at least publicly).  Note that Google does not allow listing hits
>   beyound the first few hundred or thousand (I forget exactly how
>   many, but I don't think it would list as far as the 10,000th result
>   or further), and for specific queries where the results are
>   sufficiently few and Google does allow listing to the end, results
>   are usually exhausted long before the initially announced
>   (approximate) total count.
>
>   In any case, when I just did
>
>     <http://www.google.com/search?q=%22implemented+in+Common+Lisp%22>
>     <http://www.google.com/search?q=%22written+in+Common+Lisp%22>
>
>   Google gave "about 828,000" for the former and "about 281,000" for
>   the latter; 

That matches my numbers exactly then as the average of your two
figures is 554,500.

>   sadly, there is no way to ask Google what it would have
>   given six months ago...

Sure there is, just look at the article. The figures for 6 months ago
are listed.

-- 
Brian Adkins
http://lojic.com/

On Sat, 24 Oct 2009 14:06:54 -0400, Brian Adkins wrote:

> Tamas K Papp <tkpapp@gmail.com> writes:
> 
>> On Sat, 24 Oct 2009 11:46:27 -0400, Brian Adkins wrote:
>>
>>> I've updated a "programming language popularity" post with new "stats"
>>> regarding the number of Google hits for "implemented/written in
>>> <language>".
>>> 
>>> I found it interesting that nearly half of the languages that rose in
>>> position were Lisp related. Mostly meaningless, but may still be
>>> mildly interesting to some:
>>> 
>>> http://lojic.com/blog/2009/10/24/programming-language-popularity-part-
>> two/
>>
>> Language        Apr 09  Oct 09
>> Common Lisp 	20,600  554,500
>>
>> A 27-fold increase in 7 months?  I am unwilling to believe that this
>> happened to Lisp (or any language for that matter).  Something else
>> must have happened that inflated the numbers (eg Google changed their
>> algorithm, you made a programming mistake, etc), and I have no prior
>> reason to believe that this change would affect all languages
>> proportionally.
>>
>> Consequently, I suppose that you are "measuring" noise. [...]
> 
> Remarkably consistent "noise" then given how all languages across the
> board had significant jumps. It's the relative change in position that's

Sure, the noise had a common component, but you still don't know if
there was an idiosyncratic one (ie if the changes in the search
algorithm just made an n-fold increase with a constant n, or whether
it is variable, etc).

> less noisy. No one asserted that there was a 27-fold increase in
> applications written/implemented in Lisp.

No one asserted that you asserted that.  I just don't find the
statistics you have compiled to be of any use for judging (the changes 
in) the popularity of languages, and I just wanted to say that, in case
someone thinks that we can draw conclusions bases on Google rankings.

Also, you are using order statistics (ranking), which are not going to
be particularly informative for things in the tail (the "small"
languages), because even a small amount of noise will screw up the
rankings.  You can see this by plotting the ratio (Oct/Apr) vs the
Apr absolute value.  Observe how noise is decreasing in the Apr axis, and 
how it is very large for small values.  Even if there is any information 
in the data, most of it has been swamped out by the noise.

Tamas

On 2009-10-24, Tamas K Papp <tkpapp@gmail.com> wrote:
> Language        Apr 09  Oct 09
> Common Lisp 	20,600  554,500
>
> A 27-fold increase in 7 months?

Economy. People have time off to do what they really love. :)

> From: Brian Adkins <lojicdot...@gmail.com>

> I've updated a "programming language popularity" post ...

You know it's possible to develop computer software without
actually using or seeing or being aware of any programming
"language". This whole question you pose is probably going to seem
rather moot in a few weeks when I implement my Web service for
no-syntax software deveopment based on intentional datatypes.

> http://lojic.com/blog/2009/10/24/programming-language-popularity-part-two/

Looking there now:
   C             1,905,500 16,975,000 0
   C++           699,000   6,270,000  +1
   Java          850,000   5,118,000  -1
   PHP           680,000   5,083,500  0
So how come your report generator doesn't know how to align
columns? It's not like you're using almost 80 characaters and would
overflow your Hollerith card or VT100 terminal if you made things
use up one or two more columns by aligning them. Your longest line
(one of the column headers) is only 46 characters wide, plenty
short of the hard limit of 80.

Let me guess: You wrote your report generator in C, which is such a
painful language to use that you could just barely make it produce
crappy output and it would cost a year's work to get the output
correctly aligned?

Den Sun, 25 Oct 2009 06:31:23 -0700, skrev Robert Maas,
http://tinyurl.com/uh3t:

> 
> Let me guess: You wrote your report generator in C, which is such a
> painful language to use that you could just barely make it produce
> crappy output and it would cost a year's work to get the output
> correctly aligned?

Silly, printf would have no problem alligning the data. It is no more 
difficult to do in c than in Lisp. Have you ever programmmed C?

> > Let me guess: You wrote your report generator in C, which is such a
> > painful language to use that you could just barely make it produce
> > crappy output and it would cost a year's work to get the output
> > correctly aligned?
> From: John Thingstad <jpth...@online.no>
> Silly, printf would have no problem alligning the data.

That works *only* after the software has properly planned the
layout so that there's room for the all the aligned data within
each column, and the parameters for printf have been constructed
appropriately for that plan, so that those parameters can then be
built into the format-control string passed to printf. In Lisp,
this may involve liberal use of MAPCAR and REDUCE. For example, if
the data is in a two-level list and each cell of the array has a
record giving various properties of that cell such as 'foo' which
tells how many columns are needed to left of decimal point, with an
OO-getter function 'get-foo' for it, then something like the
following code would tell the maximum number of character-columns
needed for left-of-decimal-point data anywhere in table-column
number N:
  (setq column (mapcar #'(lambda (row) (nth N row)) rows))
  (setq leftsizes (mapcar #'get-foo column))
  (setq maxleftsize (reduce #'max leftsizes))
I've broken it into 3 lines with SETQs, instead of nesting it in
one huge s-expression, so that the names of the intermediate
variables would self-document what each expression creates.

> It is no more difficult to do in c than in Lisp.

In theory, somebody could implement nested list structure together
with MAPCAR and REDUCE in C, but hardly any ordinary C programmer
would even think of the idea much less have a clear idea how to
implement it in a non-buggy way and then go to all the trouble of
implementing it and testing it to make sure it works. Most C
programmers would try to take shortcuts that don't require
re-inventing list-processing, and pay the price of such shortcuts.

(Note that for this task, the full Lisp paradigm of a lexical
 source-code symbol being a "first-class citizen" object with a
 value and function cell, together with code=data i.e. EVAL able to
 convert a linked-list (foo arg1 arg2 ...) into code that performs
 (APPLY (symbol-function foo) (list arg1 arg2 ...)) or equivalently
 (FUNCALL (symbol-function foo) arg1 arg2 ...), is **not**
 necessary. All that's needed is a library of list-processing
 utilities, such as the Fortran list-processing library that existed
 circa 1966, plus MAPCAR and REDUCE added relatively easily on top
 of that library. But most C programmers don't know of the
 existance of such a library and wouldn't know how to make one
 themselves from scratch and wouldn't have a good idea how to
 effectively use one if they had one given to them, and most
 importantly wouldn't just naturally *think* of writing their
 application in such a way. I suggest the OP is such a conventional
 C programmer who simply doesn't conceptualize his applications in
 the list-processing way. A PHP/MySQL programmer by comparision
 would most likely know how to do the SQL/RDBS equivalent of MAPCAR
 and REDUCE, but still might not *think* of what to me is the
 obvious list-processing way of doing the task. And the extra work
 to do the task in C+LispProcessingLibrary or PHP+MySQL+RDBS,
 compared to Common Lisp, might influence such a C or PHP
 programmer to take shortcuts instead of doing it the
 auto-plan-first list-processing way.)

> Have you ever programmmed C?

Yes, and it was a royal pain to manually keep track of all
references to each heap-allocated object at all points in the
program, so that I could insert a free() call the precise point in
the source-code when usage of it would be done and the last pointer
to it was just about to be erased during runtime. Now I realize
that for most applications now, the fear of "memory leak" is
ill-founded. It's not necessary to *ever* call free() in most
applications. For most CGI applications that run just for a few
seconds before terminating, very little heap space gets allocated,
and it doesn't build up over time because like I said the program
only runs for a few seconds before terminating. And for most
Unix-style command-line utilities, likewise they are run just
briefly to produce their output before terminating. And with very
large virtual memory and good paging on modern computers, a
medium-long-running program that grow to a good fraction of a
gigabyte of unreclaimed heap garbage is not really a problem. In
fact, during the past several weeks, I ran CMU Common Lisp with
automatic garbage collection disabled, for over two days at a time
during normal software development, before it filled up half a
gigabyte and consequently aborted. I ran it for an hour or two at a
time during heavy production use of the developed code. I think I
proved that it *is* possible to simply ignore "memory leak" over
medium spans of time. It's *only* for persistent applications, such
as a login shell, where garbage reclamation really is needed to
prevent the application from *eventually* running out of memory.

I suspect the OP is a C programmer who mistakensly believes that
*every* C application must carefully avoid "memory leak", whereupon
the pain of doing list processing is too great to bear, whereupon a
shortcut half-baked algorithm was used instead, resulting in the
mis-aligned columns.

Or the OP isn't even a competant C programmer, doesn't know even
what you know about how printf *could* have aligned the columns
correctly if the programmer took the care to *manually* do the
planning of the layout in lieu of list-processing doing all the
layout-planning automatically.