Python syntax in Lisp and Scheme

[Andrew Dalke]

Doug Tolton:
> Yes and I have repeatedly stated that I disagree with it.  I simply do
> not by that allowing expressiveness via high level constructs detracts
> from the effectiveness of the group.  That argument is plainly
> ridiculous, if it were true then Python would be worse than Java,
> because Python is *far* more expressive.

I disagree with your summary.  Compare:

  The argument is that expressive power for a single developer can, for
  a group of developers and especially those comprised of people with
  different skill sets and mixed expertise, reduce the overall effectiveness
  of the group.

Notice the "can".   Now your summary is:

  ...allowing expressiveness via high level constructs detracts
  from the effectiveness of the group

That implies that at least I assert that *all* high level constructs
detract from group effectiveness, when clearly I am not saying
that.


> > If this is indeed the crux, then any justification which says "my brain"
> > and "I" is suspect, because that explicitly ignores the argument.
> Apparently you can't read very well.  I simply stated that I believe our
> point of contention to be that issue, I never stated I believe that
> because it's some vague theory inside my head.

Nor can you, because I did not say that.  I said that the arguments you
use to justify your assertions could be stronger if you were to include
cases in your history and experience which show that you understand
the impacts of a language feature on both improving and detracting from
a group effort.  Since you do have that experience, bring it up.  But
since your arguments are usually along the lines of "taking tools out
of your hands", they carry less weight for this topic.

(Ambiguity clarification: "your hands" is meant as 2nd person singular
possessive and not 2nd person plural. :)

> No, what I was referring to wasn't estimation.  Rather I was referring
> to the study that found that programmers on average write the same
> number of lines of code per year regardless of the language they write
> in.

McConnell's book has the same study, with outliers for assembly
and APL.  Indeed, I mentioned this in my reply:
> > ... and that LOC has a
> > good correlation to development time, excluding extremes like APL
> > and assembly.

>  Therefore the only way to increase productivity is to write
> software in a language that uses less lines to accomplish something
> productive.  See Paul Grahams site for a discussion.

I assume you refer to "Succinctness is Power" at
  http://www.paulgraham.com/power.html

It does not make as strong a case as you state here.  It argues
that "succintness == power" but doesn't make any statement
about how much more succinct Lisp is over Python.  He doesn't
like Paul Prescod's statement, but there's nothing to say that
Python can't be both easier to read and more succinct.  (I am
not making that claim, only pointing out that that essay is pure
commentary.)

Note also that it says nothing about group productivity.
If it takes me 5% longer to write a program in language X
then language Y, but where I can more easily use code and
libraries developed by others then it might be a good choice
for me to use a slightly less succinct language.

Why don't people use APL/J/K with it's succinctness?

I also disagree with Graham's statement:
> the most accurate measure of the relative power of
> programming languages might be the percentage of
> people who know the language who will take any job
> where they get to use that language, regardless of the
> application domain.

I develop software for computational life sciences.  I would
do so in Perl, C++, Java, even Javascript because I find
the domain to be very interesting.  I would need to be very
low on money to work in, say, accounting software, even if
I had the choice of using Python.


> You are saying that Python and Perl are similarly compact?!?
> You have got to be kidding right?
> Perl is *far* more compact than Python is.  That is just ludicrous.

Yes.  In this I have a large body of expertise by which to compare
things.  Perl dominates bioinformatics sofware development, and the
equivalent Python code is quite comparable in side -- I argue that
Python is easier to understand, but it's still about the same size.

> It's always nice just to chuck some arbitrary table into the
> conversation which conveniently backs some poitn you were trying to
> make, and also conveniently can't be located for anyone to check the
> methodology.

"Can't be located"!?!?!  I gave a full reference to the secondary material,
included the full quote (with no trimming to bias the table more my way),
gave the context to describe the headings, and gave you a reference
to the primary source!  And I made every reasonable effort to find both
sources online.

Since you can't be suggesting that I tracked down and destroyed
every copy of McConnell's book and of the primary literature (to make
it truely unlocatable) then what's your real complaint?  That things exist
in the world which aren't accessible via the web?  And how is that my
fault?

> If you want some real world numbers on program length check here:
> http://www.bagley.org/~doug/shootout/

If I want some real world numbers on program length, I do it myself:
  http://pleac.sourceforge.net/
I wrote most of the Python code there

Still, since you insist, I went to the scorecard page and changed
the weights to give LOC a multipler of 1 and the others a multiplier
of 0.  This is your definition of succinctness, yes?  This table
is sorted (I think) by least LOC to most.

            SCORES
Language Implementation Score Missing
Ocaml       ocaml        584     0
Ocaml       ocamlb       584     0
Ruby        ruby         582     0
Scheme      guile        578     0
Python      python       559     0
Pike        pike         556     0
Perl        perl         556     0
Common Lisp cmucl        514     0
Scheme      bigloo       506     1
Lua         lua          492     2
Tcl         tcl          478     3
Java        java         468     0
Awk         mawk         457     6
Awk         gawk         457     6
Forth       gforth       449     2
Icon        icon         437     7
C++         g++          435     0
Lisp        rep          427     3
Haskell     ghc          413     5
Javascript  njs          396     5
Erlang      erlang       369     8
PHP         php          347     9
Emacs Lisp  xemacs       331     9
C           gcc          315     0
SML         mlton        284     0
Mercury     mercury      273     8
Bash        bash         264     14
Forth       bigforth     264     10
SML         smlnj        256     0
Eiffel      se           193     4
Scheme      stalin       131     17

So:
  - Why aren't you using Ocaml?
  - Why is Scheme at the top *and* bottom of the list?
  - Python is right up there with the Lisp/Scheme languages
  -  ... and with Perl.

Isn't that conclusion in contradiction to your statements
that 1) "Perl is *far* more compact than Python is" and 2)
the implicit one that Lisp is significantly more succinct than
Python?  (As you say, these are small projects .. but you did
point out this site so implied it had some relevance.)

> I just don't buy these numbers or the chart from Mcconell on faith.  I
> would have to see his methodolgy, and understand what his motivation in
> conducting the test was.

I invite you to dig up the original paper (which wasn't McConnell)
and enlighten us.  Until then, I am as free to agree with McConnell --
more so because his book is quite good and comprehensive with
sound arguments comparing and contrasting the different
approaches and with no strong hidden agenda that I can detect.

> It still wasn't relevant to Macros.  However, because neither of you
> understand Macros, you of course think it is relevant.

My lack of knowledge not withstanding, the question I pose to
you is, in three parts:
  - is it possible for a language feature to make a single programmer
       more expressive/powerful while hindering group projects?
  - can you list three examples of situations where that's occured?
  - can you list one example where the increased flexibility was, in
       general, a bad idea?  That is, was there a language which would
       have been better without a language feature.

Note that I did not at all make reference to macros.  Your statements
to date suggest that your answer to the first is "no."

                    Andrew
                    dalke at dalkescientific.com