[wingide-users] wingide-users Digest, Vol 113, Issue 14

Christopher Fry cfry1 at MIT.EDU
Sun Sep 29 15:00:04 MDT 2013

I apologize for my "guns blazing". That was emotion coming from my frustration about
how difficult it is to debug code, how bad popular programming languages are, and how slow
improvements in software languages and development tools are esp in comparison
to hardware advancements.

Language choice has to do with many factors, not all of which have to do with the language per se.
I'm working in a (social) environment (MIT) where python is known and used. I need to build upon
pre-existing python software and have others use my code, (not just as end-users).
Python runs fast, is popular and has lots of libraries. These are all good things.
As a core language, it is poorly designed. I can tell you what's better and what Python
could have done instead, but this is a long conversation. I'll have a beer with anyone
in Kendall Sq Cambridge about this issue if you like. I'll buy the beer.

In Wingware, the stepper, inspector, shell and editor are not well integrated. 
Many debugging hours can be saved with a "reconfiguration" of those pieces.
I speak from experience, but explaining my experience is something that,
again would take a long time and is best done over a beer or two.
I know a lot of the details on how to do this (I've done it in the past for different languages).
I've offered to meet with the WingWare folks to explain this stuff in the past and the offer remains open.

There may well be reasons under the hood in Python that make this harder than I hope.
Good languages are designed to make it easy to do this kind of "introspection" and tool integration.
But I'm optimistic that, with some clever coding and work, these extensions will be
quite worth it. I'm trying to help here. I'm not giving up on Python or Wingware.

From: Jeff Vahue [jvahue at knowlogicsoftware.com]
Sent: Sunday, September 29, 2013 12:41 PM
To: Christopher Fry; 'Wingware Support'
Cc: wingide-users at wingware.com
Subject: RE: [wingide-users] wingide-users Digest, Vol 113, Issue 14

Fry - if Python is "not a great language" why are you using it - it must
provide some value to you?  Yes __str__, __repr__ can do horrible things
from the IDE point of view (if object references are circular things can get
really bad), but the user may have a valid reason why they use these
constructs.  I have a log converter that sucks in a dynamically changing set
of logs - each log is a class that has a __rep__ function so I can just call
that to "convert" the binary struct content to the human form (I could have
used my own function for this but when I started it seemed like a reasonable
idea).  I know that when I look at the log file header in the debugger is
will be huge and maybe the debugger doesn't like it.  I believe that is what
Wingware is saying - this is not Python's fault.

It is nice to see a little bit more conciliatory tone in this last email but
I feel bad for the Wingware guys having to deal with your comments and act
responsibly in their answers to you.

Sorry everyone I'm sure this is not the venue for this but I get annoyed
reading these "know it" all comments from people who don't sound like they
know it all.  Anyone that develops software knows most things are a tradeoff
(there are a million ways to skin a cat) so when discussing why you think
your ideas are better you should always begin with an attempt to understand
the other guys point of view on the problem, and not come in "guns blazing"
(which I thought "Fry's" first message did).  Just because you use their
tool does not mean they have to implement every idea you ever had about what
an IDE should be.  Maybe some of your ideas are great and you should present
them for their review, then let them decide what to do - that is until you
buy the company and become the Supreme Overlord of development.

Jeff Vahue
90 Annawon Ave.
Wrentham, MA. 02093

ADDRESSEES. It may contain privileged, confidential or proprietary
information. Any unauthorized disclosure, use, copying or distribution of
the contents of this message is strictly prohibited. If received in error,
please promptly notify the sender and delete the original and all copies
from your system.

-----Original Message-----
From: wingide-users-bounces at wingware.com
[mailto:wingide-users-bounces at wingware.com] On Behalf Of Christopher Fry
Sent: Saturday, September 28, 2013 4:00 PM
To: Wingware Support
Cc: wingide-users at wingware.com
Subject: Re: [wingide-users] wingide-users Digest, Vol 113, Issue 14

From: Wingware Support [support at wingware.com]
Sent: Friday, September 27, 2013 3:28 PM
To: Christopher Fry
Cc: wingide-users at wingware.com
Subject: Re: [wingide-users] wingide-users Digest, Vol 113, Issue 14

Christopher Fry wrote:
> This I the first time I've looked at a list of new features for Wing 5.
> It does not include what I consider to be the most important deficiencies
of Wing4.
> First, programmers spend most of their time fixing bugs.
> I see NOTHING that directly affects debugging, and the stuf that's
> there appears to be to be barely helpful at all.

It's mostly a GUI rewrite which was an absolute necessity at this point in
the life of the old GUI toolkit Wing 4 used.

Fry sez: OK that all makes sense. Sometimes you have to do "infrastructure"
improvements before doing "feature improvements".

One thing relevant to
debugging (for some people) is that I/O from commands typed in the shells is
asynchronous and thus gets to the IDE before the commands execute.

Fry sez: I don't understand the above at all, but probably not so important
that I do.

> In Eclipse, a lot of the "debugging" you have to do is debugging
> eclipse itself, ie whoops I accidentally dragged this pane over there
> and now I can't find the stepper controls and have no way to figure out
how to get them back.
> So on the face of it, letting a user drag panes around is a bad idea.
> If a feature is in Eclipse, consider it a red flag as something NOT to

Being able to drag tabs was our #1 most requested feature.  We can't ignore
that and have tried to do a reasonable job with it.

Fry sez: OK paying attention to users IS important. If this means that I can
drag certain important file tab to the left and they will stay visible there
even after I open up other files, that sounds like  a useful feature.

> So what DO we need for debugging?
> -a better inspector: its very hard to see the details of certain objects,
>   esp App Engine model classes
> -  A way to invoke the inspector on results you get from entering in an
>     in the Python Shell/
> -  way to step though some code that I've started by typing in a call to
the Python shell.

These were planned for Wing 5 and still are, but we haven't been able to
work on them for 5.0.  This is because rewriting 350K lines of GUI code is
hard and time consuming.  We had to focus on that and get it done.

Fry sez: Yep, I understand, thanks!

> - A way to have a running app in the editor and be able  to type in an
>    into some python listener and see its results WITHOUT having to set a
>    I don't want to set a break point, I want to define a bunch of classes,
>    then call them. Don't make me artificially have to set a breakpoint
>    then call some method I don't care about form my UI button click or
>    then get into debug probe and NOW I can type in my expression.
> -  AND let me INSPECT the result of that expression.

How would you determine the locals context to run within?  Or just use the
global context?  Also, how would you deal with the inevitable
threading/concurrency issues just injecting code randomly into a running
app?  I realize that's not always going to be an issue but it sure will
confuse some people.

Fry sez: Here's how it works in a good environment.
The classes, methods and globals are all defined in the env that I'm wanting
to execute in, but nothing else.  I'll tell you what I sometimes do to solve
this problem.
I put at the bottom of my file some dummy code like foo() then set a
breakpoint at that line.
Then I execute the program with the green button.
Or I find some way to "break" the program by clicking on something in the
This is a pain.
Here's how it works in the Water idea: You don't have a difference between
"shell" and "debug probe". You just have one environment. You select
expressions in your text editor and eval them. One of the expressions you
can select is "load_file(...) or a whole bunch of files that "load your
whole program.
Now your "listener" has all this stuff loaded in, as does your inspector.
And you just eval more stuff. Say you edit a method. Well to see its effect
just eval the method def and its "in" the env so any calls to it get the new
Often at the bottom of a file I'd have a bunch of comments that would be
calls that I do for testing. Loading the file would NOT eval the comments,
but after its loaded, I could go in and select a commented fn call and call
NOW very occasionally the env would get screwed up. Say for instance I'd
rename a method, now both the old def and new def would be defined.
Mostly this wouldn't matter but if I had an old call around, it would still
work when it ought to error. The worst I could do is just reboot the IDE.
So my env was "dirtier" than your's. But in practice it is SOOO much more
convenient that its way worth it.
I understand Python might have some restrictions here. Its not a great
But you might be able  to find some ways to get this more dynamic behavior
and make development MUCH easier.
If you are not familiar with such IDEs (none are popular now) I can
appreciate why you'd be skeptical. Its a different developer mindset.

> I consider the above more important than anything I see in your list of
> I told you all this a year ago and you said wait for version 5.
> Nothing in your list compels me to try version 5.
> I'm sure there's good stuff in there. You are smart people who do good
> But do you actually use Wingware to debug? If so, why haven't you
> observed the problems that I've articulated above?

Yes, we debug Wing with itself every day, all day long.  Almost
everything I do, including writing new code, is in the debugger. I work
almost exclusively in the Debug Probe, which I find a lot easier and
faster to use than the graphical inspectors.  I do use the Watch tool
fairly often, however.   I would also like recursive debugging from the
shells, but to say Wing's debugger is useless without this seems a bit
odd.  (Not sure that's what you're saying, but it sounds like it)

Fry sez: I never said wingware debugger is useless. As far as I know, its
best of the Python environments and probably better than any Ruby env too.
Its just that I envision it being significantly better and I *hope* it isn't
that hard to do.
You've got the essential pieces in place already.

BTW, data extraction for a debugger in Python is a difficult problem.
Objects can implement __str__, __repr__, __len__, property methods, etc
and they can and often do horrible things when those are called.  We
avoid it by default.

Fry sez: OK I didn't know that. Python is not a great language.

Does enabling the Debugger > Advanced > Resolve
Properties preference help with App Engine model classes?

Fry sez: Sounds promising but how do I find "debugger"? There's a "Debug"
menu with
no "Advanced" on it.

There's no expectation that every user will upgrade to 5.0.  We
understand that people are going to upgrade when we offer them a
compelling reason to do that, and the features that people care about
vary greatly from individual to individual.  If that's not until 5.1 or
6.0, that's just fine.

fry sez: No doubt I will find all sorts of improvements in v 5 and I expect
upgrade pretty soon. Its just I was getting nervous that you forgot about
debugging tools I mentioned to you a year or two ago.
Thanks for the feedback!
Fry sez: Working on IDEs is difficult but very very important. I appreciate
your great efforts!
One of the hardest things you have to do is make up for Python deficiencies.

A good lang makes writing IDEs for it easier.


Stephan Deibel
Wingware | Python IDE
Advancing Software Development

Wing IDE users list

More information about the wingide-users mailing list