Does OOP make sense for small scripts?

Does OOP make sense for small scripts? - python

I mostly write small scripts in python, about 50 - 250 lines of code. I usually don't use any objects, just straightforward procedural programming.
I know OOP basics and I have used object in other programming languages before, but for small scripts I don't see how objects would improve them. But maybe that is just my limited experience with OOP.
Am I missing something by not trying harder to use objects, or does OOP just not make a lot of sense for small scripts?

I use whatever paradigm best suits the issue at hand -- be it procedural, OOP, functional, ... program size is not a criterion, though (by a little margin) a larger program may be more likely to take advantage of OOP's strengths -- multiple instances of a class, subclassing and overriding, special method overloads, OOP design patterns, etc. Any of these opportunities can perfectly well occur in a small script, there's just a somewhat higher probability that it will occur in a larger one.
In addition, I detest the global statement, so if the natural procedural approach would require it, I will almost invariably switch to OOP instead -- even if the only advantage is the ability to use a qualified name instead of the barename which would require global.
There's definitely no need to "try harder" in general -- just ask yourself "is there an opportunity here to use (a) multiple instances (etc etc)" and it will soon become second nature, i.e., you'll spot the opportunities without needing to consciously remind yourself every time to look for them, and your programming will improve as a result.

Object-Oriented Programming, while useful for representing systems as real-world objects (and hopefully making large software system easier to understand) is not the silver bullet to every solution (despite what some people teach).
If your system does not benefit from what OOP provides (things such as data abstraction, encapsulation, modularity, polymorphism, and inheritance), then it would not make sense to incur all the overhead of doing OOP. However, if you find that as your system grows these things become a bigger concern to you, then you may want to consider moving to an OOP solution.
Edit: As an update, you may want to head over to Wikipedia to read the articles on various criticisms of OOP. Remember that OOP is a tool, and just like you wouldn't use a hammer for everything, OOP should not be used for everything. Consider the best tool for the job.

One of the unfortunate habits developed with oop is Objectophrenia - the delusion of seeing objects in every piece of code we write.
The reason why that happens is due our delusion of believing in the existence of a unified objects theorem.
Every piece of code you write, you begin to see it as a template for objects and how they fit into our personal scheme of things. Even though it might be a small task at hand, we get tempted by the question - is this something I could place into my class repository which I could also use for the future? Do I see a pattern here with code I have previously written and with code which my object clairvoyance tells me that I will one day write? Can I structure my present task into one of these patterns.
It is an annoying habit. Frequently, it is better not to have it. But when you find that every bit of code you write somehow falls into patterns and you refactor/realign those patterns until it covers most of your needs, you tend to get a feeling of satisfaction and accomplishment.
Problems begins to appear when a programmer gets delusional (compulsive obsessive object oriented disorder) and does not realise that there are exceptions to patterns and trying to over-manipulate patterns to cover more cases is wrong. It's like my childhood obsession with trying to cover a piece of bread completely with butter or jam spread every morning I had breakfast. That sometimes, it is just better to leave the object oriented perception behind and just perform the task at hand quick and dirty.
The accepted industrial adage of 80-20 might be a good measure. Using this adage in a different manner than it is normally perceived, we could say 80% of the time have an object oriented perception. 20% of the time - code it quick and dirty.
Be immersed by objects but eventually you have to resist its consuming you.
You probably have not done enough programming yet because if you have, you would see all the patterns that you had done and you will also begin to believe in patterns that you have yet to apply. When you begin to see such objectophrenia visions, it's time to be careful not to be consumed by them.

If you plan to use the script independently, then no. However if you plan to import it and reuse some of it, then yes. In the second case, it's best to write some classes providing the functionality that's required and then have a conditional run (if __name__=='__main__':) with code to execute the "script" version of the script.

My experience is that any purely procedural script longer than a few dozen lines becomes difficult to maintain. For one thing, if I'm setting or modifying a variable in one place and using it in another place, and those two places can't fit on a single screen, trouble will follow.
The answer, of course, is to tighten the scope and make the different parts of your application more encapsulated. OOP is one way to do that, and can be a useful way to model your environment. I like OOP, as I find I can mentally jump from thinking about how the inside of a particular object will work, to thinking about how the objects will work together, and I stay saner.
However, OOP is certainly not the only way to make your code better encapsulated; another approach would be a set of small, well-named functions with carefully defined inputs and outputs, and a master script that calls those functions as appropriate.

OOP is a tool to manage complexity in code, 50-250 lines of code are rarely complicated. Most scripts I have written are primarily procedural. So yes, for small scripts just go with procedural programming.
Note that for significantly complicated scripts OOP may be more relevant, but there is still not hard and fast rule that says use OOP for them. It is a matter of personal preference then.

Use the right tool for the right job. For small scripts that don't require complex data structures and algorithms, there is likely no use for object oriented concepts.

Am I missing something by not trying harder to use objects, or does OOP just not make a lot of sense for small scripts?
Objects buy you encapsulation and reuse (through inheritance). Neither is likely to be terribly useful when writing small scripts. When you have written a collection of similar scripts or you find yourself repeatedly changing your scripts, then maybe you should consider where objects might help.

In your case I'd say that OOP would be helpful only if it makes the scripts more readable and understandable. If not, you probably don't need to bother.

OOP is just another paradigm. A lot of problems can be solved using both procedural or OOP.
I use OOP when I see clear need of inheritance in the code i am writing, its easier to manage common behaviour and common attributes.
It sometimes makes it easy to understand, and manage. Even if the code is small.

Another benefit of OOP is to communicate intent (whether to other developers, managers, or yourself some point in the future). If the script is small enough where it can be fully communicated in a couple of sentences then OOP is probably not necessary, in my opinion.

Using OOP for few hundred lines of code rarely makes sense. But if your script is useful, it will probably grow rather quickly because new features will be added. If this is the case, it is better to start coding OOP way it will pay in the long run.

First of all - what do you mean by objects? In Python functions are objects and you're most likely using them. :)
If by objects you mean classes and instances thereof, then I would say something obvious: no, there is no reason to saying that using them is making your code better by itself. In small scripts there is not going to be any leverage coming from sophisticated OO design.

OOP is about what you get if you add polymorphism on top of modular programming.
The latter of both promotes low coupling, encapsulation, separation of responsibility and some other concepts, that usually produce code, that is short, expressive, maintainable, flexible, extensible, reusable and robust.
This is not so much a question about size, but about length of the software's life cycle. If you write any code, as short as it may be, as long as it is complex enough that you don't want to rewrite it, when your requirements change, it is important that it meets the aforementioned criteria.
OOP makes modular programming easier in that it has established solutions for implementing the concepts promoted by modular programming, and that polymorphism allows really low coupling through dependency injection.
I personally find it simpler to use OOP to achieve modularity (and reusability in particular), but I guess, that is a matter of habit.
To put it in one sentence. OOP will not help you in solving a given problem better, than procedural programming, but instead yields a solution, that is easier to apply to other problems.

It really depends on what the script is an what it's doing and how you think about the world.
Personally after a script has made it past 20-30 lines of code I can usually find a way that OOP makes more sense to me (especially in Python).
For instance, say I'm writing a script that parses a log file. Well, conceptually I can imagine this "log parser" machine... I can throw all these sheets of paper into it and it will sort them, chop parts out of some pages and paste them onto another and eventually hand me a nice report.
So then I start thinking, well, what does this parser do? Well, first off he's (yes, the parser is a he. I don't know how many of my programs are women, but this one is definitely a guy) going to read the pages, so I'll need a method called page reader. Then he's going to find all of the data referring to the new Frobnitz process we're using. Then he's going to move all the references about the Frobnitz process to appear next to the Easter Bunny graph. Ooh, so now I need a findeasterbunny method. After he's done that, then he's going to take the rest of the logs, remove every 3rd word, and reverse the order of the text. So I'll need a thirdwordremover and a textreversal method, too. So an empty shell class would look like so:
class LogParser(Object):
def __init__(self):
#do self stuff here
def pageReader(self):
#do the reading stuff here, probably call some of the other functions
def findFrobnitz(self):
pass
def findEasterBunny(self):
pass
def thirdWordRemover(self):
pass
def textReversal(self):
pass
That's a really contrived example, and honestly probably not a situation I'd use OOP for... but it really just depends on what's easiest for me to comprehend at that particular moment in time.

"Script" means "sequential" and "procedural". It's a definition.
All of the objects your script deals with are -- well -- objects. All programming involves objects. The objects already exist in the context in which you're writing your script.
Some languages allow you to clearly identify the objects. Some languages don't clearly identify the objects. The objects are always there. It's a question of whether the language makes it clear or obscure.
Since the objects are always there, I find it helps to use a language that allows clear identification of the objects, their attributes, methods and relationships. Even for short "scripts", I find that explicit objects and an OO language helps.
The point is this.
There's no useful distinction between "procedural", "script" and "OO".
It's merely a shift in emphasis. The objects are always there. The world is inherently object-oriented. The real question is "Do you use a language that makes the objects explicit?"

as someone who does a lot of scripts, if you get the idea that your code may at some point go beyond 250 line start to go oop. I use a lot of vba and vbscript and I would agree that anything under 100 lines is usually pretty straightforward and taking the time to plan a good oop design is just a waste.
That being said I have one script that came to about 500 line + and looking back on it, because i didn't do it oop it quickly turned into an unholy mess of spaghetti. so now anything over 200 lines I make sure i have a good oop plan ahead of time

Related

Python and functional language interop

My current primary programming language is python. There are lots of things I like about it, but I also like functional languages. Not enough to do an entire program in them, but definitely for certain functionality, that fits the functional mould well.
Of course .NET is amazing in this regard, having both ironpython and F#. But considering the ironpython support for the scientific python ecosystem is still dodgy last time I checked, .NET is not much of an option for me. I am a bit shocked at the apparent lack of tools to facilitate interop between cpython and say, Haskell. They are both mature languages with large communities, that seem like such a nice match to me.
Is there something about their architecture that makes them ill-compatible that im missing, or is this just something awesome that is still waiting to happen?
To clarify; there are some half-baked projects out there, but I am thinking of something that parallels the awesomeness of Weave, pycuda, or boost. Something that automates all the plumbing inherent in interop with just a few annotations.

Another approach is to use unix pipes, and just write a Haskell program, and also write a Python program, and have them communicate over text. Haskell and Python even share the same syntax for lists, so it's really easy to pipe data from one to the other.

Referring to:
Is there something about their architecture that makes them
ill-compatible that im missing, or is this just something awesome that
is still waiting to happen?
I think it is about the people doing these languages:
There are not much people who want to do Haskell and Python at the same time.
to make use of both languages (liek Haskell and Python) at the same time you either could go via the C-Interface or create a protocol both languages speak.
Both are fairly advanced, limiting the number of people who could do it. Sure there would be also tradeoffs which make it difficult to use the full power of both languages.
I am using Python and although I know some Haskell, I do not program it. I am a bit stuck in object-orientation, telling me that some day a problem will decide for me that it can better be solved in Haskell than python. That problem did not yet occur because my first thought is: I know how to do it in Python. I think other 'experts' face that problem, too.
You start thinking in a language. I think that Haskell has a totally different way of thinking with its functional style, no side-effects. To get into this thinking I need to forget or not use my Python knowledge. Switching between these two ways of thinking requires some strength.
Wrapping it up: because that two languages are not so close they stay apart. It is hard to do both and there are not many or easy ways to practice doing both.

I think that any answer to this question would be remiss without considering the inertia of object-oriented and imperative languages relative to functional ones. Consider the following situation, beginning with the fact that functional languages are not taught at nearly the frequency that object-oriented or imperative languages are at the secondary, university, or graduate level. As User mentions, there is significant momentum involved as a programmer concerning one's choice of language. For example, during the course of a typical CS degree at a four year University, one may learn a handful of languages and more than likely, not one of them is a functional language. This typical graduate will then proceed to work in industry, where, after programming for 40+ hours per week for one's job, it is very difficult to then take time to, not only learn an entirely new language, but to learn a language that operates completely differently from the one's one already knows. On top of all of this, there is the drawback that functional languages are not nearly as useful in industry as object-oriented or imperative one's are. One can see that given this current state, it is understandable that the interoperability between Python and Haskell is not what some programmers would like it to be.

If you were to use Haskell to Python bindings, what would you do in each language?
If you consider binding C and Python, for example, you use C when you need the speed boost, or when you need to push bits around, and you are using Python when want to be expressive and concise. It's common that you have a pair of languages, one for most of the logic, and one that you can drop down to for speed, at the cost of clarity. The more of a gap between the languages, the more you can gain from switching.
If we were to bind Haskell and Python, it is less clear what you'd get out of it. I wouldn't drop from Python into Haskell just for speed, since Haskell, while fast, isn't as fast as C. But if I was using Haskell, when would I use Python? Python isn't more expressive than Haskell, not like comparing C and Python.
I think that most of the time, it's easier to just import functools, and program functionally in Python, instead of having to convert objects into some Haskell representation, do some work, and then convert it back.
Though, if you really wanted it, Cython would make it easy to write functions that Haskell's FFI can use.

coding language customization

I've always wondered this since I started to code: is there any way to customize deep portions of a language to your taste.
For example, I code mainly in Python would like to use the | or : characters to denote the boundary of a Set. I use sets frequently and hate typing set(some_list) or explicitly set([a,b,b,c,d]). I've been using s() by setting s = set, but this wouldn't work if I was working on code others would have to read.
Perhaps a "translator" text-editor add-on which would save 2 copies of your code, one with your own syntax and one with the standard syntax would be sufficient. Is there such a thing? (especially for python)

Clarity and readability is a very important trait in production code. Remember that far more effort is generally expended into reading existing code than is spent writing new code. Maintenance is a serious consideration.
With that in mind, doing something like s = set and using s() instead of set() adds no functional benefit and is detrimental to readability while only offering the savings of a couple keystrokes. I think you recognize that on some level, but part of you isn't willing to accept the additional keystrokes in the name of readability.
I urge you to consider something like a macro instead so you feel better about pressing only a single key while still producing the same code. Something like a Logitech G15/G110/G19 keyboard even allows you to do this independent of the editor you're using so you don't need a software add-on. A few mice would allow you to do something similar as well (oh how I love my Razer Naga). Of course, a basic macro feature in software would work as well, but you're probably pressing a key combination to do it and just typing set( is probably faster anyway.

It is possible indeed to customise your language as you like. Some languages provide powerful metaprogramming features (unfortunately, Python is not one of them). Take a look at Lisp macros, or Nemerle, or Converge (the latter is the closest to Python). Some languages, like Katahdin, would even allow you to modify the very syntax easily.
But this sort of power should not be used for petty language modifications - it would hinder the readability and won't add any significant benefits. It's much better to use metaprogramming for implementing the embedded Domain Specific Languages, preferably with distinctive syntax, so it would be obvious for a reader when you're using the core language constructs and when it is a eDSL code.
Of course, if you're designing your own language from scratch or implementing an existing language, you can also use metaprogramming and syntax alteration tricks for the core language functionality as well, it is a much more flexible approach than having a huge, bloated core language from the very beginning.

What does a dynamic language like python give you? Coming from a c#/java background. show me the light! [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What’s with the love of dynamic Languages
I'm coming from a c#/java background i.e. strongly typed, OOP language.
I'm very much interested in Python, but I need to learn a little more about the advantages of a dynamic language.
What power does it really give me? (in web applications).
Can someone outline some of the advantages and cool tricks I can do?

I don't think of dynamically typed languages as "allowing cool tricks" (they do, but mostly it's not really sound to use "cool" tricks in production software -- they come in handy for testing, debugging, etc, but when it comes to getting good, fast stuff deployed for production, simplicity rules).
Rather, I think of such languages as "not getting in my way" -- in particular, not slowing me down by forcing me to redundantly specify things over and over. Not every statically typed languages does "get in your way" -- good ones with solid, logically correct type systems like Haskell let the compiler deduce types (though you may redundantly specify them if you like redundancy... or, more to the point, if you want stricter constraints than what the compiler can actually deduce from the code). But in Java (and to a lesser extent in C# except when you use the reasonably recent var keyword) redundancy is the rule, and that impacts productivity.
A compromise can be offered by third-party checking systems for Python, like typecheck -- I don't use it, myself, but I can see how somebody who really thinks static type checking adds a lot of value might be happy with it. There's even a syntax (which the Python compiler accepts but does nothing with) in recent Python versions to let you annotate your function arguments and return values -- its purpose is to let such packages as typecheck be extended to merge more naturally with the language proper (though I don't think typecheck does yet).
Edit:
As I wrote here, and I quote:
I love the explanations of Van Roy and
Haridi, p. 104-106 of their book,
though I may or may not agree with
their conclusions (which are basically
that the intrinsic difference is tiny
-- they point to Oz and Alice as interoperable languages without and
with static typing, respectively), all
the points they make are good. Most
importantly, I believe, the way
dynamic typing allows real modularity
(harder with static typing, since type
discipline must be enforced across
module boundaries), and "exploratory
computing in a computation model that
integrates several programming
paradigms".
"Dynamic typing is recommended", they
conclude, "when programs must be as
flexible as possible". I recommend
reading the Agile Manifesto to
understand why maximal flexibility is
crucial in most real-world application
programming -- and therefore why, in
said real world rather than in the
more academic circles Dr. Van Roy and
Dr. Hadidi move in, dynamic typing is
generally preferable, and not such a
tiny issue as they make the difference
to be. Still, they at least show more
awareness of the issues, in devoting 3
excellent pages of discussion about
it, pros and cons, than almost any
other book I've seen -- most books
have clearly delineated and preformed
precedence one way or the other, so
the discussion is rarely as balanced
as that;).

I enjoyed reading this comparison between Python and Java.
In relation with web, I would recommend doing a simple example with Django to see how it works.

Python (like all dynamic languages) defers attribute lookups until runtime. This allows you to break past the ideas of polymorphism and interfaces, and leverage the power of duck-typing, whereby you can use a type that merely looks like it should work, instead of having to worry about its ancestry or what it claims to implement.

Can't speak for python per se, but I was playing around with the PSObject class in Powershell last week which allows you to dynamically add members, methods, etc. Coming from a C++\C# background, this seemed like magic - no need to re-comile to get these constructs in-built making it a much nicer workflow for what I was doing.

Python is strongly typed and object oriented the difference is that Python is also dynamic.
In Python classes are objects like everything else and as every other object you can create and modify them at runtime. This basically means that you can create and change modules, metaclasses, classes, attributes/methods and functions at runtime. You can add base classes to already existing classes and several other things.

Python vs. Ruby for metaprogramming [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm currently primarily a D programmer and am looking to add another language to my toolbox, preferably one that supports the metaprogramming hacks that just can't be done in a statically compiled language like D.
I've read up on Lisp a little and I would love to find a language that allows some of the cool stuff that Lisp does, but without the strange syntax, etc. of Lisp. I don't want to start a language flame war, and I'm sure both Ruby and Python have their tradeoffs, so I'll list what's important to me personally. Please tell me whether Ruby, Python, or some other language would be best for me.
Important:
Good metaprogramming. Ability to create classes, methods, functions, etc. at runtime. Preferably, minimal distinction between code and data, Lisp style.
Nice, clean, sane syntax and consistent, intuitive semantics. Basically a well thought-out, fun to use, modern language.
Multiple paradigms. No one paradigm is right for every project, or even every small subproblem within a project.
An interesting language that actually affects the way one thinks about programming.
Somewhat important:
Performance. It would be nice if performance was decent, but when performance is a real priority, I'll use D instead.
Well-documented.
Not important:
Community size, library availability, etc. None of these are characteristics of the language itself, and all can change very quickly.
Job availability. I am not a full-time, professional programmer. I am a grad student and programming is tangentially relevant to my research.
Any features that are primarily designed with very large projects worked on by a million code monkeys in mind.

I've read up on Lisp a little and I would love to find a language that allows some of the cool stuff that Lisp does, but without the strange syntax, etc. of Lisp.
Wouldn't we all.
minimal distinction between code and data, Lisp style
Sadly, the minimal distinction between code and data and "strange" syntax are consequences of each other.
If you want easy-to-read syntax, you have Python. However, the code is not represented in any of the commonly-used built-in data structures. It fails—as most languages do—in item #1 of your 'important' list. That makes it difficult to provide useful help.
You can't have it all. Remember, you aren't the first to have this thought. If something like your ideal language existed, we'd all be using it. Since the real world falls short of your ideals, you'll have to re-prioritize your wish list. The "important" section has to be rearranged to identify what's really important to you.

Honestly, as far as metaprogramming facilities go, Ruby and Python are a lot more similar than some of their adherent like to admit. This review of both language offers a pretty good comparison/review:
http://regebro.wordpress.com/2009/07/12/python-vs-ruby/
So, just pick one based on some criteria. Maybe you like Rails and want to study that code. Maybe SciPy is your thing. Look at the ecosystem of libraries, community, etc, and pick one. You certainly won't lose out on some metaprogramming nirvana based on your choice of either.

Disclaimer: I only dabble in either language, but I have at least written small working programs (not just quick scripts, for which I use Perl, bash or GNU make) in both.
Ruby can be really nice for the "multiple paradigms" point 3, because it works hard to make it easy to create domain-specific languages. For example, browse online and look at a couple of bits of Ruby on Rails code, and a couple of bits of Rake code. They're both Ruby, and you can see the similarities, but they don't look like what you'd normally think of as the same language.
Python seems to me to be a bit more predictable (possibly correlated to 'clean' and 'sane' point 2), but I don't really know whether that's because of the language itself or just that it's typically used by people with different values. I have never attempted deep magic in Python. I would certainly say that both languages are well thought out.
Both score well in 1 and 4. [Edit: actually 1 is pretty arguable - there is "eval" in both, as common in interpreted languages, but they're hardly conceptually pure. You can define closures, assign methods to objects, and whatnot. Not sure whether this goes as far as you want.]
Personally I find Ruby more fun, but in part that's because it's easier to get distracted thinking of cool ways to do things. I've actually used Python more. Sometimes you don't want cool, you want to get on with it so it's done before bedtime...
Neither of them is difficult to get into, so you could just decide to do your next minor task in one, and the one after that in the other. Or pick up an introductory book on each from the library, skim-read them both and see what grabs you.

There's not really a huge difference between python and ruby at least at an ideological level. For the most part, they're just different flavors of the same thing. Thus, I would recommend seeing which one matches your programming style more.

Have you considered Smalltalk? It offers a very simple, clear and extensible syntax with reflectivity and introspection capabilities and a fully integrated development environment that takes advantage of those capabilities. Have a look at some of the work being done in Squeak Smalltalk for instance. A lot of researchers using Squeak hang out on the Squeak mailing list and #squeak on freenode, so you can get help on complex issues very easily.
Other indicators of its current relevance: it runs on any platform you'd care to name (including the iPhone); Gilad Bracha is basing his Newspeak work on Squeak; the V8 team cut their teeth on Smalltalk VMs; and Dan Ingalls and Randal Schwartz have recently returned to Smalltalk work after years in the wilderness.
Best of luck with your search - let us know what you decide in the end.

Lisp satisfies all your criteria, including performance, and it is the only language that doesn't have (strange) syntax. If you eschew it on such an astoundingly ill-informed/wrong-headed basis and consequently miss out on the experience of using e.g. Emacs+SLIME+CL, you'll be doing yourself a great disservice.

Your 4 "important" points lead to Ruby exactly, while the 2 "somewhat important" points ruled by Python. So be it.

You are describing Ruby.
Good metaprogramming. Ability to create classes, methods, functions,
etc. at runtime. Preferably, minimal
distinction between code and data,
Lisp style.
It's very easy to extend and modify existing primitives at runtime. In ruby everything is an object, strings, integers, even functions.
You can also construct shortcuts for syntactic sugar, for example with class_eval.
Nice, clean, sane syntax and consistent, intuitive semantics.
Basically a well thought-out, fun to
use, modern language.
Ruby follows the principle of less surprise, and when comparing Ruby code vs the equivalent in other language many people consider it more "beautiful".
Multiple paradigms. No one paradigm is right for every project,
or even every small subproblem within
a project.
You can follow imperative, object oriented, functional and reflective.
An interesting language that actually affects the way one thinks
about programming.
That's very subjective, but from my point of view the ability to use many paradigms at the same time allows for very interesting ideas.
I've tried Python and it doesn't fit your important points.

Compare code examples that do the same thing (join with a newline non-empty descriptions of items from a myList list) in different languages (languages are arranged in reverse-alphabetic order):
Ruby:
myList.collect { |f| f.description }.select { |d| d != "" }.join("\n")
Or
myList.map(&:description).reject(&:empty?).join("\n")
Python:
descriptions = (f.description() for f in mylist)
"\n".join(filter(len, descriptions))
Or
"\n".join(f.description() for f in mylist if f.description())
Perl:
join "\n", grep { $_ } map { $_->description } #myList;
Or
join "\n", grep /./, map { $_->description } #myList;
Javascript:
myList.map(function(e) e.description())
.filter(function(e) e).join("\n")
Io:
myList collect(description) select(!="") join("\n")
Here's an Io guide.

Ruby would be better than Lisp in terms of being "mainstream" (whatever that really means, but one realistic concern is how easy it would be to find answers to your questions on Lisp programming if you were to go with that.) In any case, I found Ruby very easy to pick up. In the same amount of time that I had spent first learning Python (or other languages for that matter), I was soon writing better code much more efficiently than I ever had before. That's just one person's opinion, though; take it with a grain of salt, I guess. I know much more about Ruby at this point than I do Python or Lisp, but you should know that I was a Python person for quite a while before I switched.
Lisp is definitely quite cool and worth looking into; as you said, the size of community, etc. can change quite quickly. That being said, the size itself isn't as important as the quality of the community. For example, the #ruby-lang channel is still filled with some incredibly smart people. Lisp seems to attract some really smart people too. I can't speak much about the Python community as I don't have a lot of firsthand experience, but it seems to be "too big" sometimes. (I remember people being quite rude on their IRC channel, and from what I've heard from friends that are really into Python, that seems to be the rule rather than the exception.)
Anyway, some resources that you might find useful are:
1) The Pragmatic Programmers Ruby Metaprogramming series (http://www.pragprog.com/screencasts/v-dtrubyom/the-ruby-object-model-and-metaprogramming) -- not free, but the later episodes are quite intriguing. (The code is free, if you want to download it and see what you'd be learning about.)
2) On Lisp by Paul Graham (http://www.paulgraham.com/onlisp.html). It's a little old, but it's a classic (and downloadable for free).

#Jason I respectively disagree. There are differences that make Ruby superior to Python for metaprogramming - both philosophical and pragmatic. For starters, Ruby gets inheritance right with Single Inheritance and Mixins. And when it comes to metaprogramming you simply need to understand that it's all about the self. The canonical difference here is that in Ruby you have access to the self object at runtime - in Python you do not!
Unlike Python, in Ruby there is no separate compile or runtime phase. In Ruby, every line of code is executed against a particular self object. In Ruby every class inherits from both object and a hidden metaclass. This makes for some interesting dynamics:
class Ninja
def rank
puts "Orange Clan"
end
self.name #=> "Ninja"
end
Using self.name accesses the Ninja classes' metaclass name method to return the class name of Ninja. Does metaprogramming flower so beautiful in Python? I sincerely doubt it!

I am using Python for many projects and I think Python does provide all the features you asked for.
important:
Metaprogramming: Python supports metaclasses and runtime class/method generation etc
Syntax: Well thats somehow subjective. I like Pythons syntax for its simplicity, but some People complain that Python is whitespace-sensitive.
Paradigms: Python supports procedural, object-oriented and basic functional programming.
I think Python has a very practical oriented style, it was very inspiring for me.
Somewhat important:
Performance: Well its a scripting language. But writing C extensions for Python is a common optimization practice.
Documentation: I cannot complain. Its not that detailed as someone may know from Java, but its good enough.
As you are grad student you may want to read this paper claiming that Python is all a scientist needs.
Unfortunately I cannot compare Python to Ruby, since I never used that language.
Regards,
Dennis

Well, if you don't like the lisp syntax perhaps assembler is the way to go. :-)
It certainly has minimal distinction between code and data, is multi-paradigm (or maybe that is no-paradigm) and it's a mind expanding (if tedious) experience both in terms of the learning and the tricks you can do.

Io satisfies all of your "Important" points. I don't think there's a better language out there for doing crazy meta hackery.

one that supports the metaprogramming hacks that just can't be done in a statically compiled language
I would love to find a language that allows some of the cool stuff that Lisp does
Lisp can be compiled.

Did you try Rebol?

My answer would be neither. I know both languages, took a class on Ruby and been programming in python for several years. Lisp is good at metaprogramming due to the fact that its sole purpose is to transform lists, its own source code is just a list of tokens so metaprogramming is natural. The three languages I like best for this type of thing is Rebol, Forth and Factor. Rebol is a very strong dialecting language which takes code from its input stream, runs an expression against it and transforms it using rules written in the language. Very expressive and extremely good at dialecting. Factor and Forth are more or less completely divorced from syntax and you program them by defining and calling words. They are generally mostly written in their own language. You don't write applications in traditional sense, you extend the language by writing your own words to define your particular application. Factor can be especially nice as it has many features I have only seen in smalltalk for evaluating and working with source code. A really nice workspace, interactive documents, etc.

There isn't really a lot to separate Python and Ruby. I'd say the Python community is larger and more mature than the Ruby community, and that's really important for me. Ruby is a more flexible language, which has positive and negative repercussions. However, I'm sure there will be plenty of people to go into detail on both these languages, so I'll throw a third option into the ring. How about JavaScript?
JavaScript was originally designed to be Scheme for the web, and it's prototype-based, which is an advantage over Python and Ruby as far as multi-paradigm and metaprogramming is concerned. The syntax isn't as nice as the other two, but it is probably the most widely deployed language in existence, and performance is getting better every day.

If you like the lisp-style code-is-data concept, but don't like the Lispy syntax, maybe Prolog would be a good choice.
Whether that qualifies as a "fun to use, modern language", I'll leave to others to judge. ;-)

Ruby is my choice after exploring Python, Smalltalk, and Ruby.

What about OCaml ?
OCaml features: a static type system, type inference, parametric polymorphism, tail recursion, pattern matching, first class lexical closures, functors (parametric modules), exception handling, and incremental generational automatic garbage collection.
I think that it satisfies the following:
Important:
Nice, clean, sane syntax and consistent, intuitive semantics. Basically a well thought-out, fun to use, modern language.
Multiple paradigms. No one paradigm is right for every project, or even every small subproblem within a project.
An interesting language that actually affects the way one thinks about programming.
Somewhat important:
Performance. It would be nice if performance was decent, but when performance is a real priority, I'll use D instead.
Well-documented.

I've use Python a very bit, but much more Ruby. However I'd argue they both provide what you asked for.
If I see all your four points then you may at least check:
http://www.iolanguage.com/
And Mozart/Oz may be interesting for you also:
http://mozart.github.io/
Regards
Friedrich

For python-style syntax and lisp-like macros (macros that are real code) and good DSL see converge.

I'm not sure that Python would fulfill all things you desire (especially the point about the minimal distinction between code and data), but there is one argument in favour of python. There is a project out there which makes it easy for you to program extensions for python in D, so you can have the best of both worlds. http://pyd.dsource.org/celerid.html

if you love the rose, you have to learn to live with the thorns :)

I would recommend you go with Ruby.
When I first started to learn it, I found it really easy to pick up.

Do not to mix Ruby Programming Language with Ruby Implementations, thinking that POSIX threads are not possible in ruby.
You can simply compile with pthread support, and this was already possible at the time this thread was created, if you pardon the pun.
The answer to this question is simple. If you like lisp, you will probably prefer ruby. Or, whatever you like.

I suggest that you try out both languages and pick the one that appeals to you. Both Python and Ruby can do what you want.
Also read this thread.

Go with JS just check out AJS (Alternative JavaScript Syntax) at my github http://github.com/visionmedia it will give you some cleaner looking closures etc :D

Concerning your main-point (meta-programming):
Version 1.6 of Groovy has AST (Abstract Syntax Tree) programming built-in as a standard and integrated feature.
Ruby has RubyParser, but it's an add-on.

Do OO design principles apply to Python?

It seems like many OO discussions use Java or C# as examples (e.g. Head First Design Patterns).
Do these patterns apply equally to Python? Or if I follow the design patterns, will I just end up writing Java in Python (which apparently is a very bad thing)?

The biggest differences are that Python is duck typed, meaning that you won't need to plan out class hierarchies in as much detail as in Java, and has first class functions. The strategy pattern, for example, becomes much simpler and more obvious when you can just pass a function in, rather than having to make interfaces, etc. just to simulate higher order functions. More generally, Python has syntactic sugar for a lot of common design patterns, such as the iterator and the aforementioned strategy. It might be useful to understand these patterns (I've read Head First and found it pretty useful), but think about Pythonic ways to implement them rather than just doing things the same way you would in Java.

Python has it's own design idioms. Some of the standard patterns apply, others don't. Something like strategy or factories have in-language support that make them transparent.
For instance, with first-class types anything can be a factory. There's no need for a factory type, you can use the class directly to construct any object you want.
Basically, Python has its own design idioms that are somewhat different largely because it's so dynamic and has incredible introspection capabilities.
Example:
x = list
my_list = x(range(0,5)) #creates a new list by invoking list's constructor
By assigning the class-type to a callable object you can essentially remove any 'factory' types in your code. You are only left with callables that produce objects that should conform to some given conventions.
Furthermore, there are design patterns in Python that just can't be represented in other statically-typed languages efficiently. Metaclasses and function decorators are good examples of this.

It depends on the pattern. Some things are difficult to do in Python: Singleton is an example. You replace this pattern with another, such as, in the case of Singleton, Borg.
It's not insane to use design patterns in Python-- the Iterator pattern, for instance, is integrated into the syntax. However, many things simply aren't done as OO- or pattern-heavy stuff. Python is made to be procedural or functional when it best suits the task, and OO too.
Overall, I'd just say to use your best judgment. If it seems like using Design Pattern Alpha-Gamma is overkill and overcomplication, then it probably is. If it seems like the pattern is perfect for what you want, it probably is.

Design patterns are little more than duct-tape to fix a languages deficiencies.

Short answer: Yes; Python is an OO language.
Slightly longer answer: Yes; you can design using OO principles and then implement in any language (even assembler).
The benefit of using an OO language is that it incorporates support for many common OO concepts, so you don't risk unnecessary bugs having to simulate them by convention. Of course there will always be language-specific details with greater or lesser applicability; you asked about "design principles", which should be expressed above that level of detail.
Long, verbose, boring answer: (The development of programming languages isn't a simple linear progression, but let me oversimplify and ignore that fact to make an observation that spans about 40 years' of programming experience.)
There's always going to be a role for language features vs. design principles and patterns. At every stage, attentive practitioners have noticed:
"Here's a problem we keep solving by hand in our current language(s)."
"Here's a bug we keep writing in our current language(s)."
"Here are some good practices we keep observing in our best programs."
And so the next generation of language(s) tend provide support for observed good behavior, tend to incorporate concepts so they don't have to be done by convention/agreement (or accidentally broken by the same), and enforce practices that prevent easily avoidable errors.
Regardless of how sophisticated, specialized, or generalized our tools, there are always programmers who "just turn the crank" and others who keep looking watching for how the "best and brightest" (in the mind of the beholder) use the tools. They then describe and promote those practices. Correctly defined (and whether called "style", "guidelines", "patterns", "principles", etc.), those practices end up forming "the next level" that we're always trying to reach, regardless of where we are currently standing.

On further thought, some patterns, such as Borg, may be more specific to Python (though similar things can be said about other patterns and languages).
The iterator pattern is also used in Python, albeit in a slightly different form.
Duncan Booth has written an article on patterns in python.

I'd say they apply to Python once you're already doing object-oriented programming with Python. Keep in mind that Python can do a lot more than OOP, and you should use common sense in choosing the appropriate paradigm for the job. If you decide that your program is best represented as a collection of objects, then sure, go ahead and use the design patterns, but don't be afraid to do something completely different if it's called for.

yes, of course they apply. But as noted above, many patterns are built into the language, or made irrelevant by higher level features of the language.

The use of Java or C# is probably due to the mainstream popularity of the language.
But design principle and/or design patterns apply irrespective of the language you use. The implementation of the same design pattern in Python would obviously be different than in Java or C#.

Yes, you can use plenty of design patterns in Python. A design pattern is just a repeatable implementation of a higher level task. The reason why Python & design patterns don't work the same as other languages is because Python includes most of the basic patterns built in. This means that patterns that emerge in Python are likely to be higher level design patterns instead of the menial tasks for which patterns are usually needed.

We Keep Coding

Python is a programming language that lets you work quickly and integrate systems more effectively.