Re: PostLisp, a language experiment

From: Albert van der Horst (albert_at_spenarnc.xs4all.nl)
Date: 03/18/05 

Date: 18 Mar 2005 09:41:57 GMT

In article <1111090963.619099.179640@l41g2000cwc.googlegroups.com>,
billy <wtanksleyjr@gmail.com> wrote:
>Albert van der Horst wrote:
>> billy <wtanksleyjr@gmail.com> wrote:
>> >Duane Rettig wrote:
>> >> Ed Beroset <beroset@mindspring.com> writes:
>
>> >> quantity of shorter definitions). Since I know a language for
>which
>> >> a longer definition _can_ be written without increasing the
>liklihood
>> >> of bugs, I can separate the concept of wanting longer definitions
>> >> from the concept of wanting buggier code. Obviously, I don't
>desire
>> >> buggier code.
>
>> >There is no such language. Increasing the size of a module increases
>> >its complexity superlinearly.
>
>> Not true. A c program and its assembler equivalent must have the
>> same complexity, or I would reject your definition of complexity.
>
>Your statement is not a denial of mine. Translating a program from one
>language to another does not "add lines" to the original program; it
>produces a new program in a new language which allegedly does the same
>thing. The number of lines is not relevant.

Okay.

>
>If you wish to measure complexity in lines of code (this is not my
>measure of choice, but you seem to want it), you have to have to match
>your units. An LOC in C is not the same as an LOC in assembler.

I don't. I argue that a c-program and its equivalent assembler program
are essentially the same program.

>
>The Lisp function we were shown is an immensely long function,
>regardless of LOC or tokens or functionality count or whatever metric
>you care to define. It manages to become barely manageable by using
>some clever tricks, but I doubt that most people would be able to
>correctly write (the first time) such a monster even with all those
>tricks; I suspect that the reason that function is used is that someone
>automatically generated it, and many people since have taken advantage
>of its regular structure to add new things into it, and again because
>of its regular structure there's little risk of "rippling changes".
>
>Contrary to the original poster's implication, a similar function in
>Forth is quite possible; like the Lisp function, such a Forth function
>would rely on indentation and spacing to make it clear where and how to
>perform insertions and changes.
>
>> The assembler equivalent is typically 5 times as long.
>
>Although your objection doesn't apply to my statement, I do find it
>curious that most people find it harder to maintain assembly programs
>than programs in higher level languages. Why, if according to your
>ideas the two have the same complexity? I would argue that in fact the
>two do NOT have the same complexity; if the assembler program is 5
>times longer, then each possible C error locus will correspond to about
>5 possible assembler error loci. I could, for example, use a "*"

This is not complexity. You are arguing that loading 5 wagons of
hay is more complex than loading one wagon.

Maybe a better analogy. Assembler programming is programming with
a small hay stick. You have to lift five times as many.
Not complexity, in any reasonable meaning of the word.
Cumbersome is a better word.

<SNIP>

>
>So no, I don't buy the statement that assembly is the same complexity
>as C; certainly not for the purposes we're discussing.

So I reject your definition. And by implication your conclusions.

>> You are in good company in not understanding the issue
>> why small modules leads to less bugs. I had Less Hatton admit
>> it in his course Safer C.
>
>I don't doubt it :-).
>
>> Small modules leads less bugs through the intermediate of
>> smaller programs.
>
>Well sure they do! A small program is a small module, though.
>
>> In the above example you could say (stylized)
>> by adding a limited number of assembler modules (each the
>> equivalent of a c-type statement) you have decreased the
>> assembler program to a one fifth c-program.
>
>Yes, I can see how that's possible. I've done it. It's a matter of
>using the additional expressive power of a lower-generation language to
>do more precisely what you need done than what a high-level language
>can express.
>
<SNIP>
>
>> Less Hatton assumes (like you do, implicitly) that the choice
>> is between a program of ten thousand-line-modules or thousand
>> ten-line-modules. It is not.
>
>I do not make this assumption. I do, however, define a program as a
>module (as is a function). A smaller module is easier to analyse than a
>larger one.

But nobody is interested in modules! We want function points.
We want a total program that does something for you.
It is up to the programmer to decide how many modules, WOC's,
LOC's or mouse clicks you use up.

What you argue here is, that you could program a function point
with an arbitrary small module. You can't be serious.

>> With ten line modules your program
>> would not reach 10.000 lines total by a far stretch.
>
>I do not make this assumption either, and I deny it. Stupid factoring
>will balloon the size of a program as much or more than too little
>factoring. The remedy is good design, not blind factoring.

Stupid factoring is something rather unheard of, at least in Forth.
I know that people like Marcel Hendrix / gforth sometimes make
"complete sets" of operators, where some may never be used probably.
This may be stupid (depending on your point of view), and adds bloat,
but it is not factoring.

I would be interested in a real or made up example of stupid
factoring.

>-Billy

Groetjes Albert 

--
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

Relevant Pages

  • Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?
    ... I generally agree with Mr. Comstock. ... most Assembler students will never actually write "production" grade Assembler code after their class. ... Second, as most people have said, reenterable coding adds complexity - more complexity than just the GETMAIN and FREEMAIN. ...
    (bit.listserv.ibm-main)
  • Re: PostLisp, a language experiment
    ... > same complexity, or I would reject your definition of complexity. ... produces a new program in a new language which allegedly does the same ... An LOC in C is not the same as an LOC in assembler. ... Stupid factoring ...
    (comp.lang.lisp)
  • Re: Compilation Was: Is DEFCONSTANT broken?
    ... compilation is to reduce code complexity, ... There's money in compilers? ...  And, by the way, assembler code is not compiled code; it ... they are just instructions which happen to be the target of the jump). ...
    (comp.lang.lisp)
  • Re: Compilation Was: Is DEFCONSTANT broken?
    ... compilation is to reduce code complexity, ... break these simplifications goes against the goal of compilation. ... And, by the way, assembler code is not compiled code; ... they are just instructions which happen to be the target of the jump). ...
    (comp.lang.lisp)
  • Re: PostLisp, a language experiment
    ... An LOC in C is not the same as an LOC in assembler. ... > hay is more complex than loading one wagon. ... >>factoring. ... > Stupid factoring is something rather unheard of, ...
    (comp.lang.lisp)