Skip to main content

GUIs are evil

Well, not really. Like most things a GUI is neither good nor evil, but a shade of something in between. However, for a while, before I caught myself, I was spending large amounts of time writing GUIs for analysis. Time that would have been better spent writing analysis code and debugging it and documenting it and writing papers as a result of it. I taped a piece of paper in front of my desk that said 'NO GUIs' to remind myself.

Programming a GUIs is a time trade. Creating a GUI trades time now for time later. The catch is that the time later usually goes to an 'end user' rather than you.

When to write a GUI:
  • A GUI for MATLAB or Python is good for code that will be repeatedly used to run analysis by people who have no interest in knowing the underlying code.
  • A GUI is good for tasks that have a strong visual component: this means analysis that is done by displaying data on screen on which you have to indicate things by clicking on them.
  • Your analysis code is all finished and documented and you are regularly running analysis with it and you are getting tired of some repeated typing or repeated actions. Again, first think if you could write a glue script (in Python for example) rather than a GUI.
When to resist the devil's call:
  • The code is for exploratory analysis that may or may not yield results.
    "But I need to see stuff graphically, and I need to click on things to select regions or points", you say. Yes, MATLAB has ginput (look it up) and matplotlib has connect that can connect mouse and keyboard events to a graph. Don't make a full blown GUI that also makes coffee. That is the dark side.
  • The code has no graphical component to it (besides loading data and creating graphs).
  • Your sketch of the GUI has nothing but buttons and text boxes with parameters: replace the GUI with a nice, commented parameter file where the parameters have names. With the time saved write more documentation, take your spouse/SO/friends out or play video games.
  • You are coding the GUI before you have coded the smaller programs the GUI will eventually call. That is the dark side. Write the analysis components first, then decide if it will need a GUI package.
Also see:
Labels:

Comments

Post a Comment

Popular posts from this blog

A note on Python's __exit__() and errors

Python's context managers are a very neat way of handling code that needs a teardown once you are done. Python objects have do have a destructor method ( __del__ ) called right before the last instance of the object is about to be destroyed. You can do a teardown there. However there is a lot of fine print to the __del__ method. A cleaner way of doing tear-downs is through Python's context manager , manifested as the with keyword. class CrushMe: def __init__(self): self.f = open('test.txt', 'w') def foo(self, a, b): self.f.write(str(a - b)) def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): self.f.close() return True with CrushMe() as c: c.foo(2, 3) One thing that is important, and that got me just now, is error handling. I made the mistake of ignoring all those 'junk' arguments ( exc_type, exc_val, exc_tb ). I just skimmed the docs and what popped out is that you need to return True or
Post a Comment
Read more

Using adminer on Mac OS X

adminer is a nice php based sqlite manager. I prefer the firefox plugin "sqlite manager" but it currently has a strange issue with FF5 that basically makes it unworkable, so I was looking for an alternative to tide me over. I really don't want apache running all the time on my computer and don't want people browsing to my computer, so what I needed to do was: Download the adminer php script into /Library/WebServer/Documents/ Change /etc/apache2/httpd.conf to allow running of php scripts (uncomment the line that begins: LoadModule php5_module Start the apache server: sudo apachectl -k start Operate the script by going to localhost Stop the server: sudo apachectl -k stop  
Post a Comment
Read more