Related
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.
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 10 years ago.
Python and Ruby are usually considered to be close cousins (though with quite different historical baggage) with similar expressiveness and power. But some have argued that the immense success of the Rails framework really has a great deal to do with the language it is built on: Ruby itself. So why would Ruby be more suitable for such a framework than Python?
There are probably two major differences:
Ruby has elegant, anonymous closures.
Rails uses them to good effect. Here's an example:
class WeblogController < ActionController::Base
def index
#posts = Post.find :all
respond_to do |format|
format.html
format.xml { render :xml => #posts.to_xml }
format.rss { render :action => "feed.rxml" }
end
end
end
Anonymous closures/lambdas make it easier to emulate new language features that would take blocks. In Python, closures exist, but they must be named in order to be used. So instead of being able to use closures to emulate new language features, you're forced to be explicit about the fact that you're using a closure.
Ruby has cleaner, easier to use metaprogramming.
This is used extensively in Rails, primarily because of how easy it is to use. To be specific, in Ruby, you can execute arbitrary code in the context of the class. The following snippets are equivalent:
class Foo
def self.make_hello_method
class_eval do
def hello
puts "HELLO"
end
end
end
end
class Bar < Foo # snippet 1
make_hello_method
end
class Bar < Foo; end # snippet 2
Bar.make_hello_method
In both cases, you can then do:
Bar.new.hello
which will print "HELLO". The class_eval method also takes a String, so it's possible to create methods on the fly, as a class is being created, that have differing semantics based on the parameters that are passed in.
It is, in fact, possible to do this sort of metaprogramming in Python (and other languages, too), but Ruby has a leg up because metaprogramming isn't a special style of programming. It flows from the fact that in Ruby, everything is an object and all lines of code are directly executed. As a result, Classes are themselves objects, class bodies have a self pointing at the Class, and you can call methods on the class as you are creating one.
This is to large degree responsible for the degree of declarativeness possible in Rails, and the ease by which we are able to implement new declarative features that look like keywords or new block language features.
Those who have argued that
the immense success of the Rails
framework really has a great deal to
do with the language it is built on
are (IMO) mistaken. That success probably owes more to clever and sustained marketing than to any technical prowess. Django arguably does a better job in many areas (e.g. the built-in kick-ass admin) without the need for any features of Ruby. I'm not dissing Ruby at all, just standing up for Python!
The python community believes that doing things the most simple and straight forward way possible is the highest form of elegance. The ruby community believes doing things in clever ways that allow for cool code is the highest form of elegance.
Rails is all about if you follow certain conventions, loads of other things magically happen for you. That jives really well with the ruby way of looking at the world, but doesn't really follow the python way.
Is this debate a new "vim versus emacs" debate?
I am a Python/Django programmer and thus far I've never found a problem in that language/framework that would lead me to switch to Ruby/Rails.
I can imagine that it would be the same if I were experienced with Ruby/Rails.
Both have similar philosophy and do the job in a fast and elegant way. The better choice is what you already know.
Personally, I find ruby to be superior to python in many ways that comprise what I'd call 'consistent expressiveness'. For example, in ruby, join is a method on the array object which outputs a string, so you get something like this:
numlist = [1,2,3,4]
#=> [1, 2, 3, 4]
numlist.join(',')
#=> "1,2,3,4"
In python, join is a method on the string object but which throws an error if you pass it something other than a string as the thing to join, so the same construct is something like:
numlist = [1,2,3,4]
numlist
#=> [1, 2, 3, 4]
",".join([str(i) for i in numlist])
#=> '1,2,3,4'
There are a lot of these little kinds of differences that add up over time.
Also, I cannot think of a better way to introduce invisible logic errors than to make whitespace significant.
The real answer is neither Python or Ruby are better/worse candidates for a web framework. If you want objectivity you need to write some code in both and see which fits your personal preference best, including community.
Most people who argue for one or other have either never used the other language seriously or are 'voting' for their personal preference.
I would guess most people settle on which ever they come in to contact with first because it teaches them something new (MVC, testing, generators etc.) or does something better (plugins, templating etc). I used to develop with PHP and came in to contact with RubyOnRails. If I had have known about MVC before finding Rails I would more than likely never left PHP behind. But once I started using Ruby I enjoyed the syntax, features etc.
If I had have found Python and one of its MVC frameworks first I would more than likely be praising that language instead!
Python has a whole host of Rails-like frameworks. There are so many that a joke goes that during the typical talk at PyCon at least one web framework will see the light.
The argument that Rubys meta programming would make it better suited is IMO incorrect. You don't need metaprogramming for frameworks like this.
So I think we can conclude that Ruby are not better (and likely neither worse) than Python in this respect.
Because Rails is developed to take advantage of Rubys feature set.
A similarly gormless question would be "Why is Python more suitable for Django than Ruby is?".
I suppose we should not discuss the language features per se but rather the accents the respective communities make on the language features. For example, in Python, re-opening a class is perfectly possible but it is not common; in Ruby, however, re-opening a class is something of the daily practice. this allows for a quick and straightforward customization of the framework to the current requirement and renders Ruby more favorable for Rails-like frameworks than any other dynamic language.
Hence my answer: common use of re-opening classes.
Some have said that the type of metaprogramming required to make ActiveRecord (a key component of rails) possible is easier and more natural to do in ruby than in python - I do not know python yet;), so i cannot personally confirm this statement.
I have used rails briefly, and its use of catchalls/interceptors and dynamic evaluation/code injection does allow you to operate at a much higher level of abstraction than some of the other frameworks (before its time). I have little to no experience with Python's framework - but i've heard it's equally capable - and that the python community does a great job supporting and fostering pythonic endeavors.
I think that the syntax is cleaner and Ruby, for me at least, is just a lot more "enjoyable"- as subjective as that is!
Two answers :
a. Because rails was written for ruby.
b. For the same reason C more suitable for Linux than Ruby
All of this is TOTALLY "IMHO"
In Ruby there is ONE web-application framework, so it is the only framework that is advertised for that language.
Python has had several since inception, just to name a few: Zope, Twisted, Django, TurboGears (it itself a mix of other framework components), Pylons (a kinda-clone of the Rails framework), and so on. None of them are python-community-wide supported as "THE one to use" so all the "groundswell" is spread over several projects.
Rails has the community size solely, or at least in the vast majority, because of Rails.
Both Python and Ruby are perfectly capable of doing the job as a web applications framework. Use the one YOU (and your potential development team) like and can align on.
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 10 years ago.
Py3k just came out and has gobs of neat new stuff! I'm curious, what are SO pythonistas most excited about? What features are going to affect the way you write code on a daily basis, or have you been looking forward to?
There are a few things I'm quite interested in:
Text and data instead of unicode and 8 bit
Extended Iterable Unpacking
Function annotations
Binary literals
New exception catching syntax
A number of Python 2.6 features, eg: the with statement
I hope that exception chaining catches on. Losing exception stack traces due to the antipattern presented below had been my pet peeve for a long time:
try:
doSomething( someObject)
except:
someCleanup()
# Thanks for passing the error-causing object,
# but the original stack trace is lost :-(
raise MyError("Bad, bad object!", someObject)
I know, I know, adding some context info to the original exception and preserving the original stack trace was possible, but it required a really ugly hack. Now you can (and should!) just:
raise MyError("Bad, bad object!", someObject) from original_exception
and easily get both of the above. So, as a part of my holy mission against lost stack traces:
Folks, don't forget the from clause when reraising exceptions! Thank you.
Quite frankly, none of it. While I'll probably find myself using some of the new syntax, I mainly use Python for quick and simple scripts and regular expressions.
I think the new features will make a lot of little things a little easier for a lot of people and a few big things easy for a few people. However, I am skeptical of any claims that a lot of people will end up finding massive gains in productivity.
In short, I think these changes will make things a little better overall, but don't expect any miracles.
Not so much a feature, but I think the library cleanup will be of great help, esp. to new python programmers. On more than one occasion have I wanted to do something in python only to find two included libraries that offer that functionality, with no obvious reason why I should chose one over the other.
Despite what they did to achieve smallest possible migration course with interpreted languages, I find the whole release of python3 as ten years of painful path of migration. Therefore I don't find it particularly attracting.
The improvements they did are all good and important. Two different types for strings have been a real source of annoyances everywhere, therefore it's good they got rid from unicode object and introduced bytes object aside now unicode str.
The bignum vs. num -change was from convenience and I think that too was a good choice. In overall they cleaned the language from harmful components they accumulated during the last ten years.
Second worst thing they did was 10% slower implementation, as if speed wouldn't be python's problem already.
I believe the release of python3 pushes down python's reputation rather than improves it. Right now they are back in the start with their language when it comes down to library support.
Not having to do as much..
Not having to worry about using unicode() or u"".
Not having to search though the docs of urllib urllib2 and httplib to find where that functions I need to to encode a file and upload it via a POST request
Not having to worry about wether except TypeError, something: will catch a TypeError and something, or TypeError into `something..
And conversely, having to look at the docs again! I know python well enough now I can do most stuff without referring to pydoc, but every time that I do, I discover some other useful module or function.
The print statement. <sniff> I'm starting to miss it already.
Actually, before even going to Python 2.6, we're purging print in favor of logging.debug. This is just to get out of the habit of using print casually for debugging, support and development.
What remains are some programs that actually produce stuff on stdout. For those, we may introduce a 2.6/3.0 compatible "print" function in one of our libraries.
Dictionary comprehensions aren't necessarily earth-shattering but they're very nice.
While {k: v for k, v in list} is longer than dict(list) it's more flexible and self-explanitory.
One of the most underestimated features of Python 3 is the introduction of Abstract Base Classes. This is something that won't revolutionize Python programming straight away, but represents an interesting shift from a loose duck typing approach into the direction of better defined interfaces.
More information can be found in PEP 3119.
Just about all of them as I am taking the release of Python 3 as motivation to learn the language.
Unicode (utf-8) is really important for people living in non-english speaking countries.
I didn't like to specify the encoding at the beginning of the file, because I always forget. Usually my text is compatible with ASCII because I'm using UTF-8, so it is working without the encoding specification. But If I write my name (with an accent) or a € sign, it breaks ... I ended up writing unicode characters with their \uxxxx representation but it is kinda cryptic!
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.
Coming from a Perl 5 background, what are the advantages of moving to Perl 6 or Python?
There is no advantage to be gained by switching from Perl to Python. There is also no advantage to be gained by switching from Python to Perl. They are both equally capable. Choose your tools based on what you know and the problem you are trying to solve rather than on some sort of notion that one is somehow inherently better than the other.
The only real advantage is if you are switching from a language you don't know to a language you do know, in which case your productivity will likely go up.
Python does not have Junctions. In fact I think only Perl has Junctions so far. :-)
In my opinion, Python's syntax is much cleaner, simpler, and consistent. You can define nested data structures the same everywhere, whether you plan to pass them to a function (or return them from one) or use them directly. I like Perl a lot, but as soon as I learned enough Python to "get" it, I never turned back.
In my experience, random snippets of Python tend to be more readable than random snippets of Perl. The difference really comes down to the culture around each language, where Perl users often appreciate cleverness while Python users more often prefer clarity. That's not to say you can't have clear Perl or devious Python, but those are much less common.
Both are fine languages and solve many of the same problems. I personally lean toward Python, if for no other reason in that it seems to be gaining momentum while Perl seems to be losing users to Python and Ruby.
Note the abundance of weasel words in the above. Honestly, it's really going to come down to personal preference.
Perl is generally better than python for quick one liners, especially involve text/regular expressions
http://novosial.org/perl/one-liner/
Python has one huge advantage: it's implemented, there's a rather stable compiler for it.
Perl 6 (renamed Raku in 2019) is a rather visionary language, with a stable compiler and test specification released in 2015. It has a set of very cool features, among them: junctions, grammars (yes, you can write full parsers with Raku "regexes"), unicode handling at the grapheme level, and lazy lists.
In your particular case when you know Perl 5 you'll get familiar with the Raku (née Perl 6) syntax very quickly.
For a more comprehensive list of what cool features Raku has, see https://raku.org/ or alternatively, the FAQ.
Python has a major advantage of being available in a production-ready format today.
Python has Jython and IronPython, if you need to work closely with Java or the .net clr.
Perl 6 has the advantages of being based on the same principles as Perl (1-5); If you like Perl, you'll like Perl 6 for the same reasons. (There's more than one way to do it, etc.)
Perl 6 also has an advantage of being only partially implemented: If you want to hack on language internals or help to define the standard libraries, this is a great time to get started in Perl 6.
Edit: (2011) It's still a great time to hack on the Perl6 internals, but there is now a much more mature, usable Perl6 distribution, Rakudo Star. If you want to use Perl6 today, that's a great choice.
You have not said why you want to move away from Perl*. If my crystal ball is functioning today then it is because you do not fully know the language and so it frustrates you.
Stick with Perl and study the language well. If you do then one day you will be a guru and know why your question is irrelevant. Enlightment comes to those to seek it.
You called it "Perl5" but there is no such language. :P
IMO python's regexing, esp. when you try to represent something like perl's /e operator as in s/whatever/somethingelse/e, becomes quite slow. So in doubt, you may need to stay with Perl5 :-)
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.