Which scripting language to learn?
November 4, 2005 6:09 PM Subscribe
Looking to learn a scripting language. Which?
I'm a mostly networking/IP Telephony IT worker, and I’m finally ready to take the Asterisk plunge. And the one thing that impressed me most (ok, after the price tag) was the Asterisk Gateway Interface, basically a scriptable way to control phone calls, tie in text-to-speech, etc. You script all the computation and decision making, then feed back single-line commands like “get digits” or “play this WAV file”.
The problem is, while I have (in my school days) done some C++, ASP, and Java programming, what I know about Linux scripting languages could be handily contained on a cocktail napkin.
The examples I've seen on line (and in the excellent O'Reilly book about Asterisk) are all in PHP, Python, and Perl. In theory you could use anything, Pascal, Bourne...
So if you had to learn a scripting language, with no preconceived notions, which would you use?
I'm a mostly networking/IP Telephony IT worker, and I’m finally ready to take the Asterisk plunge. And the one thing that impressed me most (ok, after the price tag) was the Asterisk Gateway Interface, basically a scriptable way to control phone calls, tie in text-to-speech, etc. You script all the computation and decision making, then feed back single-line commands like “get digits” or “play this WAV file”.
The problem is, while I have (in my school days) done some C++, ASP, and Java programming, what I know about Linux scripting languages could be handily contained on a cocktail napkin.
The examples I've seen on line (and in the excellent O'Reilly book about Asterisk) are all in PHP, Python, and Perl. In theory you could use anything, Pascal, Bourne...
So if you had to learn a scripting language, with no preconceived notions, which would you use?
The asterix stuff is pretty remarkably, isn't it? I work on the fringe of the phone world and I can see that really taking off.
If I wasn't doing web-specific stuff, I'd probably learn perl. Perl can do anything -- it's kinda the swiss army knife of programming, and there are about 80 billion examples on the internet.
Given that you know other programming languages, picking up one of the main scripting languages shouldn't be too hard -- perl, php, python, vb -- you kinda know 'em already. They're not all that different in the end.
posted by ph00dz at 6:16 PM on November 4, 2005
If I wasn't doing web-specific stuff, I'd probably learn perl. Perl can do anything -- it's kinda the swiss army knife of programming, and there are about 80 billion examples on the internet.
Given that you know other programming languages, picking up one of the main scripting languages shouldn't be too hard -- perl, php, python, vb -- you kinda know 'em already. They're not all that different in the end.
posted by ph00dz at 6:16 PM on November 4, 2005
I take it you're only interested in languages with Asterisk bindings?
Either of Perl or Python will work well. If you've no UNIX background whatsoever and you're of an OO bent, you might find Python more approachable than Perl. If you've spent time with UNIX machines, Perl's an obvious choice.
Shortly, a bunch of people are going to pop up and tell you how horrid Perl is. Make sure to ignore them and form your own opinion.
PHP's a nifty scripting environment, but as system glue it has far less maturity than Perl or even Python.
Oh, and Pascal is usually a traditionally compiled language, not a scripting system.
posted by majick at 6:17 PM on November 4, 2005
Either of Perl or Python will work well. If you've no UNIX background whatsoever and you're of an OO bent, you might find Python more approachable than Perl. If you've spent time with UNIX machines, Perl's an obvious choice.
Shortly, a bunch of people are going to pop up and tell you how horrid Perl is. Make sure to ignore them and form your own opinion.
PHP's a nifty scripting environment, but as system glue it has far less maturity than Perl or even Python.
Oh, and Pascal is usually a traditionally compiled language, not a scripting system.
posted by majick at 6:17 PM on November 4, 2005
I got my start in PHP. I've written 10s of thousands of lines of it. I enjoy it and it's easy to use. Which is just to say: Python is the prettiest thing I've come across (Ruby is a similar type of Lisp for Dummies).
posted by yerfatma at 6:35 PM on November 4, 2005
posted by yerfatma at 6:35 PM on November 4, 2005
Perl is like an aggravating relationship with an awesome but flawed friend. At times you will swear to yourself you're leaving and never coming back, but you will go back. You always do, and there's good reasons. Though you may, eventually, find yourself steadily seeing someone else.
Ruby is getting some traction with the Rails craze. I haven't decided if I like it yet or not.
Python... I miss my freeform syntax formatting and even more, I miss curly braces. They're like a big syntactic hug, and help cue my eyes more than whitespace alone. But python is Good Stuff, and someone who hasn't been writing in C-influenced languages for 15 years might not miss the braces so much.
posted by namespan at 6:40 PM on November 4, 2005
Ruby is getting some traction with the Rails craze. I haven't decided if I like it yet or not.
Python... I miss my freeform syntax formatting and even more, I miss curly braces. They're like a big syntactic hug, and help cue my eyes more than whitespace alone. But python is Good Stuff, and someone who hasn't been writing in C-influenced languages for 15 years might not miss the braces so much.
posted by namespan at 6:40 PM on November 4, 2005
(And php is like the parents of your screwup friend who let you do whatever you want. It's supportive and fun and easy but sometimes, it's just missing that sense of quality and judgment. Though it's getting better, and if you want to learn to write good PHP, there's increasingly better places to learn from.
But it wouldn't be my first choice for cli scripting. Its natural habitat is the web, and I am reluctant to take it outside that.)
posted by namespan at 6:48 PM on November 4, 2005
But it wouldn't be my first choice for cli scripting. Its natural habitat is the web, and I am reluctant to take it outside that.)
posted by namespan at 6:48 PM on November 4, 2005
If I can hijack this thread just a little, can someone explain what the hell "On Rails" actually means? I know quite a bit about programming, particularly web programming, and I don't get it.
Here's how web programming works -- a browser hits on a script, that script connects to a database, probably, and then a web page is built and sent back to the browser.
Where are the rails? Which bit of that does the "on rails" thing help with?
I read stuff like this:
Being a full-stack framework means that all layers are built to work seamlessly together. That way you Don’t Repeat Yourself (DRY) and you can use a single language from top to bottom. Everything from templates to control flow to business logic is written in Ruby—the language of love for industry heavy-weights.
In striving for DRY compliance, Rails shuns configuration files and annotations in favor of reflection and run-time extensions.
This means the end of XML files telling a story that has already been told in code. It means no compilation phase: Make a change, see it work. Meta-data is an implementation detail left for the framework to handle.
and just shake my head.
posted by AmbroseChapel at 6:52 PM on November 4, 2005
Here's how web programming works -- a browser hits on a script, that script connects to a database, probably, and then a web page is built and sent back to the browser.
Where are the rails? Which bit of that does the "on rails" thing help with?
I read stuff like this:
Being a full-stack framework means that all layers are built to work seamlessly together. That way you Don’t Repeat Yourself (DRY) and you can use a single language from top to bottom. Everything from templates to control flow to business logic is written in Ruby—the language of love for industry heavy-weights.
In striving for DRY compliance, Rails shuns configuration files and annotations in favor of reflection and run-time extensions.
This means the end of XML files telling a story that has already been told in code. It means no compilation phase: Make a change, see it work. Meta-data is an implementation detail left for the framework to handle.
and just shake my head.
posted by AmbroseChapel at 6:52 PM on November 4, 2005
"Ruby On Rails" is the name of a rapid-development Web application framework. "On Rails" is a metaphor for "fast", but it doesn't have any technical meaning other than "using Ruby On Rails".
What you described is how a web program works. How web programming works is something like "You write a program that uses a database library and a templating library, you design your database schema, you manually manipulate the database in your program, you design templates that contain forms that reflect the data in your database..." and so on. Rails makes that easier to do.
As an example of "Don't Repeat Yourself": the standard Rails tutorial has you create a database schema, then run the command to create the program and template fragments to go with it -- and automatically you have a Web application that provides interfaces to read, update and create database records, complete with HTML forms and the glue code.
When you write a program in Rails, it will be completely transparent to your program's users that you did so. Rails is entirely for the programmer's benefit.
Any or all of the "Getting Started" links here will show how straightforward Rails development is better than I can describe it, though.
posted by mendel at 7:03 PM on November 4, 2005
What you described is how a web program works. How web programming works is something like "You write a program that uses a database library and a templating library, you design your database schema, you manually manipulate the database in your program, you design templates that contain forms that reflect the data in your database..." and so on. Rails makes that easier to do.
As an example of "Don't Repeat Yourself": the standard Rails tutorial has you create a database schema, then run the command to create the program and template fragments to go with it -- and automatically you have a Web application that provides interfaces to read, update and create database records, complete with HTML forms and the glue code.
When you write a program in Rails, it will be completely transparent to your program's users that you did so. Rails is entirely for the programmer's benefit.
Any or all of the "Getting Started" links here will show how straightforward Rails development is better than I can describe it, though.
posted by mendel at 7:03 PM on November 4, 2005
AmbroseChapel: Handling the data before it's inserted into the db and after it's extracted from it... templates, control flow, etc. are usually stuff you go through upon connection depending on what user is logged in, what they're doing, what they just did... most programs end up building their own database models, perhaps template tags specific to those models, other stuff from scratch, Ruby just gives you a big jump of stuff (framework) to code your stuff on. And yeah, this is getting offtopic.
For the original poster, PHP is (really) easy, and great for the web, but it works for CLI stuff. If you want to learn to write scripts for the web at the same time automating Asterisk, go with PHP.
The main factor in your decision though, shouldn't be the language I think, it should be what language most other people are coding in for the same application, so you can reuse code and get help etc.
posted by Firas at 7:09 PM on November 4, 2005
For the original poster, PHP is (really) easy, and great for the web, but it works for CLI stuff. If you want to learn to write scripts for the web at the same time automating Asterisk, go with PHP.
The main factor in your decision though, shouldn't be the language I think, it should be what language most other people are coding in for the same application, so you can reuse code and get help etc.
posted by Firas at 7:09 PM on November 4, 2005
perl or python. perl because I love it, python because everyone else does :P
posted by devilsbrigade at 7:24 PM on November 4, 2005
posted by devilsbrigade at 7:24 PM on November 4, 2005
Python is nice because it lets you just get shit done; it lets you focus on whatever problem you're solving at the time and solve it well, without getting in your way. It also manages to do this without sacrificing any power or depth, to the point that the only thing people can really say against it is "I don't like the whitespace," which is just a tad superficial, don't you think?
I haven't used Perl much but I believe it has, if anything, even more community support and third-party modules than Python does (which is to say, a lot). Depending on your personality and style you may find Perl's complete and total lack of structure or form to be a good thing; or you may run away screaming the first time you try reading someone else's Perl code.
As others have pointed out, PHP is not only heavily Web-oriented and really not suitable for command-line scripts, but it's also less mature and generally more of a mess. So you can safely ignore it for your purposes.
posted by cyrusdogstar at 7:49 PM on November 4, 2005
I haven't used Perl much but I believe it has, if anything, even more community support and third-party modules than Python does (which is to say, a lot). Depending on your personality and style you may find Perl's complete and total lack of structure or form to be a good thing; or you may run away screaming the first time you try reading someone else's Perl code.
As others have pointed out, PHP is not only heavily Web-oriented and really not suitable for command-line scripts, but it's also less mature and generally more of a mess. So you can safely ignore it for your purposes.
posted by cyrusdogstar at 7:49 PM on November 4, 2005
Oh, and I take umbrage with the assertion that Python is not as suited for Unix as Perl is--it's equally so. Perl has just been entrenched in the Unix sysadmin's toolkit for longer due to its very glue-like nature and its string munging skills, but it is not any more or less Unix-y than Python.
And while Python has much stronger object oriented aspects than Perl (AFAIK), it certainly doesn't force you to--I've written many rambling single-file scripts in Python with nary a class or attribute in sight. Not that it's a good thing, mind you, but it's possible if you really like it =)
posted by cyrusdogstar at 7:52 PM on November 4, 2005
And while Python has much stronger object oriented aspects than Perl (AFAIK), it certainly doesn't force you to--I've written many rambling single-file scripts in Python with nary a class or attribute in sight. Not that it's a good thing, mind you, but it's possible if you really like it =)
posted by cyrusdogstar at 7:52 PM on November 4, 2005
which is just a tad superficial, don't you think?
I don't think it's superficial. Part of the programming process is reading and otherwise staring at your own (or others) code. If the experience of staring at your code starts to become a low-quality experience for you, you have a problem.
I've always liked the fact that Perl forces me to use braces with control structures. Some people could happily go brace-free for the rest of their lives. Maybe I could after I got used to it, though I suspect as I switched between languages, it would really bother me.
That said, I'd never scare someone off of Python just for that. It hasn't even totally scared me off. The whitespace issue is just personal preference.
posted by weston at 8:23 PM on November 4, 2005
I don't think it's superficial. Part of the programming process is reading and otherwise staring at your own (or others) code. If the experience of staring at your code starts to become a low-quality experience for you, you have a problem.
I've always liked the fact that Perl forces me to use braces with control structures. Some people could happily go brace-free for the rest of their lives. Maybe I could after I got used to it, though I suspect as I switched between languages, it would really bother me.
That said, I'd never scare someone off of Python just for that. It hasn't even totally scared me off. The whitespace issue is just personal preference.
posted by weston at 8:23 PM on November 4, 2005
The whitespace issue is just personal preference.
I guess that's mostly my point, it's not an objective plus/minus (then again, are there any truly objective items by which to judge these things?) but personal preference. Plus, everyone I know who is used to C-style syntax and then learned Python has at worst come to not be bothered by it, and most end up preferring it (myself included).
posted by cyrusdogstar at 8:36 PM on November 4, 2005
I guess that's mostly my point, it's not an objective plus/minus (then again, are there any truly objective items by which to judge these things?) but personal preference. Plus, everyone I know who is used to C-style syntax and then learned Python has at worst come to not be bothered by it, and most end up preferring it (myself included).
posted by cyrusdogstar at 8:36 PM on November 4, 2005
learn whatever the actual asterisk developers as well as the majority of people on the asterisk-dev mailing list are currently using for AGI -- will help you learn faster in this specialized environment and make it easier to steal^H^H^H^H^Hborrow code from others.
posted by dorian at 9:03 PM on November 4, 2005
posted by dorian at 9:03 PM on November 4, 2005
Just my $0.02 on the python/perl thing.
An early design goal of perl was to be familiar and easy to learn by unix sysadmins. As a result, perl is loaded with bits and pieces borrowed from Bourne shell, awk, sed, and C. The greatest strength is the massive community creating supporting libraries as a result of this familiarity. Perl's greatest weakness is that because of the redundant syntax and implicit variables, perl is easy to write but harder to read.
Python was designed to minimize the multiple idioms and implicit code involved in scripting. In python programming communities, there is a strong preference for the most "pythonic" idiom. It's greatest strength is structure and readability. However, many of the process and shell interactions are much more verbose than the perl or Bourne equivalent.
Beyond that, perl has larger volume of libraries and CPAN, python (for me) is more of a pleasure to program in. If you want string-mudging, both of them use perl-compatible regular expressions that do roughly the same thing. My suggestion is to pick the one that matches the culture you are working in. If you are scripting for yourself, pick the language that gives you the least headaches to read.
Personally, I have a strong preference against the implicit variables and punctuation soup of perl code.
posted by KirkJobSluder at 9:27 PM on November 4, 2005
An early design goal of perl was to be familiar and easy to learn by unix sysadmins. As a result, perl is loaded with bits and pieces borrowed from Bourne shell, awk, sed, and C. The greatest strength is the massive community creating supporting libraries as a result of this familiarity. Perl's greatest weakness is that because of the redundant syntax and implicit variables, perl is easy to write but harder to read.
Python was designed to minimize the multiple idioms and implicit code involved in scripting. In python programming communities, there is a strong preference for the most "pythonic" idiom. It's greatest strength is structure and readability. However, many of the process and shell interactions are much more verbose than the perl or Bourne equivalent.
Beyond that, perl has larger volume of libraries and CPAN, python (for me) is more of a pleasure to program in. If you want string-mudging, both of them use perl-compatible regular expressions that do roughly the same thing. My suggestion is to pick the one that matches the culture you are working in. If you are scripting for yourself, pick the language that gives you the least headaches to read.
Personally, I have a strong preference against the implicit variables and punctuation soup of perl code.
for line in sys.stdin.readlines(): tells me what stream, what method is used to read the stream, and where to find the data. while (<>){} is less pleasing. (Although perl -pi -e "s/foo/bar/;" is my preferred method for massive search and replace.)posted by KirkJobSluder at 9:27 PM on November 4, 2005
Oh, I should add that implicit variables for me is ok if you are talking about nesting functions:
however I don't care for the perl equivalent of
posted by KirkJobSluder at 9:59 PM on November 4, 2005
print(string.rstrip(line.replace("aaa","bbb")))however I don't care for the perl equivalent of
s/aaa/bbb/; chomp; print;. Just a personal preference.posted by KirkJobSluder at 9:59 PM on November 4, 2005
Python
Shortly, a bunch of people are going to pop up and tell you how horrid Perl is. Make sure to ignore them and form your own opinion.
so why bother with askme?
posted by andrew cooke at 4:41 AM on November 5, 2005
Shortly, a bunch of people are going to pop up and tell you how horrid Perl is. Make sure to ignore them and form your own opinion.
so why bother with askme?
posted by andrew cooke at 4:41 AM on November 5, 2005
I won't tell you how horrid Perl is. I'll just say that I find the design of the language and perl code ugly. It's got a huge community, though. If I cared about Perl I'd spend a lot time at PerlMonks. I admire the community even though I dislike the language.
As for the whitespace complaints about Python I just don't get it. It's just syntax. I haven't done a whole bunch of either Perl or Python programming but it seems to me that if the only thing you dislike about a language is syntax, then it's pretty simple (for some languages) to write a processor that translates to and from a more desirable syntax. Until someone comes along and tells me why it'd be difficult to write such a translator for Python I'll continue to be mystified by the syntax complaint.
posted by rdr at 5:20 AM on November 5, 2005
As for the whitespace complaints about Python I just don't get it. It's just syntax. I haven't done a whole bunch of either Perl or Python programming but it seems to me that if the only thing you dislike about a language is syntax, then it's pretty simple (for some languages) to write a processor that translates to and from a more desirable syntax. Until someone comes along and tells me why it'd be difficult to write such a translator for Python I'll continue to be mystified by the syntax complaint.
posted by rdr at 5:20 AM on November 5, 2005
The whitespace issue is fine if you're in one environment, but once you start, say, mailing code around, using different editors, etc... things are bound to get mangled.
Offhand, I can't think of a better way to introduce invisible logic errors than to make whitespace significant. Especially if you're editing code in any way through a browser window (hi, Zope!).
I've used python a fair amount, and it's not terrible other than that, although it does seem to give you an unusually large number of ways to blow your feet off without realizing it.
Separate from the hype, ruby has some aspects that I like. It's got a lot of constructs based around iterators, which I find very elegant, and it encourages clean code.
posted by Caviar at 5:49 AM on November 5, 2005
Offhand, I can't think of a better way to introduce invisible logic errors than to make whitespace significant. Especially if you're editing code in any way through a browser window (hi, Zope!).
I've used python a fair amount, and it's not terrible other than that, although it does seem to give you an unusually large number of ways to blow your feet off without realizing it.
Separate from the hype, ruby has some aspects that I like. It's got a lot of constructs based around iterators, which I find very elegant, and it encourages clean code.
posted by Caviar at 5:49 AM on November 5, 2005
Cavlar: It is just as easy to to introduce invisible logic errors with curly braces (or begin/end statements). From Sun's Java docs: "Misplaced curly braces are the most common cause of compilation errors. It is easy to lose track of which braces go with certain blocks of code, especially nested blocks that contain if/else statements or similar constructs."
The reason Python's block-by-indent works so well is that the programmer and the computer are both using the same cues for program structure. So any mangling (which I've never encountered) is instantly recognizable.
Just to keep things balanced ;)
posted by Popular Ethics at 6:57 AM on November 5, 2005
The reason Python's block-by-indent works so well is that the programmer and the computer are both using the same cues for program structure. So any mangling (which I've never encountered) is instantly recognizable.
Just to keep things balanced ;)
posted by Popular Ethics at 6:57 AM on November 5, 2005
Python's a good language to learn with. Probably better than Perl. You'll be able to do what you want with either.
The languages are temperamentally very different. Perl gives you enough rope to hang yourself (occasionally it's almost spewing rope at you.) Python tries to parcel out just enough rope to do what you want without leaving enough excess to make so much as an untidy knot, let alone trip you up. Sometimes I end up wanting a little more slack. Perl always gives you lots of slack. There are up-sides and down-sides to that.
I'm reading Programming Ruby now, and really like Ruby's looks so far, but haven't programmed in it, so I can't comment on it yet.
cyrusdogstar, I think majick just meant that if you're used to sed and awk and shell-scripting, Perl will feel more familiar than Python, not that Python somehow didn't get along with UNIX.
posted by Zed_Lopez at 7:37 AM on November 5, 2005
The languages are temperamentally very different. Perl gives you enough rope to hang yourself (occasionally it's almost spewing rope at you.) Python tries to parcel out just enough rope to do what you want without leaving enough excess to make so much as an untidy knot, let alone trip you up. Sometimes I end up wanting a little more slack. Perl always gives you lots of slack. There are up-sides and down-sides to that.
I'm reading Programming Ruby now, and really like Ruby's looks so far, but haven't programmed in it, so I can't comment on it yet.
cyrusdogstar, I think majick just meant that if you're used to sed and awk and shell-scripting, Perl will feel more familiar than Python, not that Python somehow didn't get along with UNIX.
posted by Zed_Lopez at 7:37 AM on November 5, 2005
I'm picking up some Python as I'm picking up some Django (a web development framework for Python).
I'm impressed at Python's range. It can be used to create something fairly complicated, like Django, while also being used to "script" Django in a manner that doesn't require much knowledge of the depths of python. At the same time, I'm free to used advanced python concepts in my Django apps as I learn them.
posted by Good Brain at 8:55 AM on November 5, 2005
I'm impressed at Python's range. It can be used to create something fairly complicated, like Django, while also being used to "script" Django in a manner that doesn't require much knowledge of the depths of python. At the same time, I'm free to used advanced python concepts in my Django apps as I learn them.
posted by Good Brain at 8:55 AM on November 5, 2005
Python is very easy to start out with and pick up very quickly. It is one of the best languages for "getting things done fast", and as a full-featured language it is very competent. I would suggest starting here if you do not have any real background in scripting languages.
Perl is my personal choice, however. It has a very long history, excellent documentation, superb user support communities, and the largest archive of existing library support routines you will ever find - CPAN. Perl would be about 10 times less useful if it were not for CPAN, because no matter what kind of algorithm, data structure, file format, support routine, etc. you are looking for, it's probably already been implemented for you on CPAN (for free.)
A lot of people give perl a bad time because it's possible to write extremely ugly / hairy / unmaintainable code with it. This is a true criticism, but it doesn't mean that you have to fall into this trap. It is very easy to write completely structured perl that doesn't resemble line noise in the least. But a lot of the existing perl scripts that people run into do tend to the side of looking incomprehensible, so a lot of people assume that perl has to look that way, which is not true.
posted by Rhomboid at 9:10 AM on November 5, 2005
Perl is my personal choice, however. It has a very long history, excellent documentation, superb user support communities, and the largest archive of existing library support routines you will ever find - CPAN. Perl would be about 10 times less useful if it were not for CPAN, because no matter what kind of algorithm, data structure, file format, support routine, etc. you are looking for, it's probably already been implemented for you on CPAN (for free.)
A lot of people give perl a bad time because it's possible to write extremely ugly / hairy / unmaintainable code with it. This is a true criticism, but it doesn't mean that you have to fall into this trap. It is very easy to write completely structured perl that doesn't resemble line noise in the least. But a lot of the existing perl scripts that people run into do tend to the side of looking incomprehensible, so a lot of people assume that perl has to look that way, which is not true.
posted by Rhomboid at 9:10 AM on November 5, 2005
Perl is an excellent general purpose programming language, suitable for everything from simple scripting of most OS environments to full-blown application software development.
In addition to this, there exists a huge corpus of modules that to the things that you need done (CPAN, the Comprehensive Perl Archive Network), and it's pretty easy to find out if what you need already exists, so you don't have to re-invent. CPAN is pretty easy to use, and will build, test, and install a module and all its dependencies with a single command.
posted by jimfl at 10:50 AM on November 5, 2005
In addition to this, there exists a huge corpus of modules that to the things that you need done (CPAN, the Comprehensive Perl Archive Network), and it's pretty easy to find out if what you need already exists, so you don't have to re-invent. CPAN is pretty easy to use, and will build, test, and install a module and all its dependencies with a single command.
posted by jimfl at 10:50 AM on November 5, 2005
Zed: Nice :)
I'd say Python. The reason for that is mostly stylistic. I like the syntax of Python and the features it offers.
One of those features is list comprehension. This lets you apply a function to each element of a list, like so:
[x+10 for x in range(10)]
would yield:
[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
This adds 10 to every number from 0-9. range(10) alone would return a list of integers from 0 to 9.
It's this and the other functional-programming aspects of Python that give it a plus for me.
posted by formless at 2:29 PM on November 5, 2005
I'd say Python. The reason for that is mostly stylistic. I like the syntax of Python and the features it offers.
One of those features is list comprehension. This lets you apply a function to each element of a list, like so:
[x+10 for x in range(10)]
would yield:
[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
This adds 10 to every number from 0-9. range(10) alone would return a list of integers from 0 to 9.
It's this and the other functional-programming aspects of Python that give it a plus for me.
posted by formless at 2:29 PM on November 5, 2005
Perl is fantastically concise and powerful if you are already a good programmer. But its flexibility lets bad programmers get away with never learning better practices.
Anyway, for your purposes, there appear to be AGI bindings or interfaces for Perl, Python, and Ruby, so you might just look into which is most complete and mature.
AmbroseChapel: just to clarify what "Ruby on Rails" means, 'cause I don't think you got a clear answer: "Ruby" is a programming language, like Perl or Python. "Rails" is a set of libraries and utility programs that provide a programming framework for developing Web applications; that is, they do the things that a Web-application programmer must often do in a standard and easily-invoked manner. There are equivalent frameworks in the Perl world, such as Maypole and Catalyst.
A few of the things these frameworks automate for you:
- high-level request processing, by letting you define handlers for specific URL patterns rather than coding up the URL dispatching yourself
- HTML generation, by parsing embedded logic in templates
- authentication and session management, by mapping browser cookies to cached session data
- "AJAX" XMLHttpRequest->DHTML callbacks, by deploying the Prototype Javascript library
Hope this helps...
posted by nicwolff at 2:37 PM on November 5, 2005
Anyway, for your purposes, there appear to be AGI bindings or interfaces for Perl, Python, and Ruby, so you might just look into which is most complete and mature.
AmbroseChapel: just to clarify what "Ruby on Rails" means, 'cause I don't think you got a clear answer: "Ruby" is a programming language, like Perl or Python. "Rails" is a set of libraries and utility programs that provide a programming framework for developing Web applications; that is, they do the things that a Web-application programmer must often do in a standard and easily-invoked manner. There are equivalent frameworks in the Perl world, such as Maypole and Catalyst.
A few of the things these frameworks automate for you:
- high-level request processing, by letting you define handlers for specific URL patterns rather than coding up the URL dispatching yourself
- HTML generation, by parsing embedded logic in templates
- authentication and session management, by mapping browser cookies to cached session data
- "AJAX" XMLHttpRequest->DHTML callbacks, by deploying the Prototype Javascript library
Hope this helps...
posted by nicwolff at 2:37 PM on November 5, 2005
Python, though I do wish there was something like CPAN for it.
One thing that surprised me about Perl and Ruby after using Python is that they didn't have real command-lines. If you type python at a command line, you get an interactive command prompt with built-in help and all that jazz; in Perl and Ruby, you just got a blank area to type in and nothing executes until you quit.
posted by boaz at 4:57 PM on November 5, 2005
One thing that surprised me about Perl and Ruby after using Python is that they didn't have real command-lines. If you type python at a command line, you get an interactive command prompt with built-in help and all that jazz; in Perl and Ruby, you just got a blank area to type in and nothing executes until you quit.
posted by boaz at 4:57 PM on November 5, 2005
Cool, I'll have to check that out. I found python's interactive shell invaluable when I was learning.
posted by boaz at 7:45 PM on November 5, 2005
posted by boaz at 7:45 PM on November 5, 2005
Perl has a shell, try "perl -d -e 1" some time. If that's not enough try psh.
posted by Rhomboid at 9:35 PM on November 5, 2005
posted by Rhomboid at 9:35 PM on November 5, 2005
Popular Ethics wrote "Misplaced curly braces are the most common cause of compilation errors.
Compilation errors are NOT the same as invisible logic errors. Compilation errors are a nuisance, but the compiler will find them and tell you you've done something wrong because things don't line up. Invisible logic errors are just that - you have no idea that something's wrong until you run the program and it doesn't behave the right way. If your tests don't happen to check for proper behavior in the weird boundary condition you've inadvertently created by botching the indentation somewhere, you're just screwed. And if you think your testing is catching all of your errors, you're probably doubly screwed.
posted by Caviar at 3:32 PM on November 27, 2005
Compilation errors are NOT the same as invisible logic errors. Compilation errors are a nuisance, but the compiler will find them and tell you you've done something wrong because things don't line up. Invisible logic errors are just that - you have no idea that something's wrong until you run the program and it doesn't behave the right way. If your tests don't happen to check for proper behavior in the weird boundary condition you've inadvertently created by botching the indentation somewhere, you're just screwed. And if you think your testing is catching all of your errors, you're probably doubly screwed.
posted by Caviar at 3:32 PM on November 27, 2005
This thread is closed to new comments.
PHP, however, shouldn't even be touched with someone else's dick in a drunken blackout.
posted by cmonkey at 6:16 PM on November 4, 2005