Thread Subject: WTF good are editor cells?

The editor keeps bugging me about "Cell mode" so I looked at the
documentation and the video. Great, it is something that makes
software engineers vomit. A tool to "help" people to write godawful
specialized long M-files with polluted namespaces when they could
write short reusable functions instead.

But sometimes you have some particular data you need to analyze in a
particular way as a one-off, so when I had such a need, I gave it a
try.

I created an M-file and made a cell with a double %% and put some
commands in it to load some data from a file. Then I executed the
cell. No errors were reported, so far so good, so I went on to write
the next step of the analysis in another cell. That step was supposed
to plot something in a figure, but it told me that variables were not
defined. The same variables that I HAD just defined in the previous
cell!

So I ran the previous cell AGAIN. Again, no errors reported. But the
variables did not show up in my workspace! WTF. Instead of Cmd+Enter,
I copied the contents of the cell manually and pasted them into the
command window. This time it reported a syntax error.

Um. So it is a feature of cell mode that when a you execute a cell
with a syntax problem they entire cell is silently disregarded and no
indication is made to the user?

dsfargeg WHAT!?

Okay, so then after correcting that problem I went to the second cell
where I had written about ten lines. No syntax errors, so when I ran
it it actually produced some output... an error message, which was
unsurprising. Um, except there was absolutely no indication of which
of the ten lines generated the error.

If I were executing a script file from the command line, the line
number would be front and center in the error message. Here, no such
indication. How does it help "rapid code iteration" to purposefully
conceal from the user exactly the information they need in order to
fix their code, I wonder? Now I have to manually execute each line to
find out the problem. Time saved by Cell mode so far: a negative
number.

Two strikes so far, but I'm stubborn, so I went on to the next cell.
This step of the analysis called for a for-loop. I wrote the cell,
executed it, and came upon an error message inside the for loop (which
I could only tell was inside the loop because the message was returned
by a builtin function that was only called inside the loop -- not as
though the error message contained any information about which line
the execution stopped or anything.)

So I have an error that happens at some iteration of a loop. The
typical diagnostic here when debugging an M-file would be to set
'dbstop if error' and inspect the workspace to see what about the data
is causing the error. I do this and re-run the cell.

The error message is produced; the debugger does not stop. Um, but I
told it to 'dbstop if error.' Never mind, I will set the breakpoint
manually by clicking in the left margin of the editor and hope that
the error manifests on the first dozen or so times it stops. I click,
it produces a red dot indicating the breakpoint; I execute the cell;
the debugger never stops.

Wonderful. It is a feature of this "rapid development" tool that you
CAN'T USE THE DEBUGGER FGSFDS FAIL.

In summary, we have a new feature of a development environment that in
the name of "rapid code iteration", swallows errors silently (which
prevents you from rapidly iterating your code), fails to report useful
information about the errors it does let through (which prevents you
from rapidly iterating your code,) and prevents you from using
debugging tools (which in turn prevents you from rapidly iterating
your code.)

F------, would not use again.

Peter,
I'm going to go out on a limb and say you haven't found your
"inner peace." Green Tea might help.

Now, I've used the "cell mode" many times and found it has
been pretty useful. I don't remember watching a video, but
there are some pretty useful help pages written for it. I
also don't believe anyone at Mathworks has ever suggested
utilizing long Mfiles. I utilize the cells to document
every 4 or 5 lines of code if possible. Or to explain my
custom-written functions.

I can't imagine how your errors are popping up. As far as I
understand it, the cell-function is just a "pretty
function." It cleans up your m-file and that's it. It's
kinda like claiming your comments are messing your results up.



Peter Meilstrup <peter.meilstrup@gmail.com> wrote in message
<75c78475-9345-4fc5-933e-12a73465e8ad@s19g2000prg.googlegroups.com>...
> The editor keeps bugging me about "Cell mode" so I looked
at the
> documentation and the video. Great, it is something that makes
> software engineers vomit. A tool to "help" people to write
godawful
> specialized long M-files with polluted namespaces when
they could
> write short reusable functions instead.
>
> But sometimes you have some particular data you need to
analyze in a
> particular way as a one-off, so when I had such a need, I
gave it a
> try.
>
> I created an M-file and made a cell with a double %% and
put some
> commands in it to load some data from a file. Then I
executed the
> cell. No errors were reported, so far so good, so I went
on to write
> the next step of the analysis in another cell. That step
was supposed
> to plot something in a figure, but it told me that
variables were not
> defined. The same variables that I HAD just defined in the
previous
> cell!
>
> So I ran the previous cell AGAIN. Again, no errors
reported. But the
> variables did not show up in my workspace! WTF. Instead of
Cmd+Enter,
> I copied the contents of the cell manually and pasted
them into the
> command window. This time it reported a syntax error.
>
> Um. So it is a feature of cell mode that when a you
execute a cell
> with a syntax problem they entire cell is silently
disregarded and no
> indication is made to the user?
>
> dsfargeg WHAT!?
>
> Okay, so then after correcting that problem I went to the
second cell
> where I had written about ten lines. No syntax errors, so
when I ran
> it it actually produced some output... an error message,
which was
> unsurprising. Um, except there was absolutely no
indication of which
> of the ten lines generated the error.
>
> If I were executing a script file from the command line,
the line
> number would be front and center in the error message.
Here, no such
> indication. How does it help "rapid code iteration" to
purposefully
> conceal from the user exactly the information they need in
order to
> fix their code, I wonder? Now I have to manually execute
each line to
> find out the problem. Time saved by Cell mode so far: a
negative
> number.
>
> Two strikes so far, but I'm stubborn, so I went on to the
next cell.
> This step of the analysis called for a for-loop. I wrote
the cell,
> executed it, and came upon an error message inside the for
loop (which
> I could only tell was inside the loop because the message
was returned
> by a builtin function that was only called inside the loop
-- not as
> though the error message contained any information about
which line
> the execution stopped or anything.)
>
> So I have an error that happens at some iteration of a
loop. The
> typical diagnostic here when debugging an M-file would be
to set
> 'dbstop if error' and inspect the workspace to see what
about the data
> is causing the error. I do this and re-run the cell.
>
> The error message is produced; the debugger does not stop.
Um, but I
> told it to 'dbstop if error.' Never mind, I will set the
breakpoint
> manually by clicking in the left margin of the editor and
hope that
> the error manifests on the first dozen or so times it
stops. I click,
> it produces a red dot indicating the breakpoint; I execute
the cell;
> the debugger never stops.
>
> Wonderful. It is a feature of this "rapid development"
tool that you
> CAN'T USE THE DEBUGGER FGSFDS FAIL.
>
> In summary, we have a new feature of a development
environment that in
> the name of "rapid code iteration", swallows errors
silently (which
> prevents you from rapidly iterating your code), fails to
report useful
> information about the errors it does let through (which
prevents you
> from rapidly iterating your code,) and prevents you from using
> debugging tools (which in turn prevents you from rapidly
iterating
> your code.)
>
> F------, would not use again.

Not showing the line number for the error can be a real
drag. I run into this myself. I don't miss breakpointing
much in the way I tend to use cells, but I can see how you'd
expect it to be there.

As far as swallowing the error, this just shouldn't happen.
 I'd appreciate it if you could send me your code and
version number. I know we had some problems in earlier
releases, but I want to be sure we've got this fixed.

Thanks,
Matthew Simoneau
The MathWorks