Slashdot Mirror
The Year in Scripting Languages
Mitchell writes "People from several language communities came together to create a
joint year-in-review
for Lua, Perl, Python, Ruby, and Tcl."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
The reason is simple: I need to use several non-scripting languages (Java, Smalltalk, etc.) and remembering the language syntax and class libraries for more than 4 or 5 programming languages is a hassle.
BTW, scripting languages are not necessarily horribly inefficient anymore.
A little off topic, but I compared the resources used for a small web app on the following platforms:
- Java servlets/JSPs - minimum memory footprint is about 75 megabytes
- Smalltalk servlets - mimimum memory footprint is about 20 megabytes
- Python Zope - minimum memory foortprint is about 11 megabytes
In all three cases, the server processes use negligible CPU time after startup (mostly waiting with select).Anyway, for lots of applications, Python is fast enough - no need for high performance compilers like Common Lisp, C++, Smalltalk, etc.
-Mark
Incorrect. CMD/Batch scripting is still alive and well, and much more powerful in its cmd.exe "cmd scripting" form than it ever was in the DOS "batch scripting" days. Batch/CMD is to sh as WSH is to perl (especially since you can use perl to write WSH code -- WSH is not a language, but a framework that can support many languages).
BTW, PHP news is available in RDF format as a Slashbox. Go to your Slashdot "preferences" to add.
As for Language wars, no language is better, it's just a better tool for a particular job.
Perl Data Language (http://pdl.perl.org) is a set of C and FORTRAN bindings that make perl into a complete vectorized scientific-computing language that's useful for big tasks like inverting 1000x1000 matrices or fluid-dynamic simulation, but that can also be used interactively to work with image and spectral data.
That's neat because interactive data analysis is a pretty small niche market with a few proprietary (and, IMHO, seriously broken) languages dominating. With PDL, I can give fresh science data to high school students, straight from the spacecraft. Their L337 gaming machines are plenty powerful enough to run the tools they need, and perl is pretty much universal.
I think you should use PHP before really forming any opinions. HTML is a markup language, whereas things like PHP and Perl are scripting languages. There is nothing really similar in the least. Perl can output HTML just like PHP can.
:-)
I prefer PHP as a scripting language for many tasks, including anything involving database access. People have written complex socket applications in PHP such as HTTP servers and HTTP proxies, simple sysadmin utilities, and everything in between. In fact, many C programmers seem to prefer PHP as a scripting language due to its C-like syntax and clean design.
PHP and Perl are equivalent in my mind in terms of what can be accomplished. If you are comfortable with the syntax of one, there is no pressing need to learn the other. If you need a shell script, PHP and Perl both work. If you are developing for the Web, PHP and mod_perl do the job. PHP is not limited to Apache, however, which is one of the many reasons it has been more widely adopted in the Web development community.
I have found that those who think PHP is only useful for Web application development are the same people who think Perl is only useful for shell scripting. See if the mod_perl community agrees with that.
TCLs claim to fame is its small memory use. TCL can be included as a command interpreter in other programs easily and without much bloat. There are more embedded TCL applications than any one person knows about; both in hardware and software. TCL was also first with UTF-8 support in strings, around 1998 or before, way before Perl, so there are probably more TCL CGI scripts overseas than most English users think.
As for benchmarks, TCL is getting faster, with a huge jump from v7 to v8 and about a 25% improvement from 8.0 to 8.4a3 (scroll down to bottom of linked page.)
> PHP isn't really a scripting language in the same
/usr/local/bin/php
> sense that those others are.
Actually, it is.
#!
Since most of this is about your experience there is not much anyone else can say but...
After about a day I had an excellent understanding of both PHP and SQL.
I don't know PHP but you don't have an excellent understanding of SQL in one day. Its not a that hard but ain't that easy either. Rather what is probably true is that you have an excellent understanding of how to write SQL to get information from the types of simple database with simple underlying business rules.
The modern SQL spec runs 2000 pages you don't have an excellent understanding of 2% of that in one day.
This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers.
I don't know what you are talking about. If X is a type of object then X's are passed around as pointers (see bless). Arrays in Perl are linked lists so an array of X's is a linked list, that's why you use things like push, pop, shift, etc... on arrays in Perl.
As for graphics Perl libraries support a wide range of graphics formats.
There are some other things like your comments about the regex engine that I highly doubt. No regex engine has had the time, attention and work of Perl's, Its not Perl's strong suit because of some sort of myth, for example Perl's grep has outperformed the native grep on Solaris. My guess is that the failure lies with you on this one.
As a C programmer myself, I think it is pretty evident that you are not. That's not meant to be offensive, but you should not attempt to speak from inexperience as a general rule. Try to be more open minded, or at least only form an opinion after you have educated yourself on a particular topic.
:-)
:-)
For example, after your attempt to say that PHP only slightly resembles C, you try to point out weaknesses in PHP by mentioning functions that are direct equivalents of C functions (strlen, strchr, sprintf, etc.). Make up your mind.
Also, since it seems you suggest otherwise, there is a good reason why not every string manipulating function begins with str_. Do you think C should have used str_printf() and str_sprintf()? How about PHP's functions crypt(), echo(), explode(), md5(), trim(), soundex(), etc. Should these all be renamed? Bill Gates may agree with you, but I doubt you will find many open source developers who do.
In case it is helpful, strchr() and split() do not do the same thing. It sounds like you're heading for trouble there.
I guess my point is that your inexperience is not a valid complaint against PHP. Yes, it is not the perfect language, but it happens to work well for a lot of people. If you want to bash it, at least use valid reasons (which there are plenty) such as how mod_php is a content generation module and therefore unable to interact with other request phases within Apache (though I think this is being remedied in the apache_hooks API). Or, point to a benchmark showing how Perl parses large text files 20% faster in some cases. Or, show how Python's OO model is more advanced.
Sorry if this post comes off a bit strong, but I tire of seeing hollow rhetoric.
PHP is half baked and frequently doesn't work as documented.
Although K really isn't a scripting langauge (neither is C), results were done for it, too (being faster and having less code). There is also a shallow introduction to K on Kuro5hin.org.
It's also good to see newer scripting languages like Ferite progressing as well.
Parrot isn't the VM for Perl6. Parrot is a "new language from the creators of Perl and Python." Duh. There's even an O'Reilly book on it.
:/
Seriously though. They barely mentioned Parrot and Parrot is coming along very nicely I think. Even with a Java to Parrot Bytecode program, Brainfuck, Jako, Befunge-93, cola, forth, miniperl, ook, (non-final) perl6 interpreters/compilers, as well as python, ruby and scheme interpreters/compilers coming. Of course it's not finished, so not all of the languages are either, but hey, it's getting there, and damn fast. There's even a Parrot Assembly Lange.
Parrot is definately not Perl6. It's much more. It's like java, but open source, and independent of Languages. They're hoping to have it compile on as many platforms as perl does now, unlike Java which is Windows, Mac, Linux, and some PDAs, end of story.
So everyone check it out and throw some patches in too! Of course, the only support I've given so far is moral support.
The real missing item is VBScript. Sure, it's 99% Windoze (1% Macintosh -- who probably don't realize they have it). It's the engine behind ASP -- which isn't a language in its own right. It's the replacement for DOS Shell scripts/batch files. It's the preferred platform for management scripts on Win2K/WinXP (see WMI) It's the preferred platform for trojan horse programs... maybe I shouldn't claim that as a positive, huh? Probably Javascript should have been mentioned too, but it's rarely used as shell-style scripting. Why do I use VBScript when I've got Perl and Python on the same machine? Frobbable code at Microsoft's website. If nothing else, I prototype it there, then acces the same COM objects through Python or Perl.
Design for Use, not Construction!
-- Don't Tase me, bro!
Here are a few reasons why someone would want to use Tcl:
... while', you could write it in Tcl itself.
1) Its implementation is beautiful. The C code is some of the cleanest and most pleasant that I've ever had the pleasure to read.
2) The language itself is quite comprehensible, even to beginners. Python is maybe a tad easier, but Tcl is certainly not tough to pick up.
3) You can write control structures *in* Tcl. For example, even though the language doesn't have 'do
4) Lots of neat stuff in the implementation, like the event loop.
5) It's extremely easy to embed and extend. It makes it incredibly easy to make your application scriptable. Also, it's not that big (although larger than Lua, for sure), so it won't bloat your app too much.
http://www.welton.it/davidw/
Well, my big project was started before Tcl/Tk had a text widget, and I think before NCSA Mosaic was written, but yes, Tcl is what I use for anything new that needs a GUI or is otherwise beyond the capabilities of a short Bourne-shell script.
(The main thing I've written is an editor, which you can find along with a bunch of other stuff here. Please don't judge Tcl based on what I do with it in my spare time, though; there are loads of better-maintained and more ambitious Tcl projects out there.)
Well, the thing I like about Tcl is it's utterly fanatical self-consistency and simplicity. It's about the diametric opposite of Perl (especially pre-Perl5 Perl. Larry Wall wrote "I wanted Perl to work smoothly in the way that natural languages work smoothly, not in the way that mathematics works smoothly." Tcl works smoothly in the way that mathematics works smoothly. It's a very small, very consistent language, and that means you can keep all of it in your head even as a casual user. It's learning curve comes mainly from being simpler than other languages a new Tcl programmer may be familiar with. Yes, that means you can't write DeCSS in half a line of punctuation characters the way you can with some languages
Honestly, asking why you can't increment a variable by appending ++ to it in Tcl is like asking why you can't indicate the object of a verb by changing a final -us to -um in English instead of having to put the words in a particular order, or why you can't "use Getopt::Std;" in Lisp, or why you can't just push the button for the right floor in a car the way you can in an elevator.
Tcl and Perl are both excellent languages, but they appeal to very different kinds of people. (I haven't used it much, but from what I've seen Python is somewhere in the middle - a lot of Tcl's consistency, but also a lot of syntax compared to Tcl, which lets you express things somewhat more tersely.)
Tcl is also great at introspection, which makes it easy to write code that manipulates code.
Tcl was originally designed as an embedded extension language, to be added on to applications in $COMPILED_LANGUAGE to provide scriptability - it was originally targetted to replace things like sendmail.cf,
I actually wish that Tcl had had more success in its original intended niche; since it's a pain to have to learn a new incomplete and clunky mini-language with every new application you want to configure or script - and then not have them be able to talk to each other. If Guile or whatever becomes a bit more ubiquitous for that purpose I'll learn it and be content, I suppose, but I guess everybody who writes a new app wants to write a new language to go along with it rather than steal somebody else's.
"Lua" is Portuguese for "Moon". Lua is a Brazilian project.
Prescriptive grammar:linguistics
It even got a mention on Slashdot.