Hi Gael, et al.: Regrettably, I couldn't attend scipy this year, but have been enjoying everyone's slides. I'm not entirely sure what the purpose of this message is, but one item in your slides was quite relevant to what I've been working on this week. In your lightning talk on the interactive shell, you wrote: "What do we gain with GUIs? -Pretty look and feel -Doesn't make you more productive/richer: no economic or academic incentive" At a gut level, I disagree that GUIs don't make you more productive. I imagine that you and others probably disagree, too. After all, we must find *some* non-superficial value in them to go to the effort of writing them! For certain datasets, I've found that I can't do the analysis I want without a good GUI for browsing and tagging data. Since this involves syncing up plots and animations across 4D, the code is non-trivial. So, the snag comes at the point of trying to justify all the time you spend writing a GUI app; you hope for future efficiency in analysis, but the benefits are pushed into the future right along with publishable results (==riches, such as it is in academia). And much of the efficiency comes by implementing the hardest features: not just plots, but draggable, zoomable, taggable, animated, linked plots. Perhaps the best way to conclude is by saying thanks to all those that are pushing forward on the graphical toolkits. The faster it is to make an app, the less conflict we'll all feel when justifying time spent crafting GUIs. -Eric
On Fri, Aug 22, 2008 at 11:15:00AM -0400, Eric Bruning wrote:
In your lightning talk on the interactive shell, you wrote: "What do we gain with GUIs? -Pretty look and feel -Doesn't make you more productive/richer: no economic or academic incentive"
I guess that was just me being provocative as usual. :). That said, I would have fully agreed with you a month ago, but I came to realize that there is a heavy cost you pay by sitting in a GUI: you now have to deal with screen refresh, event-processing, and if your calculations are sitting in the same Python process, this slows them down. So I guess my point is that to pay this price, and still have a valuable scientific tools, you need a better incentive than looking pretty, you need to be able to solve additional problems, and this come with adding additional features. Gaël
Eric Bruning wrote:
Hi Gael, et al.:
Regrettably, I couldn't attend scipy this year, but have been enjoying everyone's slides. I'm not entirely sure what the purpose of this message is, but one item in your slides was quite relevant to what I've been working on this week.
In your lightning talk on the interactive shell, you wrote: "What do we gain with GUIs? -Pretty look and feel -Doesn't make you more productive/richer: no economic or academic incentive"
At a gut level, I disagree that GUIs don't make you more productive. I imagine that you and others probably disagree, too. After all, we must find *some* non-superficial value in them to go to the effort of writing them! For certain datasets, I've found that I can't do the analysis I want without a good GUI for browsing and tagging data. Since this involves syncing up plots and animations across 4D, the code is non-trivial.
So, the snag comes at the point of trying to justify all the time you spend writing a GUI app; you hope for future efficiency in analysis, but the benefits are pushed into the future right along with publishable results (==riches, such as it is in academia). And much of the efficiency comes by implementing the hardest features: not just plots, but draggable, zoomable, taggable, animated, linked plots.
Perhaps the best way to conclude is by saying thanks to all those that are pushing forward on the graphical toolkits. The faster it is to make an app, the less conflict we'll all feel when justifying time spent crafting GUIs.
For every specialist, it doesn't matter what tool he uses, GUI or not. But for the boys and girls that once in a while need some tools, GUI is very very convenient way of not have to know / remember all the small details !! Why do you think all amateurs (and a few professionals) like LabView so much ;-) But even more important than the GUI is feeding the user with the right apriori knowledge of the tool and the domain at the right time. Just my 2 cents, I'm not an expert, but ... ... I'm trying to build a Labview equivalent in Python ;-) cheers, Stef
I think what Stef is getting at is that effective scientific software may need to match its user model to the user's world model. In other words, the "workflow" matters. If the software requires the user (scientist/engineer/etc.) to deal with data or process in a different order than the order implied by their experiment, the software is not as good as it could be. In my view, this is why we build UIs--so that we can match the software model to the user's model such that the software is "invisible" to the user in doing their work. I contend that it is a rare case when a CLI interface is the *best* fit to the user's world model. Of course, as Gael points out, writing GUIs takes time. The tradeoff then is efficiency of use for the user versus efficiency of delivery time for the developer. Barry On Fri, Aug 22, 2008 at 3:23 PM, Stef Mientki <s.mientki@ru.nl> wrote:
Eric Bruning wrote:
Hi Gael, et al.:
Regrettably, I couldn't attend scipy this year, but have been enjoying everyone's slides. I'm not entirely sure what the purpose of this message is, but one item in your slides was quite relevant to what I've been working on this week.
In your lightning talk on the interactive shell, you wrote: "What do we gain with GUIs? -Pretty look and feel -Doesn't make you more productive/richer: no economic or academic incentive"
At a gut level, I disagree that GUIs don't make you more productive. I imagine that you and others probably disagree, too. After all, we must find *some* non-superficial value in them to go to the effort of writing them! For certain datasets, I've found that I can't do the analysis I want without a good GUI for browsing and tagging data. Since this involves syncing up plots and animations across 4D, the code is non-trivial.
So, the snag comes at the point of trying to justify all the time you spend writing a GUI app; you hope for future efficiency in analysis, but the benefits are pushed into the future right along with publishable results (==riches, such as it is in academia). And much of the efficiency comes by implementing the hardest features: not just plots, but draggable, zoomable, taggable, animated, linked plots.
Perhaps the best way to conclude is by saying thanks to all those that are pushing forward on the graphical toolkits. The faster it is to make an app, the less conflict we'll all feel when justifying time spent crafting GUIs.
For every specialist, it doesn't matter what tool he uses, GUI or not. But for the boys and girls that once in a while need some tools, GUI is very very convenient way of not have to know / remember all the small details !! Why do you think all amateurs (and a few professionals) like LabView so much ;-) But even more important than the GUI is feeding the user with the right apriori knowledge of the tool and the domain at the right time.
Just my 2 cents, I'm not an expert, but ... ... I'm trying to build a Labview equivalent in Python ;-)
cheers, Stef
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-user
In your lightning talk on the interactive shell, you wrote: "What do we gain with GUIs? -Pretty look and feel -Doesn't make you more productive/richer: no economic or academic incentive"
I guess that was just me being provocative as usual. :).
I'm glad you were! (And I took no offense)
That said, I would have fully agreed with you a month ago, but I came to realize that there is a heavy cost you pay by sitting in a GUI: you now have to deal with screen refresh, event-processing, and if your calculations are sitting in the same Python process, this slows them down.
Are the problems you list specific to integrating an ipython prompt with a running GUI? I haven't encountered such concurrency issues thus far. My main struggle has been in getting the user interaction I want ... and that comes back to being able to trap the right event, reselect data in a timely and flexible way, etc. So maybe I have encountered what you describe after all.
So I guess my point is that to pay this price, and still have a valuable scientific tools, you need a better incentive than looking pretty, you need to be able to solve additional problems, and this come with adding additional features.
Agreed! -Eric
On Fri, Aug 22, 2008 at 4:12 PM, Barry Wark <barrywark@gmail.com> wrote:
I think what Stef is getting at is that effective scientific software may need to match its user model to the user's world model. In other words, the "workflow" matters. If the software requires the user (scientist/engineer/etc.) to deal with data or process in a different order than the order implied by their experiment, the software is not as good as it could be. In my view, this is why we build UIs--so that we can match the software model to the user's model such that the software is "invisible" to the user in doing their work. I contend that it is a rare case when a CLI interface is the *best* fit to the user's world model.
Workflow is defininitely the key reason why I want a GUI. Perhaps Gael's point is that building a flexibile workflow is one of the most challenging parts! I'm glad to see tools being developed that are a more natural fit for the way I think about data and interfaces.
Of course, as Gael points out, writing GUIs takes time. The tradeoff then is efficiency of use for the user versus efficiency of delivery time for the developer.
And this tradeoff is compounded when user and developer are the same - finite time and all that! -Eric
On Fri, Aug 22, 2008 at 04:12:24PM -0400, Barry Wark wrote:
I think what Stef is getting at is that effective scientific software may need to match its user model to the user's world model. In other words, the "workflow" matters. If the software requires the user (scientist/engineer/etc.) to deal with data or process in a different order than the order implied by their experiment, the software is not as good as it could be. In my view, this is why we build UIs--so that we can match the software model to the user's model such that the software is "invisible" to the user in doing their work. I contend that it is a rare case when a CLI interface is the *best* fit to the user's world model.
I agree, but I was talking about a CLI interface, not a notebook, or something else, and I guess my point was that if you go in GUIs, you should should get more than a nice-looking terminal, eg Matlab, scilab.
Of course, as Gael points out, writing GUIs takes time. The tradeoff then is efficiency of use for the user versus efficiency of delivery time for the developer.
That is not my point however. My point is that by definition when you move out of the nice, fuzzy environment of a terminal, and stick this functionality in the process in which you are running the calculation, you pay in cost in robustness and speed of your environment. Of course you can go mutliprocess, but this is not my point here, as when you do that, you loose the big gain of being able to introspect you calculation cheaply as it run. If you are going this way, I think a AJAX application is not that stupid (as sage does), as the webbrowser actually gives you a very robust, rather easy to code, and fairly powerful canvas. I am currently struggling with trying to define what is my model, what is my view, what should sit where, ie how many processes we want. I am now convinced that for a robust and powerful IDE with Python, we want several processes communicating together. For instance, I think that the editor, may it be written in Python, and not emacs or vim, or eclipse, should be sitting in a different process, so that the calculation does not block the editor, nor crashes it. I am now starting to wonder if the canvas on which we print IO could also not be in a different process (web browser?) as IO is just text, and transferring from a process to another is cheaper. However, what I am really interested in for a UI, is a view on my namespace, that I can use to dynamically explore the arrays, or the different objects. I want this view to be dynamically, and strongly interactive, and I don't think that sitting in a different process than the calculation engine will get me this. Obviously I am still trying to figure these things out and thinking out loud here, but I am trying to push people to think out of the box, and make people realize that the standard model of a GUI in which everything happens is not maybe the best for our purposes, and that people have to think about the costs and the gains. Gaël
On Aug 22, 2008, at 5:43 PM, Gael Varoquaux wrote:
On Fri, Aug 22, 2008 at 04:12:24PM -0400, Barry Wark wrote:
I think what Stef is getting at is that effective scientific software may need to match its user model to the user's world model. In other words, the "workflow" matters. If the software requires the user (scientist/engineer/etc.) to deal with data or process in a different order than the order implied by their experiment, the software is not as good as it could be. In my view, this is why we build UIs--so that we can match the software model to the user's model such that the software is "invisible" to the user in doing their work. I contend that it is a rare case when a CLI interface is the *best* fit to the user's world model.
I agree, but I was talking about a CLI interface, not a notebook, or something else, and I guess my point was that if you go in GUIs, you should should get more than a nice-looking terminal, eg Matlab, scilab.
This point cannot be stressed enough. For scientific or engineering users, one of the major workflows *is* data exploration. Although writing expressions and small procedural logic blocks is a fairly reasonable fit for some of that exploration, I think people stick to it out of habit. Some scientists like to make fun of "business" users that do crazy, complex things in Excel, but we should make sure that the python/ipython/matlab/mathematica/ prompt does not become our little Excel. :) In my mind, the purpose of integrating a command-line prompt with the GUI is to provide that familiar exploratory interface while at the same time providing nice visual interfaces for things that actually *do* have workflow to them. Furthermore, if the data and object models behind the exploratory interface are easy to turn into a more workflow-oriented interface for non-expert users, then the entire lab benefits from this sharing of expertise. It's a lofty and a difficult goal, but I think it's the right way to interface GUIs with something as creative and open-ended as scientific analysis.
I am currently struggling with trying to define what is my model, what is my view, what should sit where, ie how many processes we want. I am now convinced that for a robust and powerful IDE with Python, we want several processes communicating together. For instance, I think that the editor, may it be written in Python, and not emacs or vim, or eclipse, should be sitting in a different process, so that the calculation does not block the editor, nor crashes it.
It's not clear to me why you want "several processes communicating together". Ease of coding (i.e. avoiding nasty multithreading issues)? The GIL? It's not obvious to me why the choice of Python over, say, C++ changes the decision making process here. If I were tasked with writing a C++ IDE, my first inclination would be to avoid multi-process as much as possible... -Peter
participants (5)
-
Barry Wark -
Eric Bruning -
Gael Varoquaux -
Peter Wang -
Stef Mientki