IMHO, the interpreted vs. compiled debate is so blurry at this point that we should probably all just shut up about it. There are still a few purely-interpreted languages (*nix shells), and a few purely-compiled languages (C/C++, though you can get a interpreter if you really want to). But then you have this massive grey area of Perl, Java, and Python, where there is a compiler that creates bytecode and that bytecode is interperted to machine instructions. Sometimes the compiler and interpeter are in the same binary (Perl) and sometimes they're seperate (Java), but it's ultimately the same thing. For that matter, even C compilers often translate the code to an intermediate langauge before outputting the executable.

So I don't see a justification for continuing this debate anymore. The distinction between the two sides is already blured, and projects like the .NET CLR and Parrot are continuing this trend.

For that matter, even C compilers often translate the code to an intermediate langauge before outputting the executable.

Yes, but for completely different reasons. C compilers do that to avoid the N*M problem, that is, having to compile N languages on M platforms. Without an intermediate language, one would have to write N*M compilers - with an intermediate language, one only needs to write N + M compilers.

It doesn't interpret the intermediate language - by the time runtime starts, the intermediate language is gone.

Abigail

The Java people will tell you (rightly or wrongly) that Java compiles to bytecode so that it's cross-platform. Which is still an effort to solve an N*M problem. There are other benefits to this, too (such as runtime optimization via JIT), but for the Java commmunity, at least, the primary goal seems to be cross-platform support. The difference between that and gcc's IL is when the compile to machine code is done.

Also, some compilers (like the gcc suite) support many languages, so we have to add another term to the equation: L*N*M, where L is the number of languages you want to support. Which just makes the use of an internal IL that much more important. Ignore that bit. Misread Abigail-II's post.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

We know this. JScript developers know this. Managers don't. And, it affects us in at least one way - we scripters are held to much lower standards of quality ("Oh, it's just a script") and higher standards of output ("Oh, it's just a script").

I don't write scripts - I write application frameworks. I just happen to use a language that once was a scripting language.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

I would agree with what you say except that I know there's an incorrect and harmful prevailing attitude out there that "scripting" languages are in some way inferior, because they don't create "real" programs. Honestly, I don't think we'll get the C/C++ people to stop looking crosseyed at us until we have an optimizing compiler that produces platform-specific native binaries, and I don't think a bundlemonkey approach (binding the interpreter and the bytecode together into an executable package) will do the trick. It's stupid, something that's only needed because of misconceptions that people have, but I'm pretty sure it's necessary, politically, for at least one major VHLL to have this before we'll be able to finally do away with the whole issue.

---

;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

Whichever VHLL does this will lack eval, which will make it distinctly less HL...

With scripts, you can see what you are getting. And as processor speeds increase, the delay caused by script compiling is becoming negligible.

I do not trust any Microsoft code anymore. I am becoming increasingly suspicious of linux binary rpms, especially from distributions with alot of "corporate ties", or whose primary goal is to make money.

With scripts, you can see what you are getting.

You haven't been looking at the obfu section of this site much lately, have you? :)

Seriously, given that perl offers run-time eval and a very powerful regex language with side-effects, you have to have just about the same amount of trust in the person that hands you 1000 lines of perl code as you need in 100k of executable.

Either one could do totally unexpected things without you being able to tell by inspection.

I'm not saying "scripting languages bad"; what I am saying is that the source being in front of you doesn't mean much.

And as processor speeds increase, the delay caused by script compiling is becoming negligible.

There are many areas where that's just not true. A lot of programming problems have time constraints, where if the answer is late it's just about worthless. And those constraints often get tighter just as fast as processor speeds increase.


Mike

You haven't been looking at the obfu section of this site much lately, have you? :)

Try perltidy sometime ... Similar tools exist for all major scripting languages.

Additionally, I can do something with scripting tools I cannot do for any other language - look at how the add-ons I want to use are built ... should I care. I read Text::xSV and File::Temp. I don't read CGI or DBI. Why? I don't care about how the latter are implemented. I care very much how the former are. (Or, I have cared ... I might care about CGI at some future date.) Later, I might care how various rpms are put together, for which I can find the source code.

The point here is that with a minimally sufficient effort, I can learn how CGI is put together, with or without crazy Perl stuff. Without reverse engineering, I cannot do the same with similar tools in a compiled setting.

A better example might be that I can learn exactly how Mozilla is put together ... I can't do the same with IE. I probably never will ... but I can. Transparency doesn't have to be used to be effective.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Reading the linked post, it strikes me that much of the time he talks about "Script" as if it's a coherent and tangible thing. He describes the properties of "Script" in terms that are too precise and specific. For example, he says "the script engines are bytecode-interpreted languages." Obviously this is not true of every langauge that could ever be called a "scripting language."

At first I thought he was simply overgeneralizing, but as I read I began to think perhaps he's talking about a very specific platform. I think he's talking about some MS "Script" subsystem. Maybe this is obvious to some people who have some idea of the context of this post, but for me it was a realization I came to slowly.

If this is indeed the case, then many (if not most) of the points he brings up are simply not useful for any other platform, much less scripting languages in general. This leads me to wonder what the point was of posting this link to a Perl site, except perhaps to spawn a similar discussion. If that was the intention, it's not particularly clear to me.

Correct -- I spent five years working on the Windows Scripting family of technologies -- when I say "script" in my blog, I'm talking about VBScript and JScript and that's about it. I have no idea what the relevance is to perl, or why someone would post it here. I've never written anything more complex than "hello world" in perl. ActiveState did produce a version of perl that supports the Windows Script interfaces, but I know very, very little about it.

Well we certainly are glad you stopped by. Whats the relevence to perl? Well perl is one of the latest in a long and noble line of scripting languages, and is probably one of the most seriously used. We are as a group fairly interested in scripting languages as a whole, and while our thoughts about the ones you mention are probably on the whole less than positive we are sympathetic and well used to discussing the differences between scripting languages and compiled languages etc. O'Reiley wrote an article once about post modern languages, and how he considers things like Perl and Ruby to be of this class that perhaps you may find interesting.

Again, as a group we have considerable knowledge and expertise in many scripting languages and platforms. If your area of interest is Scripting languages then maybe you should aquaint yourself better with Perl. We'd be sure to help you out and would welcome you to the community. C'mon, sign up, have fun, laugh, write an Acme:: module, become familiar with the best supported widest used most portable scripting language there is.

And yes I stand by that last sentence. Show me a scripting language with the power of CPAN at your fingertips and I might consider otherwise. :-)

Regarding "hello world"...

perl -e "print 'hello world'"
[download]

Maybe you aught to dig a little deeper. You may find its addictive though :-)



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

"a script is what you give the actors. A program is what you give the audience."

However, even within the Perl community, scripts seem to have pejorative karma, compared to, say, modules. A module is a complete entity bundled with collateral - documentation and tests.

In many module kits, the scripts supplied are "example scripts", and are not even considered deliverables. But, what do people actually run? Answer: scripts. Even a module like CPAN.pm has a thinly disguised script - disguised in a sub called shell.

My $0.02 fwiw
rinceWind

he's not a fan of Perl at all, with good reasons.

I suppose I should just read the linked material, but what are these good reasons? Do you agree they are good?

I looked... he doesn't mention perl at all... must have been another blog entry.

Eric again. Though it is true that I'm not a big fan of Perl, I've also got nothing against it. Like everyone else, I'll joke occasionally about Perl (Perl: it's great because its got built-in obfuscation! Perl: it's the only language with the same information density as line noise!) but hey, if you guys find it floats your boats, more power to you.

What I'm confused about is the "good reasons" part. I don't _think_ I've ever written anything about perl that had any kind of reasoning in it. Cheap shots, like the above, yes. Reasoning, no. I'm just wondering what you're referring to.

I have a lot of respect for you that you came and said this. ++ to you.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

What was unintentionally omitted in an edit was ", with good reasons I suppose." (belatedly edited to reflect that) There are a lot of reasons to dislike Perl (and I agree with a lot of them!) and since you seem to be a fairly clueful language guy, I assume that you'd have at least taken a glimpse at Perl at one point.

For example, they say that Java is compiled. What a crap, the .class file is just bytecode.

They also say that a binary/executable is compiled. What a crap again, your OS and CPU will need to interpret that.

I think that in this days people want things done, no matter what way you use to do that. We don't care anymore what funny or "enterprise" way you use to do things. From the point of view of bussines/companies, they want things that work, and that are done fast and cheap. And they are right, since they are who pay the programmers.