So I'm aware of the big ammount of general-purpose scripting languages like Ruby, Python, Perl, maybe even PHP, etc. that actually claim being usable for creating desktop applications too.
I think my question can be answered clearly
Are there actually companies using a special scripting language only to create their applications?
Are there any real advantages on creating a product in a language like Python only?
I'm not talking about the viability of those languages for web-development!
Should I stick with C(++) for desktop apps?
best regards,
lamas
The company I work for uses Perl and Tk with PerlApp to build executable packages to produce or major software application.
Perl beats C and C++ for simplicity of code. You can do things in one line of Perl that take 20 lines of C.
We've used WxPerl for a few smaller projects. We'd like to move fully to WxPerl, but existing code works, so the move has a low priority until Wx can give us something we need that Tk can't.
Python is popular for building GUI apps, too. You may have heard about Chandler. That's a big Python app. There are many others as well.
Ruby is also a suitable choice.
PHP is breaking into the world of command line apps. I am not sure about the power or flexibility of its GUI toolkits.
The languages you list aren't really scripting languages, as that tends to describe languages designed to work inside of a larger framework (like javascript) that provides its interface to the world. While you can certainly write scripts in those languages, each is a proper programming language (referred to as a dynamic or interpreted language, in contrast to compiled languages like C or C++).
There are many mature gui toolkits for creating desktop apps with interpreted languages. A search for any of those languages with "gui" on SO will yield many results.
The advantage of the languages you list are rapid development and concise code.
The advantage of compiled languages is mainly speed, and deeper ties with the internals of the operating system. But for most desktop apps, the ease of development in an interpreted language outweighs any small performance gains (unless you are writing a cpu intensive app, in which case, write the cpu heavy bits in C, and then call them from the interpreted language, which can handle the gui)
Many interpreted languages offer easy escapes to C or other languages (often with a nice inline syntax).
I would encourage you to take a look at some examples on http://rosettacode.org to see the fundamental differences between how programs come together with the languages you are interested in.
Python (combined with PyQt) is a very solid combination for GUI desktop applications (note that while QT is LGPL, PyQt (the Python bindings) is dual licensed: GPL or commercial).
It offers the same (GUI library-wise) as Qt on C++ but with Python's specific strenghts. I'll list some of the more obvious ones:
rapid prototyping
extremely readable (hence maintainable) code
Should I stick with C(++) for desktop apps?
In general: no, unless you want to / need to (for a specific reason).
I would recommend you not try to look for a language that is best for GUI apps but instead look for the language that you like the most and then use that to write your app.
Ruby, Python, Perl all have GUI tool kits available to them. Most of them have access to the same often used tool kits like TK, GTK, and Wx. The look and feel of a an app will be dependent more on the GUI tool kit than on the language, and performance wise your likely to see more impact for how you write your app than language choice.
If your comfortable with C++ then you should also look at C# or Java as options. While not scripting languages they have many of the same benefits like memory management and more sane string implementations.
I have used a number of programs that were developed using scripted languages. Several embedded device vendors ship my group Windows-based configuration and debugging utilities written in TCL. Google's drawing program SketchUp has a lot of Ruby inside it (and users can create add-ons using Ruby). I have seen many Linux applications written in Python. There are many more examples out there, but often times finished applications are bundled up to the point where you can't really tell what's powering it on the inside.
Yes, there can be advantages to working with scripted languages. Some scripted languages make it easier to do specific tasks; for example, text processing is much easier (IMO) in a language like Ruby that has regular expression support and a robust String class than it is in plain old C. Generating a UI using a scripted language may make it easier to support multiple platforms, as all the platform-specific code is taken care of inside the language interpreter or pre-compiled libraries. For example, our suppliers who build TCL-based apps claim they can build the UI for an app using TCL in a fraction of the time it would take them to build it in C++ or VB, and then they can port it to Linux almost effortlessly.
On the other hand there are a few things that scripted languages typically aren't suited for, such as writing drivers or doing anything that requires low-level hardware access.
Most importantly, however, is this: modern languages have become quite powerful to the point where choice of language doesn't make as big of a difference as it used to be. Use the language you are most comfortable with. The learning curve associated with learning a new language will usually have a much larger impact on your project.
http://www.pygtk.org/applications.html
Seems like a really long list of GUI applications in Python using just one of the frameworks.
Some part of MPICH2 is written in Python. I didn't check everything, but many parts of it used for running mpi applications are written it Python. Maybe MPICH2 is not used by everyone, but for sure it is good piece of software.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is it feasible to script in a Lisp, as opposed to Ruby/Python/Perl/(insert accepted scripting language)? By this I mean do things like file processing (open a text file, count the number of words, return the nth line), string processing (reverse, split, slice, remove punctuation), prototyping/quick computations, and other things you would normally use Python, etc. for. How productive would doing such tasks in a Lisp be, as opposed to Ruby/Python/Perl/scripting language of choice?
I ask because I want to learn a Lisp but also use it to do something instead of only learning it for the sake of it. I looked around, but couldn't find much information about scripting in a Lisp. If it is feasible, what would be a good implementation?
Thank you!
Today, using LISP as if it's certain that anyone would understand what language one is talking about is absurd since it hasn't been one language since the 70's or probably some time earlier too. LISP only indicates that it's fully parenthesized Polish prefix notation just like Pascal, Ruby, Python and Perl are just variations of ALGOL.
Scheme is a standard and Common LISP is a standard. Both of those are general purpose though Common LISP is a batteries included while Scheme is a minimalistic language. They are quite different in style so comparing them would be like comparing Java with Python.
Embedded LISPS
There are lots of use of Scheme and specialized LISP dialects as embedded languages. Emacs is the most widely used editor in the unix segment and its lisp elisp is the most used lisp language because of this. Image processing applpication GIMP has a Scheme base with extensions for image processing.
Stand alone scripts
It's possible in many Common LISP implementation with the standard #!-notation to make a script work as an executable and run it as an application. Eg. I use CLISP and have scripts using #!/usr/bin/clisp -C as first line. I also use Scheme the same way and in the very fast incremental compiler ikarus you use #!/usr/bin/ikarus --r6rs-script. Clojure has all power of Java libraries and you can use your own classes from it and it also can be made an application with #!/usr/bin/env java -cp /path/to/clojure-1.2.0.jar clojure.main
more permanent application
In Common LISP you can dump an image. It will be a Common Lisp binary with your code already compiled in. Many Scheme implementations has compilation to native and Clojure can compile to java bytecode (though it's not the most common way to do it). Still I have had experience with Ikarus sometimes interpreting faster than a compiled executable from racket, chicken and gambit so I often do my programming in DrRacket and running it in ikarus in Scheme.
Try both Common LISP and Scheme as both of them are good enough for the tasks you specified in your question. There are many free books on the subject and some are worth their price as well. You may also try Racket too, which is a Scheme deviate with lots of libraries for everyday tasks, but it's not conforming to any standard.
About productivity
I imagine you are referring to how quick you can write a certain task in a Lisp dialect. I imagine it depends on how used you are to the syntax. It takes a while to get used to it after only knowing Algol dialects. It takes different approaches as well as you need to think in a more functional manner, especially for Scheme. I imagine when you are as good in Scheme as in your favorite Algol dialect it will be similar. Eg. some algol dialects are faster to prototype inn than others and that is true for Lisp dialects as well.
When I first started to poke around Lisp I used it to write shell scripts... I'm somewhat OCD about order and uniformity and I really liked Lisp languages because they have saner syntax (fewer syntax rules, no random decisions related to particular syntax elements).
If you are looking into Common Lisp, then SBCL, as installed by default on any Linux distro is available right away for CGI scripting. SBCL also has its means to process command line arguments, access pipes, processes and so on. If you aren't after portability between different Lisps, then I'd say that you are good to go. Just to give you examples of where I used this scripting: a girl in our office compiled and maintained a list of words which I had to further process in our application. This list was available as Googledoc spreadsheet. My script would download the words table and parse it into the format I needed. I had scripts that helped me with file manipulation and preprocessing before the project was compiled (the project wasn't in Lisp).
Finally, SBCL has its own means of being used with FastCGI http://kdr2.com/project/sb-fastcgi.html , but of course there are several full-blown HTTP-servers, which you could either use as is, or put behind a proxy. Hunchentoot was historically most popular one, but there are others too, like cl-http, here are some more links: http://www.cliki.net/web .
#!/usr/bin/env sbcl --script
would be the shebang comment to use.
Furthermore, I use Common Lisp for my classes, simply to do my homework, which is, I imagine, what you were after when you said "open a text file, count the number of words, return the nth line". Here's an example I used for the class on introduction to logic: https://github.com/wvxvw/coursera-logic/blob/master/formula.lisp .
Since there was a discussion on the matter, here's something else to be considered.
Typically scripting languages have twofold nature: they are written in in a low-level language, while exposing high-level API to the programmer. This can be a blessing or a curse. On one hand languages like Python, Ruby, JavaScript have highly optimised libraries for dealing with common tasks, while Common Lisp typically, similarly to C++ or Java implements everything in Lisp. Thus, for example, strings are a lot less sophisticated in CL then they are in JavaScript: in CL they are simple arrays of characters, while in JS they are a special kind of trees known as ropes.
Typically, a programmer writing in scripting language is neither required nor expected to pull out a high performance code. The language compensates for it with the base level highly optimized library code. Unfortunately, once the programmer actually wants to squeeze as much performance as possible from the scripting language, it appears that they just don't have the tools to do it, because they can't get to the bottom of the implementation.
On the other hand, dealing with the lower level of details means that the programmer will be less productive overall, and this would require more skill, because optimizing the code to get on par with the industry standard implementations requires skill.
Common Lisp generally falls under the second category, but I'd argue it to be still good for one-liners and casual programming because of the extensive library and highly developed macro system, which allows to reduce verbosity usually associated with low-level languages.
I understand that you have asked two questions:
Is it possible to run scheme scripts from a command line
How effective is that?
I can answer your first question, but not your second. It highly depends on your scheme skills and how much code you want to (re)write in scheme how feasible it is.
So I just answer your first questions :)
Have a look at this SO question: Running Scheme from the command line.
If you have installed, for example, DrRacket (which is a good IDE for many scheme dialects) as your scheme interpreter, you may use the shebang line #! /usr/bin/env mzscheme in your scheme script.
This test script (test.scm)
#!/usr/bin/env mzscheme
#lang scheme
(print (+ 40 2))
can be made executable (with chmod +x test.scm) and executed (with ./test.scm).
I'd say that Lisp/Scheme could be used to write small scripts or big application. But they are not yet ready for wide use.
The big difference between python/ruby and scheme is that python has a huge library of modules centralized in one place. Ruby is quite similar to python with ruby gems.
Scheme on the other hand might have a small library of modules scattered accross the internet. The quality of modules doesn't always compare to the popular modules in python and ruby.
One could say that they are aiming at different goal but I'd say scheme just got old and people started to forget about it and how it could be used as a tool instead of just a school subject.
About Lisp, I can't really say. But from your description, it's possible to write scripts that you'd like to write but if you need something specific it's possible that it's not there and you'll have to rewrite it yourself.
All I can say, is jump in. And become someone who gives a future to this language. Don't be scared. This language has a bright future and you'll learn a lot from it.
WRT to your tasks, what about using Emacs, which comes with an interactive Python-shell. So you have the convenience of editing alongside with running scripts.
We have an in house developed web-based admin console that uses a combination of C CGI and Perl scripts to administer our mail server stack. Of late we have been thinking of cleaning up the code (well, replacing most of it), making the implementation more secure, and improving the overall behavior.
I don't have much programming knowledge, but I use Ruby on and off (mainly for writing erb templates), and hence was thinking of using ruby/rails for developing such an app (off-duty for now, I also need to learn stuff !).
Before blindly picking up a language though, what would you folks suggest ? Please let me know if this is too vague a question, I'll try to supply more information, if needed.
Have you considered writing your applications as Webmin modules?
You get a lot of stuff for free when you do so (users and groups, tons of security features, a pretty big variety of helper functions related to config files, and tons of existing code for most aspects of a UNIX/Linux system). You also get a lot of stuff for nearly free, like action logging, packages and updates via wbm or apt or yum, an online help system, etc.
There are some cons, as well. It's an old codebase, so it has some clunky bits in the API among other places. A lot of the old modules can be a bit hard to grok if you're not an old-school Perl programmer. But, it's a well-maintained codebase, and it's been banged on by millions of users for over a dozen years. It's pretty robust. The UI isn't beautiful, but it is relatively theme-able, and if you're distributing a minimized version it becomes easier to customize the UI.
I suspect you can be up and running a lot faster than starting from scratch or using most existing frameworks that aren't targeted specifically to building systems management interfaces the way Webmin is.
Also, it's BSD licensed, so you can do whatever you want with it, including building a custom commercial app with it (hundreds of companies have done so over the years).
If you already know a bit of ruby, then there's no reason not to use that.
If you're interested specifically in learning another language, then what you're trying to do could be done in pretty much any language/framework, it's just a matter of which one you want to learn.
Without knowing much about your existing application I'd say that this effectively boils down to "which language do you like to work with?".
Python and Ruby are both mature languages with ample library infrastructure. They also boast popular, similar web application frameworks namely Django and Ruby-on-Rails respectively.
Since you are porting an existing Perl app(lets) it may be worthwhile to note that Ruby is relatively more similar to Perl. Not surprising given that Ruby was influenced "primarily by Perl, Smalltalk, Eiffel and Lisp".
django has a nice admin interface
I wanted to get the community's feedback on a language choice our team is looking to make in the near future. We are a software developer, and I work in a team of Oracle and SQL Server DBAs supporting a cross platform Java application which runs on Oracle Application Server. We have SQL Server and Oracle code bases, and support customers on Windows, Solaris and Linux servers.
Many of the tasks we do on a frequent basis are insufficiently automated, and where they are, tend to be much more automated via shell scripts, with little equivalent functionality on Windows. Unfortunately, we now have this problem of redeveloping scripts and so on, on two platforms. So, I wish for us to choose a cross platform language to script in, instead of using Bash and awkwardly translating to Cygwin or Batch files where necessary.
It would need to be:
Dynamic (so don't suggest Java or C!)
Easily available on each platform (Windows, Solaris, Linux, perhaps AIX)
Require very little in the way of setup (root access not always available!)
Be easy for shell scripters, i.e. DBAs, to adopt, who are not hardcore developers.
Be easy to understand other people's code
Friendly with SQL Server and Oracle, without messing around.
A few nice XML features wouldn't go amiss.
It would be preferable if it would run on the JVM, since this will almost always be installed on every server (certainly on all application servers) and we have many Java developers in our company, so sticking to the JVM makes sense. This isn't exclusive though, since I know Python is a very viable language here.
I have created a list of options, but there may be more: Groovy, Scala, Jython, Python, Ruby, Perl.
No one has much experience of any, except I have quite a lot of Java and Groovy experience myself. We are looking for something dynamic, easy to pick up, will work with both SQL server and Oracle effortlessly, has some XML simplifying features, and that won't be a turnoff for DBAs. Many of us are very Bash orientated - what could move us away from this addiction?
What are people's opinions on this?
thanks!
Chris
You can opt for Python. Its dynamic(interpreted) , is available on Windows/Linux/Solaris, has easy to read syntax so that your code maintenance is easy. There modules/libraries for Oracle interaction and various other database servers as well. there are also library support for XML. All 7 points are covered.
I think your best three options are Groovy, Python, and Scala. All three let you write code at a high level (compared to C/Java). Python has its own perfectly adequate DB bindings, and Groovy and Scala can use ones made for Java.
The advantages of Python are that it is widely used already, so there are tons of tools, libraries, expertise, etc. available around it. It has a particularly clean syntax, which makes working with it aesthetically pleasing. The disadvantages are that it is slow (which may not be an issue for you), untyped (so you have runtime errors instead of compile-time errors), and you can't really switch back and forth between Jython and Python, so you have to pick whether you want the large amount of Python stuff, or the huge amount of Java stuff, minus a lot of the nice Python stuff.
The advantages of Groovy are that you know it already and it interoperates well with Java libraries. Its disadvantages are also slowness and lack of static typing. (So in contrast to Python, the choice is: do you value Python's clean syntax and wide adoption more, or do you value the vast set of Java libraries more in a language made to work well in that environment?)
The advantages of Scala are that it is statically typed (i.e. if the code gets past the compiler, it has a greater chance of working), is fast (as fast as Java if you care to work hard enough), and interoperates well with Java libraries. The disadvantages are that it imposes a bit more work on you to make the static typing work (though far, far less than Java while simultaneously being more safe), and that the canonical style for Scala is a hybrid object/functional blend that feels more different than the other two (and thus requires more training to use at full effectiveness IMO). In contrast to Groovy, the question would be whether familiarity and ease of getting started is more important than speed and correctness.
Personally, I now do almost all of my work in Scala because my work requires speed and because the compiler catches those sort of errors in coding that I commonly make (so it is the only language I've used where I am not surprised when large blocks of code run correctly once I get them to compile). But I've had good experiences with Python in other contexts--interfacing with large databases seems like a good use-case.
(I'd rule out Perl as being harder to maintain with no significant benefits over e.g. Python, and I'd rule out Ruby as being not enough more powerful than Python to warrant the less-intuitive syntax and lower rate of adoption/tool availability.)
The XML thing almost calls for Scala. Now, I love Scala, but I suggest Python here.
If you want a dynamic language and there already a lot of Java developers in your company, then Groovy seems an obvious choice, as it's very easy for Java developers to pick up (also, you said you have some Groovy experience yourself).
Groovy runs on the JVM and has excellent support for working with XML. It also has provides a very straightforward syntax for working with relational databases.
It comes with a console and a shell (though I never use the shell) which make it really easy to test/run scripts or snippets of Groovy code.
Although I prefer working on the JVM, one thing that turns me off is having to spin up a JVM to run a script. If you can work in a REPL this is not such a big deal, but it really slows you down when doing edit-run-debug scripting.
Now of course Oracle has a lot of Java stuff where interaction moght be needed, but that is something only you can estimate how important it is. For plain Oracle DB work I have seen very little Java and lots fo PLSQL/SQL.
If your dba now do their work in bash, then they will very likely pickup perl in a short time as there is a nice, logical progression path.
Since ruby was designed to be an improved version of perl, it might fit in that category too. Actually python also.
Scala is statically typed like Java, albeit with much better type inference.
My recommendation would be to go the Perl route. The CPAN is its ace in the hole, you do not have to deal with the OO stuff which might turn off some DBA's (although it is there for the power users).
I've been in a similar situation, though on a small scale. The previous situation was that any automation on the SQL Server DBs was done with VBScript, which I did start out using. As I wanted something cross-platform (and less annoying than VBScript) I went with Python.
What I learnt is:
Obviously you want a language that comes with libraries to access your databases comfortably. I wasn't too concerned with abstracting the differences away (ie, I still wrote SQL queries in the relevant dialect, with parameters). However, I'd be a bit less happy with PHP, for example, which has only very vendor-specific libraries and functions for certain databases. I see it's not on your list.
THE major obstacle was authentication. If your SQL Server uses Windows domain authentication, you'll have to work to get in. Another system also had specific needs as it required RSA tokens to be supported.
For the second point, Python is quite versatile enough to work around the difficulties, but it was getting into "badly supported" territory, especially on Windows. It was easy to work around the first problem from a Windows host, and for a Unix host it is possible though not easy. If you're using SQL Server authentication, it becomes a lot easier.
From your other choices, I'd expect various ways of authenticating and DB drivers to exist for Perl, which philosophically would be easier for DBAs used to shell scripting. Ruby - no experience, but it tends to have spotty support for some of the odder authentication methods and connectors. Scala I'd expect to be a bit too much of a "programmer's programming language" -- OOO and FP? It's a very interesting language, but maybe not the one I'd chose at first. As for the rest of the Java-based options, I don't have an opinion, but do check that all the connection types you want to make are solidly supported.
I have some knowledge about Human computer interaction and some basic knowledge programming scripts (Python) that run from start to finish and automate some tasks I want to do or calculations. In the past I built interfaces in HTML with PHP behind it.
I would like my python scripts to evolve from the command line and build some applications with GUIs that would allow the user to drag files and push buttons to initiate operations and check progress graphically.
Since I write my scripts in Python I looked at some of the options (Tkinter, wxPython, PyQt) but I can't make a decision between them to invest my time learn one and not the other. My criteria:
Has a introduction for programmers for GUI (what are the differences from a script, examples of some simple interfaces)
A framework that would allow me to run my programs on the platforms I use most (Windows) but that can also run on Mac and maybe Linux, without too much modification.
Very shallow learning curve (easy to make first interfaces) but flexibility later on to customize the interface beyond what the typical OS allows (different colors, size and shapes of buttons, for example)
If not the same, similar to how you program GUI for Android and/or Nokia smartphones. I'm planning to write some programs for these platforms in the near future so I would like to carry over some of the lessons here onto those platforms, if possible.
I did find this previous question but none of the answers are satisfactory.
Does any of the frameworks fit these requirements better than the others or are they essentially similar and I would be happy with any of them?
Note: If you think I should consider other language rather than Python to achieve this, which one? I really like Python whitespace syntax and have grown used to it so I would prefer to stick with it.
PyQt and/or the very similar Nokia-sponsored PySide (with a more "relaxed" license, LGPL instead of GPL, and the same underlying toolkit, Qt) do offer the advantage of similarity with Nokia's smartphones GUI toolkit (your fourth point) -- Nokia purchased Trolltech, the makers of Qt, exactly because Qt was the fundamental GUI toolkit for their mobile offerings.
All the toolkits you mention satisfy the conditions you pose about operating systems (Windows, Mac, Linux), your second point.
Your first and to some extend third points depend in good part of what learning materials you have available for each of the toolkits. To my tastes, it seems that wxPython's tutorial (the new one in wiki form is what I'm pointing to and recommending) is really good, and PyQt's not bad at all; PySide's docs don't include a good tutorial (that I know of), I believe PySide's intention is that you first learn PyQt (with the reasonable available materials), then apply these few differences to be programming in PySide instead of PyQt;-). Tkinter's tutorials that I can find are either very old or focused on the underlying toolkit's multi-language nature, which I think makes them inferior.
If you can afford a book, PyQt has a good one (also applies to PySide, as above) -- this excellent and free one is unfortunately very old, so I don't think it helps. wxPython's own book is also quite good; tkinter's, again, is very dated.
Personally I recommend PyQt / PySide: overall power A+, ease to get started (with the above tutorial and book) A-, Nokia-phone programmer similarity A. For wxPython I'd say power A, ease A, Nokia-similarity B. Tkinter's dated tutorials and book are important negatives.
You also mention Android, but I don't see how anything could be similar to both Android and Nokia's phone-GUI programming at the same time. Maybe I'm not familiar enough with Android GUI programming, but it seems to me that it differs from every one of the toolkits you've mentioned.
PyGTK fufills at least the first three points. I'm not sure on the fourth. It has a nice tutorial here: http://www.pygtk.org/pygtk2tutorial/index.html
I guess you are looking for Glade.
The site says:
Glade is a RAD tool to enable quick & easy development of user
interfaces for the GTK+ toolkit and the GNOME desktop environment.
The user interfaces designed in Glade are saved as XML, and by using
the GtkBuilder GTK+ object these can be loaded by applications
dynamically as needed.
By using GtkBuilder, Glade XML files can be used in numerous
programming languages including C, C++, C#, Vala, Java, Perl,
Python,and others.
I am a pretty noob programmer yet, but I am having just a few issues to get things started with C and Glade. So I guess you will run smoothly here with your snake. Take a look.
I recall when I first read Pragmatic Programmer that they suggested using scripting languages to make you a more productive programmer.
I am in a quandary putting this into practice.
I want to know specific ways that using Python or Ruby can make me a more productive .NET developer.
One specific way per answer, and even better if you can say whether I could use Python or Ruby or Both for it.
See standard format below.
IronPython / IronRuby
IronPython in Action will do a better job explaining this (and exactly how best to use IronPython) that can possibly be accommodated in a SO answer. I'm biased -- I was a tech reviewer and am a friend of one of the authors -- but objectively think it's a great book. (No idea if IronRuby is blessed with a similarly wonderful book, yet).
As you want "one specific way per answer" (incompatible with SO, which STRONGLY discourages a poster posting 25 different answers if they have 25 "specific ways" to indicate...!-): prototyping in order to explore some specific assembly or collection thereof that you're unfamiliar with (to check if you've understood their docs right and how to perform certain tasks) is an order of magnitude more productive in IronPython than in C#, as you can explore interactively and compilation is instantaneous and as-needed. (Have not tried IronRuby but I'll assume it can work in a roughly equivalent way and speed).
Less Code
I think productivity is direct result on how proficient you are in a specific language. That said the terseness of a language like Python might save some time on getting certain things done.
If I compare how much less code I have to write for simple administration scripts (e.g. clean-up of old files) compared to .NET code there is certain amount of productivity gain. (Plus it is more fun which also helps getting the job done)
Advanced Text Processing
Traditional strengths of awk and perl. You can just glue together a bunch of regular expressions to create a simple data-mining system on the go.
Learning a new language gives you knowledge that you can bring back to any programming language. Here are some things you'd learn.
Add functionality to your objects on the fly.
Mix in modules.
Pass a chunk of code around.
Figure out how to do more with less code: ruby -e "puts 'hello world'"
C# can do some of these things, but a fresh perspective might bring you one step closer to automating your breakfast.
Embedding a script engine
Use of IronPython for a scripting engine inside your .NET application. For example enabling end-users of your application to change customizable parts with a full fledge language such as Python.
A possible example might be to expose custom logic to end-users for a work flow engine.
Quick Prototyping - Both
In the simplest cases when firing a python interpreter and writing a line or two is way faster than creating a new project in visual studio.
And you can use ruby to. Or lua, or evel perl, whatever. The point is implicit typing and light-weight feel.
Cross platform
Compared to .NET a simple script Python is more easily ported to other platforms such as Linux. Although possible to achieve the same with the likes of Mono it simpler to run a Python script file on different platforms.
Processing received Email
Python has built-in support for POP3 and IMAP where the standard .NET framework doesn't. Useful for automating email triggered tasks.