Re: PostLisp, a language experiment
From: billy (wtanksleyjr_at_gmail.com)
Date: 03/20/05
- Next message: Brad Anderson: "Re: New to Lisp"
- Previous message: Ray Dillinger: "Re: automating ffi? what would it take?...."
- In reply to: Albert van der Horst: "Re: PostLisp, a language experiment"
- Next in thread: Albert van der Horst: "Re: PostLisp, a language experiment"
- Reply: Albert van der Horst: "Re: PostLisp, a language experiment"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 20 Mar 2005 11:05:11 -0800
Albert van der Horst wrote:
> billy <wtanksleyjr@gmail.com> wrote:
> >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.
You can argue that for some definition of "essentially the same
program". I would hope your arguments would never have any practical
effect, though; if they did, people would be using assembler where C
was appropriate or vice versa. The languages are different and have
different effects on programs written in them.
> >> 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.
No, I am absolutely not arguing that. In fact, I didn't use the word
"hay" or "wagon", and I wouldn't because I think it's a useless
analogy; each shovel of hay is roughly the same as every other shovel,
while each line of code depends critically on many of the lines before
and after it.
I'm using the word "complexity" in the well-defined sense that
information theory uses it. A C statement generates 5 lines of
assembler code; but not every 5 lines of assembler code can be
converted into a single C statement. This reveals that the
informational content of 5 lines of assembler is greater than the
informational content of 1 line of C.
> 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.
*If* this were the only difference, nobody would ever use assembly,
just as nobody pitches less hay than they can repeatably lift. It would
be a complete waste of time.
The reason that assembly is sometimes used is that assembly has more
actual complexity than C. Actually, this is also why people tend to
avoid using assembly unless it's needed. It's not just because it's
cumbersome (although it is); it's also because there are so many more
possible mistakes to make.
> >> 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.
I don't argue this, and I don't understand why you're saying that I do.
I do notice that you keep putting absurd words in my mouth, though; you
just got through telling me that I was arguing about haystacking, a
topic of which I have only the most indirect knowledge and which I'm
almost certain I made no allusion to. Now you're telling me that I was
arguing about function points.
Please stop telling me that I'm arguing about something I never
mentioned.
> >> 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.
It's clear that you don't know what I meant when I wrote "stupid
factoring". I apologise for not defining my terms.
> 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 agree.
> I would be interested in a real or made up example of stupid
> factoring.
In general, factoring is 'stupid' if the program's code is forced to
say the same thing several different times when once would have been
sufficient, or if it has to compute the same result multiple times when
once would have been sufficient.
The result of "stupid factoring" is very big or very slow code, or
both.
Stupid factoring can build a 10,000 line program out of 10-line modules
(contrary to your statement that a 10,000 line program could never be
built from 10-line modules).
> Groetjes Albert
-Billy
- Next message: Brad Anderson: "Re: New to Lisp"
- Previous message: Ray Dillinger: "Re: automating ffi? what would it take?...."
- In reply to: Albert van der Horst: "Re: PostLisp, a language experiment"
- Next in thread: Albert van der Horst: "Re: PostLisp, a language experiment"
- Reply: Albert van der Horst: "Re: PostLisp, a language experiment"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|