Path: news.mathworks.com!not-for-mail
From: "Joseph " <JHollmann_nospamplease@rbccorp.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: WTF good are editor cells?
Date: Wed, 12 Dec 2007 16:52:25 +0000 (UTC)
Organization: RBC Inc
Lines: 143
Message-ID: <fjp3k9$bj8$1@fred.mathworks.com>
References: <75c78475-9345-4fc5-933e-12a73465e8ad@s19g2000prg.googlegroups.com>
Reply-To: "Joseph " <JHollmann_nospamplease@rbccorp.com>
NNTP-Posting-Host: webapp-05-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1197478345 11880 172.30.248.35 (12 Dec 2007 16:52:25 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Wed, 12 Dec 2007 16:52:25 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 617899
Xref: news.mathworks.com comp.soft-sys.matlab:442187



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.