Re: What does "lacks a prefix" mean?

[Robert Thorpe]

I won't talk about this much more because I think it's getting off-topic
for this list.

Emanuel Berg <embe8573@student.uu.se> writes:
> This is the exact same tiresome argument that has been
> put forward several times by now and the argument is
> still only logical within the framework that is "this
> is the way people do it". Yes: I know!

I think that new languages should be written to do this the same way.  I
think the convention for let and let* used in lisp is useful and I wish
it were more widespread.  I'm not advocating it just because it's used
in old code.  My comments about refactoring were separate.

> In the other framework, where it is natural and
> *desired* that things depend on each other and happen
> stepwise - nothing to be afraid of and nothing that
> must be marked specifically as it is the natural order
> of things - in that framework it doesn't make
> sense (surprise, surprise!).

Certainly there is no point in avoiding dependencies.  They always occur
in programming.  But, there's no need to make it look as through there
are dependencies where there aren't.  There's no point removing tools
that allow use to differentiate one situation from the other easily.
That's the problem with the approach you're advocating.

As I said earlier, let's suppose you're reading through function foo
looking for what happens to variable bar.

Suppose you have:-
(let (.....
      (foo (code ...)))
  body)

In this case there's no need to read through any of the other variables
defined in the let.

Suppose instead you have:
(let* (.....
       (foo (code ...)))
  body)

In that case the part I've labeled "code ..." could depend on the other
local variables.  In the "let" case it's often possible to eval the
"code ..." part with C-x C-e.  That's often not possible in the let*
case.  In the let* case you have to read through the rest of the local
variable definitions.

In elisp we have the following meanings:
* let - there aren't dependencies between these variables.
* let* - there are dependencies between these variables.

In other languages that only support something like let* it means "there
may be dependencies between these variables, you have to read all the
code".

>> It's easy to be critical of the process of
>> restructuring or refactoring code. It's inevitable
>> in large codebases though.
>
> OK, so how many lines of zsh, C, C++ and Lisp do you
> have to write before it gets inevitable to "refactor"
> it? I ask because I did my biggest projects in those
> languages but apparently they weren't big enough
> because I never did any "refactoring", whatever that
> is, if it isn't the very normal and everyday thing
> that is writing, improving, and fixing bugs in code,
> in what case I have done it every day for many years!

Of course, refactoring is often exactly what you say.  It's improving
code.  Some people define it more rigourously.  For example, making
local improvements to code without changing the overall design is called
"refactoring".  Changing the overall design is called "rearchitecting".

Remember the original reason we discussed this though.  You wrote this:
> Why the (?)? Mucking around with old code is necessary every time you
> want to add a feature or debug a failure.

Now, you're advocating "mucking around with old code".  Well, that
inevitably requires reading it and understanding it.  New features must
always be inserted somewhere.

The original designers of a program can never envisage all of the ways
that it might be extended.  Look at Emacs, it's existed for decades and
for all that time it's maintainers have tried to expand
configurability.  Yet, every few weeks somebody comes up with a
practical case were a default behaviour can't be changed.

>> The cost and time of rewriting them is simply too
>> large. Even if the original is badly written it
>> generally contains undocumented features that people
>> rely on. If a large program is well written that
>> doesn't mean it won't need modifications regularly.
>
> So, everything is so bad, we have to have let/let* -
> it is inevitable!

Of course I don't think there's any particular threshold in terms of
lines-of-code of the type you describe.  What more important is the
overall effort of rewriting vs fixing.

For example, is the existing program merely messy?  If so then it's
often better to tidy it up than re-write it even if it's small.  If the
program has a few modules that are badly written then those can be
replaced.  Is the original full of undocumented features everyone relies
on?  If so then re-writing it can be very tricky.  Programs that are
badly designed are a difficult case.  If they're badly designed but the
design is well executed (i.e. the code is generally well written) then
it can be best to keep them around.  If a program is really bad
(i.e. buggy, badly written and difficult to modify) then it may be worth
replacing it even if it's millions of lines long.

Redesigning is one of the most useful and interesting programming skills
to develop.  It's about knowing how to re-use what you have to build a
more general program without throwing too much away.

BR,
Robert Thorpe