Python syntax in Lisp and Scheme

[Doug Tolton]

Andrew Dalke wrote:

> Doug Tolton:
> 
>>I believe the crux of our difference is that you don't want to give
>>expressive power because you believe it will be misused.  I on the
>>other hand want to give expressive power because I believe it could be
>>used correctly most of the time.  For the times when it's not, well
>>that's why I have debugging skills.  Sadly not eveyone uses looping
>>the way I would, but using my brain I can figure out what they are
>>doing.
> 
> 
> That point has been made over and over to you.  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.
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.
> 
> 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.

> By
> comparison, Alex's examples bring up
>   - teaching languages to others
>   - interference between his code and others' (the APL example)
>   - production development
>       "Imagine a group of, say, a dozen programmers, working together ...
>        to develop a typical application program of a few tens of thousands
> of
>        function points -- developing about 100,000 new lines of delivered
> code
>        plus about as much unit tests,  and reusing roughly the same amount"
>   - writing books for other people
With the exception of writing books for other people, I have done all of 
those things.  I have worked on fairly large development teams > 20 
people.  I have built multi-million dollar systems.  I have taught 
people programming languages, both on the job and as a University 
Course.  So don't come off with this attitude of I have no idea what I'm 
talking about.

Macro's are precisely better for large groups of people.  Any time you 
are building systems with Large groups of people, and you want to have 
re-usable code, you abstract it.  There are all kinds of ways to do 
that, Macros are just one.  I have never seen any large successful 
coding project that does not abstract things well.  If you are incapable 
of abstracting software successful and usefully then no project will be 
successful, not if it's non-trivial.
> 
> which at the very least suggests the expertise and background
> by which to evaluate the argument.  It may be that his knowledge of
> how and when to use macros is based on the statements of people he
> respects rather than personal experience, but given the discussions on
> this topic and the exhibited examples of when macros are appropriately
> used, it surely does seem that metaclasses, higher-level functions, and
> iterators can be used to implement a solution with a roughly equal amount
> of effort and clarity.  Th only real advantage to macros I've seen is the
> certainty of "compile-time" evaluation, hence better performance than
> run-time evaluation
As I said to Alex, that's because you don't understand Macros.  Relying 
on what someone else says about Macros only gets you so far.  At some 
point, if you don't want to look like a complete idiot, you might want 
to really learn them or just shut up about them.  It's very difficult to 
have a conversation with someone who really doesn't know what they are 
talking about, but is instead just spouting an opinion they picked up 
from someone else.  The discussion doesn't go anywhere at that point.

Macros are like any things else, a tool in your tool box.  If you know 
how to use them they can be used very effectively.  If you don't, you 
can probably work around the problem and solve it a different way. 
However as the toolset differential gets bigger, the person with more 
tools in their arsenal will be able to outperform the people with less 
tools.
> 
> Alex:
> 
>>>For some (handwaving-defined) "appropriate" approach to measuring
>>>"length" (and number of lines is most definitely not it), it is ONE
> 
> 
> You:
> 
>>Both from my experience and Fred Brooks it's the only actual way I've
>>seen of measuring the time it will take to write a program.
> 
> 
> You mean "estimating"; for measuring I suspect you can use a
> combination of a clock and a calendar.  (This from a guy who recently
> posted that the result of 1+1 is 4.  ;)
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.  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.
> 
> You should use McConnell as a more recent reference than Brooks.
> (I assume you are arguing from Mythical Man Month?  Or from his
> more recent writings?)  In any case,  in Rapid Development McConnell
> considers various alternatives then suggests using LOC, on the view
> that LOC is highly correlated with function points (among 3rd
> generation programming languages! see below) and that LOC has a
> good correlation to development time, excluding extremes like APL
> and assembly.  However, his main argument is that LOC is an easy
> thing to understand.
> 
> The tricky thing about using McConnell's book is the implications
> of table 31-2 in the section "Using Rapid Development Languages",
> which talks about languages other than the 3rd generation ones used
> to make his above estimate.
> 
>   Table 31-2 shows the approximate "language levels" for a wider
>   variety of languages than Table 31-1.  The "language level" is
>    intended to be a more specific replacement for the level implied
>    by the phrases "third-generation language" and "fourth-generation
>    language."  It is defined as the number of assembler statements
>    that would be needed to replace one statement in the higher-level
>    language.  ...
> 
>    The numbers ... are subject to a lot of error, but they are the best
>    numbers available at this time, and they are accurate enough to
>    support this point:  from a development poing of view, you should
>    implement your projects in the highest-level language possible.  If
>    you can implement something in C, rather than assembler, C++
>    rather than C, or Visual Basic rather than C++, you can develop
>    faster.
> 
> And here's Table 31-2
> 
>                            Statements per
> Language          Level    Function Point
> --------          -----    --------------
> Assembler          1           320
> Ada 83             4.5          70
> AWK               15            25
> C                  2.5         125
> C++                6.5          50
> Cobol (ANSI 85)    3.5          90
> dBase IV           9            35
> spreadsheets      ~50            6
> Focus               8           40
> Fortran 77          3          110
> GW Basic            3.25       100
> Lisp                5           65
> Macro assembler     1.5        215
> Modula 2            4           80
> Oracle              8           40
> Paradox             9           35
> Pascal              3.5         90
> Perl               15           25
> Quick Basic 3       5.5         60
> SAS, SPSS, etc.    10           30
> Smalltalk (80 & V) 15           20
> Sybase              8           40
> Visual Basic 3     10           30
> 
>   Source: Adapted from data in 'Programming Languages
>                                     Table' (Jones 1995a)
> 
> 
> I'll use Perl as a proxy for Python; given that that was pre-OO
> Perl I think it's reasonable that that sets a minimum level for
> Python.  Compare the Lisp and Perl numbers
> 
> Lisp                5           65
> Perl               15           25
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.
> 
> and the differences in "statements per function point" (which isn't
> quite "LOC per function point") is striking.  It suggests that
> Python is more than twice as concise as Lisp, so if LOC is
> used as the estimate for implementation time then it's a strong
> recommendation to use Python instead of Lisp because it
> will take less time to get the same thing done.  And I do believe
> Lisp had macros back in the mid-1990s.
> 
> Sadly, this is a secondary reference and I don't have a
> copy of
>   Jones, Capers, 1995a. "Software Productivity Research
>      Programming Languages Table," 7th ed. March 1995.
> and the referenced URL of www.spr.com/library/langtbl.htm
> is no longer valid and I can't find that table on their site.
> 
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.

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

Most of those programs are trivially small, and didn't use Macros. 
Macros as well as high order functions etc only come into play in 
non-trivial systems.

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.

> 
> 
>>Well that was a long winded digression into something that is
>>completely un-related to Macros.  Seems like a good argument why
>>re-binding the buildins is bad though
> 
> 
> It was a long winded digression into how LOC can be a
> wrong basis by which to judge the appropriateness of a
> language feature.
It still wasn't relevant to Macros.  However, because neither of you 
understand Macros, you of course think it is relevant.
> 
> 
>>>a plus -- and Java's use of { } for example ensures NON-uniformity
>>>on a lexical plane, since everybody has different ideas about where
>>>braces should go:-).
>>>
>>
>>Where braces should go is a trivial issues.  However if braces is an
>>issue that seriously concerns you then I can see why macros are giving
>>you a heart attack.
> 
> 
> See that smiley and the "--"?  This is a throwaway point at the end
> of the argument, and given Alex's noted verboseness, if it was a
> serious point he would have written several pages on the topic.
This is something we are very much in agreement on.
My response was just a little dig, because it does seem to be indicative 
of his attitude in general IMO.
> 
>                     Andrew
>                     dalke at dalkescientific.com
> 
> 


-- 
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")