|
Why do we need scripting langauges?
First, please don't mistake the title as a slam against scripting languages. I'm not so much trying to justify the use or definition of a language, I'm looking for an answer to a something I have been scratching my head over for a while. I'm wondering why, with .Net and its associated languages, do we need "scripting languages?" The question comes from this article:
http://www.oreillynet.com/lpt/a/4396
In the article, the writer is pontificating (I say that, because it sounds better than "ruminating") the future of VBScript. He says, "At this point, it is hard to tell what will become of VBScript. Microsoft did not provide native support for VBScript within the .NET Framework, choosing to support JScript instead. And there are already rumors flying that in the next major release of Windows, codename Longhorn, there will be a new Microsoft Shell (MSH) that will include a new scripting language. If that happens, more than likely VBScript will start to fade away."
As Just Another Perl Hacker, who likes VB6 and VBScript for quick Windows projects -- as much as I like Perl/Tk, a VB6 app looks and runs nicer -- I've been halfway mourning the possible demise(1) of what I consider a rather nice language(2). However, during the holiday, I've been reading through a C# book, and am absolutely floored by two things:
1. How simple C# is to pick up. Its syntax reminds me of a mish-mash between Java/JavaScript and Visual Basic, which is kind of welcoming for a newbie.
2. How powerful C# is as a language. System.IO, System.Net, and System.Xml alone are amazing simply to read about. I cannot wait until I have time to sit down and write a simple application with them.
Seeing the ease and power of C#, I am left wondering why anyone would need to limit themselves to a "scripting language?" If you have a language, such as C#, that can tie is so well with the operating system, why does Microsoft think it needs to create a "scripting language?" Is "scripting language" something psychological or does it have something to do with marketing? What am I missing?
I apologize if my question is vague, but I can't really pin it down much more than that without starting to sound like I'm insulting one language in favour of another.
---
1. I know we'll still be seeing VB6 programs for 10 or 20 years, just like Win32 stuff. However, I'm thinking mostly in terms of languages for system tasks, much like Perl, VBScript, and "scripting languages" were created for.
2. Perhaps I have simply not gotten deep enough in either VB6 or VBScript, but I generally think of them as the same language when I'm working or trying to solve a problem.
Andrew Burton
Monday, December 29, 2003
My take:
Scripting languages exist:
-To solve a specific kind of problem
-To be limited and therefore more easily approachable.
The same things that you find exciting about C# in expanded functionality might be daunting and, frankly, just noise to someone who isn't much of a developer but needs to get a task done.
VBScript is, in my opinion, a bad example of a scripting language -- it tries to be too general purpose. However, you mention that you like perl. Perl, by and large, exists to process text files. If you want to process a text file, perl has functionality in it that C# may not have built-in. If you reached for C#, the program would probably be longer than the perl equivalent. The barrier of entry for perl is much lower than C# (comparing what you need installed to run and develop).
You can't solve every problem with perl. However, if you need to mess with text files and you don't want to put a lot of thought into it or don't have a lot of time to learn programming, perl's the answer.
I've seen perl referred to as a "write-only" language. I think there's a lot of truth in that. Building on that, you need a scripting language when you have a "write-only" task -- something that you'll write and forget about.
Mark Smith
Monday, December 29, 2003
I make use of VBScript as an embedded language in my software. (Using the ScriptControl). I think many other software products do the same.
Dave B.
Monday, December 29, 2003
Mark: You said, "If you reached for C#, the program would probably be longer than the perl equivalent." I hadn't thought about it like that, really. I've been trying to train myself, with my Perl stuff, to make the code look neat for later use and revisions, and I forget that the beauty of a "scripting language" are things like one-liners and the kinds of things that most Perl hackers get grief over. Thanks!
Dave: May I ask what kind of software you write? I've never heard of ScriptControl before.
Andrew Burton
Monday, December 29, 2003
You've got to remember that VB script came out a long time before .NET. Plenty of people were complaining about the inflexibility and inadequacy of the command prompt and so Ms decided to create a scripting language. Basing it on VB6 was perfectly reasonable.
What you must remember is that programs that used VB needed the appropriate runtime on the host machine. The run times varied depending on what version of VB you wrote your program in, so, in order to allow lean scripts with no additional downloads you had the Windows scritping host installed as standard on all machines ( and more controversially, run at start up by default). It also allowed you to run Java script.
Stephen Jones
Monday, December 29, 2003
Maybe it's more a question of dynamic vs statis typing. You can run jython in the jvm or jscript in the clr etc...
fool for python
Monday, December 29, 2003
Basically the script control allows you to embed either VBScript or JScript in your VB or C++ programs. It saves a ton of work because you don't have to write your own scripting or "macro" language.
I use it to allow end users to enter their own code to define and calculate "rates".
Most end users can handle very simple VBScript (Rate = This + That * 6.3) because it's often used in MS-Office Applications (Excel, etc.). In fact most don't even know that they are using VBScript. I believe the control supports JScript too, but IMO JScript isn't as straightforward as VBScript.
http://www.microsoft.com/downloads/details.aspx?FamilyID=d7e31492-2595-49e6-8c02-1426fec693ac&DisplayLang=en
I think scripting in this manner is very important and definately useful. I have a game programming magazine that has an article about how to build native C++ scripting into a game. I can see where scripting would be very useful in a game to implement an AI.
Of course scripting in almost any enviroment can save time and make your application more flexible and the easier you can implement the script the more time you save.
Dave B.
Monday, December 29, 2003
If JScript.NET does everything that C#.NET does then the transition from VBScript to JScript might be an easier one.
Groovy - a scripting language for the JVM - created a wave of hype in the Java world in the last few weeks. I haven't tried it out, but it certainly looks appealing - Groovy code should generally be less-verbose than the equivalent Java code (it compiles to Java bytecode) and could be appropriate in a lot of places (e.g. writing Servlet controllers, unit tests, providing a scripting language for users, etc).
Walter Rumsby
Monday, December 29, 2003
C# is not cross-platform (sorry Mono, etc.. don't count).
Perl, Python, and Tcl are cross-platform.
Nick
Monday, December 29, 2003
Following on from the use of ScriptControl.. In an earlier app we wanted for ourselves and other to be able to write reports really simply... (and didn't want to expend too much effort creating a reporting subsystem).. so we used the scriptcontrol.
The user scripts could then call functions within the app to do queries etc. and write an HTML string (excellent for formatting tables of info. in a real simple way) as an output which, when the script ended, would be passed back to the app which then opened it in a browser window...
So we got a customisable report writer, viewer and print mechanism whilst hardly having to do anything in the app.
Gwyn
Monday, December 29, 2003
Any laguage is cross platform to the extent that the runtime is cross platform. Is this really a binary vs vm issue? I think we're beyond that. I really think the question is that given a vm, why would anyone use a scripting language over any other language. Again, it comes down to how you define a scripting language. In the end, I believe that it's a dynamic vs static typing issue. The vm and where it does or doesn't run has already been decided, now what will be most prodcutive language given the requirements?
Take a look at www.jython.org. It's python implemented in java. You can multiple inherit from python classes and single inherit from java classes as you would expect. All java classes are available interactively on the command line. Too far cool. Yes, it's slower than java, but as they say using <insert faveorite statically typed language> is prematrue optimization.
fool for python
Tuesday, December 30, 2003
Portability and weak typing are good points but as long as you don't need those, I agree with the original poster that easy-to-use all-purpose languages like C# and Java have made dedicated scripting languages practically obsolete.
When I need to manipulate some files I don't use Python or .BAT files, I just write a little C# program because that's what I'm most comfortable with, and the difference in size and complexity is so small as to be negligible.
For .NET specifically, there's Alintex Script ( http://www.alintex.com/ ), a free tool that automatically compiles C#/VB.NET programs with certain extensions when you attempt to execute them. The result is that you can run C# programs from the command line without explicit compilation like you would run Python scripts.
Chris Nahr
Tuesday, December 30, 2003
---"When I need to manipulate some files I don't use Python or .BAT files, I just write a little C# program because that's what I'm most comfortable with"---
That's because you know C# For the average sysadmin things are different.
And of course you can nly use C# for computers that have the .Net CLR.
Stephen Jones
Tuesday, December 30, 2003
"That's because you know C# For the average sysadmin things are different."
Why don't Windows sysadmins learn C#? That was actually curious about. What was the lure of VBScript over something like C#? And I've been given great feedback. :)
Andrew Burton
Tuesday, December 30, 2003
Stephen -- system administrators who only know some scripting languages are a special case. I was thinking of programmers who, so far, had to master both a "real" programming language for their applications (C++, Fortran, COBOL) and one or more scripting languages for file system or website management (Perl, JScript, csh scripts).
Why this distinction? It's because the languages that you could write applications in were relatively cumbersome, error-prone, required a slow compilation pass before you could run the program, and lacked features that would come in handy for scripting tasks (e.g. regular expressions or manipulating file attributes). On the other hand, scripting languages executed too slowly, were too unstructured, or otherwise too restricted for applications.
With application languages like C# and Java, this is no longer true. And then there's Python, a "scripting" language powerful enough to write entire applications in. (It was a bad idea to oppose C# and Python in my original post, that obscured the point.)
Given that, application programmers no longer need scripting languages, unless they must use one of those old-fashioned languages like C++ or Fortran. So I think the need for dedicated scripting languages will simply evaporate for programmers.
As for administrators, I'm not sure what would happen there -- maybe they'd continue using their own scripting languages, or maybe they'd switch to the same all-purpose languages that the programmers are using. These new languages are much easier to learn than their predecessors so that's not an unrealistic idea IMO.
Chris Nahr
Tuesday, December 30, 2003
*Dynamic* typing NOT weak typing.
And the point isn't productivity on very samll apps but on very large ones. The delta on a 3 line vs 8 line is small. Scale those numbers up and you can see real gains.
"Scripting" languages are not a panacea but they should be evaluated on the proper merits.
fool for python
Tuesday, December 30, 2003
A lot of this really depends on how you expect the scripting language to be used. I've seen it used for stuff like the calculate rates example, but also to allow sophisticated customers to customize an application. For example, you might have an order processing application where when an order is processed it calls a script that goes out and does additional calculations, decrements inventory etc. At some level this is no longer a script, but a real program. The line between a script and a program is pretty arbitrary.
For the high powered user, the thing to do for dotnet is to provide standard classes that he/she can inherit from using any of dotnet classes. For the application I am working on, we are providing sample VB.net source for some sample "scripts" so the user can see what they need to do for customization.
Schmiel the painter
Tuesday, December 30, 2003
Well, I'm not familiar with .Net or C# very much (albeit probably should take a look at them sometime), have a rather limited experience with Java, and only heard from a Microsoft developer that C#/.Net was closer to Java than to Perl. In any case, here is my case for the language as a 100% Perl fanatic:
1. Perl is very fast to write code in: it has garbage collection (albeit one that cannot handle circular references well, which is a problem), unlimited data structures, nested data structures, regular expressions with a very convenient syntax,
lots of shortcuts, TIMTOWDI (There's more than one way to do it), convenient and flexible OO framework, FPish constructs. You name it - it's there.
2. Perl has a lot of open source modules available on CPAN that facilitate most common tasks. Most of the tasks that can be done in Java or .Net (using non-open-source APIs) can just as well be done with CPAN modules, and then there's all those convenience APIs.
CPAN modules can be installed from the network in one command line command, while tracking all the modules' dependencies. This and its completeness makes CPAN the envy of all other scripting languages.
3. Perl does not need to be compiled - it is ran out of the box.
4. Despite being a high level, dynamically typed language Perl supports a lot of low-level mechanisms. It supports files, sockets, fork() on UNIX, various Win32 functions on Windows, many other UNIX system calls, etc. As such, you can easily write system tools in Perl, and do most things that would otherwise require C.
5. Perl runs almost everywhere.(UNIX, Windows, MacOS (pre-X), Amiga OS, DOS)
6. I _looove_ Perl! It maps directly to my mode of thinking.
Note that I am referring to Perl because it's the language that I'm most familiar with and that I use the most. All these advantages may or may not be applicable to other of the so-called "scripting languages". (which is a very misleading term, because they can easily be used for things larger in scope than scripts).
I'm also not standing against C#/.NET, Java or whatever. I relatively dislike programming in Java because of its verbosity, but it is a nice language with its own niche.
Shlomi Fish
Thursday, January 1, 2004
 Recent Topics
Fog Creek Home
|
