|
|
|
|
Multiposted.
Already being discussed in microsoft.public.scripting.wsh
|
|
I like bananas much more than apples too.
|
|
why not just let people do what they want to do and YOU do what YOU want to
do? youre like one of those religious freaks that knock on my door trying to
push their beliefs on me.
get a life pal
"Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message
news:uTbqCjQuHHA.1212[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text]
|
|
|
|
"Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message
news:uTbqCjQuHHA.1212[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > Hi all,
>
> I've published an article titled _Eight Reasons Windows Administrators
> Should Learn JScript Instead of VBScript_ on O'Reilly's
> windowsdevcenter.com site. I'd love to hear any feedback.
>
>
http://www.windowsdevcenter.com/pub/a/windows/2007/06/19/eight-reasons-windows-administrators-should-learn-jscript-instead-of-vbscript.ht
>
> Thanks!
>
> --
> Bill Stewart
None of the 8 points address an issue specifically related to Windows
Administrators. Hence I think all it is saying is that Javascript is a
better language to use. That is a highly subjective POV.
1.) JScript is more widely user.
Are you sure? How much content in the vbscript group is about windows
admin. Compare that wih the amount of content in the Jscript group about
windows admin. From a windows admin point of view VBScript is far more
widely used.
2). JScript is Alive and Well
1.5 is. 2.0 isn't implemented yet. VScript is also Alive and Well.
3) JScript is Easy to Learn
That is true. That isn't true. The syntax is smaller so there is initally
less to learn. However, the use of } where VBScript would have used the more
explicit End If or End Select etc makes it harder to read. Also to use
JScript effectively takes more 'sideways' thinking where VBScript is more
obvious although utlimately limiting.
4) JScript Is Object-Oriented
This is true, VBScript is to a degree but not with JScript's flexibility.
However a balanced treatment would point out that a VB Class can define
Properties but a JScript class can't (you can only define functions).
It would also be worth pointing out that data hiding (a fundemental precept
in OO ( although not the entirely overriding one as many believe)) is
implemented using the private keyword in VBScript. In JScript this gives
you a choice. You can either make all your values publically available on
'this' so that functions attached to the prototype can access them OR you
define all your values and functions in the constructor and add some of the
functions (the ones to be public) to 'this' but then you can't benefit from
the prototype approach.
JScript does enable inheritance but your example isn't it. In your example
you've added a new member to an existing Class without actually defining a
new class. A better example would be:-
function Base() {}
Base.prototype.getA = function() { return 'A'; }
Base.prototype.getB = function() { return 'B'; }
function Derived() {}
Derived.prototype = new Base()
Derived.prototype.getB = function() { return 'Y'; }
Derived.prototype.getC = function() { return 'Z'; }
Of course combining data hiding and inheritance in a JScript OO
implementation is somewhat more tricky yet possible unlike VBScript.
5) JScript's Regular Expression Handling Is Better
Again this is subjective and I think you are confusing fewer lines of code
with 'better'. VBScirpts verbosity is not necessarily a weakness. The
VBScript is IMO more clear in its intentions and operation.
Also take a look at this:-
SearchTarget = "I want this AB1234 and this DC4568"
Set RE = New RegExp
With RE
.Pattern = "([A-Z]{2})([0-9]{4})"
.Global = True
End With
Set oMatches = RE.Execute(SearchTarget)
For Each oMatch In oMatches
MsgBox oMatch.SubMatches(0)
MsgBox oMatch.SubMatches(1)
Next
What does that look like in JScript and honestly how 'easy' was it to write.
6) JScript Arrays Are Much More Powerful
They are more powerfull but again not for the reasons you highlight.
First off if I define an array with a fixed size I mean just that, a fixed
size, something that JScript actually can't do. If my code were to attempt
to assign a value to the 6th element of a 5 element array I would much
rather it error than to blindly carry on doing something it shouldn't be
doing.
The true reason that JScript arrays are more powerful is the prescence of a
number of useful methods such as splice, shift, pop etc.
The dictionary object is not anymore designed to overcome the limitations of
the VBScript array it has a different function. You use of it in a Jscript
example is utterly bewildering. What point are you trying to make here?
How does the JScript array differ from the VBArray that makes the Dictionary
object unnecessary in the JScript case?
I think the point you may be alluding to has nothing to do with vector
arrays at all and is a reference to the associative array that can easily be
implemented with a JScript object (not an array just a simple object) and
the need to use the Dictionary object in VBScript to replicate the same
thing. This would be an example of the 'sideways' thinking I refered to
earlier.
7) JScript Date Handling Avoids Local Time Problems
Now this makes sense JScript date time handling is better the VBScript and I
can't think of anything that you can do VBScript that can't be done in
JScript. You even managed a Windows Admin oriented example.
Adding 200 minutes to a date in VBScript is DateAdd("nn", 200, dat) whereas
in JScript is dat.setMinutes(dat.getMinutes() + 200). The JScript syntax
isn't as obvious, it's another example of the 'sideways' thinking the
JScript requires.
8) JScript has better Exception Handling
More sense here also. The Error handling in VBScript is next to useless.
Conclusion
Overall I tend to agree that JScript has more to recommend it than VBScript
but your reasoning in this article leaves some significant room for
improvement.
As to whether it is better for admins I'm not so sure. Technically it is
but commercially it may not be. Are you going to be the sysadmin for your
current systems forever? Who is going to have to maintain your clever OO
Jscript code after you? Is it possible to be a system administrator who
writes scripts and NOT know how to do them in VBScript? If you wanted to
move to a 'better' language would not Powershell be a more a obvious choice?
Anthony.
|
|
|
[Quoted Text] > That is not the point of Bill's article at all. It is a thoughtfully
> presented argument for a language that many people may not be aware of
> or realize the benefits.
It's an opinion piece, celebrating one language over
another. That just invites an endless debate over the
pros and cons of different languages.
Luckily for us, most of the Perl people are already convinced
that they've got the best language, so they don't feel a need to
spam us with a salespitch. :)
|
|
Anthony Jones wrote:
Hi Anthony,
Thanks for writing.
[Quoted Text] > None of the 8 points address an issue specifically related to Windows
> Administrators. Hence I think all it is saying is that Javascript is a
> better language to use. That is a highly subjective POV.
>
> 1.) JScript is more widely user.
>
> Are you sure? How much content in the vbscript group is about windows
> admin. Compare that wih the amount of content in the Jscript group about
> windows admin. From a windows admin point of view VBScript is far more
> widely used.
Perhaps I didn't say this too clearly. I meant that JavaScript solves
problems in more problem spaces than VBScript does.
> 2). JScript is Alive and Well
>
> 1.5 is. 2.0 isn't implemented yet. VScript is also Alive and Well.
Yes, VBScript is alive (barely), but it's on life support. MS is not
going to be updating it.
> 3) JScript is Easy to Learn
>
> That is true. That isn't true. The syntax is smaller so there is initally
> less to learn. However, the use of } where VBScript would have used the more
> explicit End If or End Select etc makes it harder to read. Also to use
> JScript effectively takes more 'sideways' thinking where VBScript is more
> obvious although utlimately limiting.
I agree that this is somewhat subjective, but my point was that JScript
has gotten a bad rap for being hard to learn. And if you're going to
learn a scripting language, JScript (because it's JavaScript) is a
better addition to your resume.
> 4) JScript Is Object-Oriented
>
> This is true, VBScript is to a degree but not with JScript's flexibility.
> However a balanced treatment would point out that a VB Class can define
> Properties but a JScript class can't (you can only define functions).
If I understand what you're saying, that's not correct. JScript objects
can have properties (?).
> It would also be worth pointing out that data hiding (a fundemental precept
> in OO ( although not the entirely overriding one as many believe)) is
> implemented using the private keyword in VBScript. In JScript this gives
> you a choice. You can either make all your values publically available on
> 'this' so that functions attached to the prototype can access them OR you
> define all your values and functions in the constructor and add some of the
> functions (the ones to be public) to 'this' but then you can't benefit from
> the prototype approach.
This starts to get a bit technical, but you can, in fact, implement data
hiding in JScript with closures.
> 5) JScript's Regular Expression Handling Is Better
>
> Again this is subjective and I think you are confusing fewer lines of code
> with 'better'. VBScirpts verbosity is not necessarily a weakness. The
> VBScript is IMO more clear in its intentions and operation.
>
> Also take a look at this:-
>
> SearchTarget = "I want this AB1234 and this DC4568"
>
> Set RE = New RegExp
> With RE
> .Pattern = "([A-Z]{2})([0-9]{4})"
> .Global = True
> End With
>
> Set oMatches = RE.Execute(SearchTarget)
> For Each oMatch In oMatches
> MsgBox oMatch.SubMatches(0)
> MsgBox oMatch.SubMatches(1)
> Next
>
> What does that look like in JScript and honestly how 'easy' was it to write.
Equivalent JScript code would be something like this:
var searchtarget = "I want this AB1234 and this DC4568";
var re = /([A-Z]{2})([0-9]{4})/g;
var matches = re.exec(searchtarget);
while (matches != null) {
var a = RegExp.$1; // returns first submatch
var b = RegExp.$2; // returns second submatch
matches = re.exec(searchtarget);
}
> 6) JScript Arrays Are Much More Powerful
>
> They are more powerfull but again not for the reasons you highlight.
>
> First off if I define an array with a fixed size I mean just that, a fixed
> size, something that JScript actually can't do. If my code were to attempt
> to assign a value to the 6th element of a 5 element array I would much
> rather it error than to blindly carry on doing something it shouldn't be
> doing.
One philosophy is that scripting language design should give you more
flexibility, not less. My own opinion is that I don't want to have to
worry about array bounds checking in a scripting language.
> The true reason that JScript arrays are more powerful is the prescence of a
> number of useful methods such as splice, shift, pop etc.
>
> The dictionary object is not anymore designed to overcome the limitations of
> the VBScript array it has a different function. You use of it in a Jscript
> example is utterly bewildering. What point are you trying to make here?
> How does the JScript array differ from the VBArray that makes the Dictionary
> object unnecessary in the JScript case?
I think VBScript's limited arrays had a great deal to do with why MS
created the the Dictionary object because VBScript has no list or hash type.
> 7) JScript Date Handling Avoids Local Time Problems
>
> Now this makes sense JScript date time handling is better the VBScript and I
> can't think of anything that you can do VBScript that can't be done in
> JScript. You even managed a Windows Admin oriented example.
>
> Adding 200 minutes to a date in VBScript is DateAdd("nn", 200, dat) whereas
> in JScript is dat.setMinutes(dat.getMinutes() + 200). The JScript syntax
> isn't as obvious, it's another example of the 'sideways' thinking the
> JScript requires.
Agreed, that JScript date handling is better.
> 8) JScript has better Exception Handling
>
> More sense here also. The Error handling in VBScript is next to useless.
Agreed, that try ... catch is better than On Error Resume Next/On Error
GoTo 0.
> Conclusion
>
> Overall I tend to agree that JScript has more to recommend it than VBScript
> but your reasoning in this article leaves some significant room for
> improvement.
>
> As to whether it is better for admins I'm not so sure. Technically it is
> but commercially it may not be. Are you going to be the sysadmin for your
> current systems forever? Who is going to have to maintain your clever OO
> Jscript code after you? Is it possible to be a system administrator who
> writes scripts and NOT know how to do them in VBScript? If you wanted to
> move to a 'better' language would not Powershell be a more a obvious choice?
I like PowerShell, but at this time it exists in a slightly different
problem space than WSH.
Thanks for writing; I appreciate your input.
--
Bill Stewart
|
|
Bill,
I liked your article and I agree with a lot of your points -
particularly vbscript's weakness in the arrays and error handling.
Something you didn't mention is vbscripts wierd insistence on
distinguishing between Subs and Functions and the oddities between
passing arguments to subs with or without parentheses
eg - check this out:
a=1
AddOne a
MsgBox a
'now a = 2 as expected
AddOne(a)
MsgBox a
'hah, foolish n00b ! a = 2 still !!!
Sub AddOne(ByRef a)
a= a +1
End Sub
One thing I would say in vbscript's defence (and this will mean
nothing to those who scrorn all things Micro$oft related - but since
we all use the WSH here, this can't be any of us right? (-; ) is that
vbscript has a lot in common with vba (for MS Word, Excel, PowerPoint
etc) and Visual Basic. This makes it a heck of a lot easier to move
useful script functions (and knowledge) between all things MS. As much
as I dislike Vb6, applications are not going to get converted to .net
overnight. So, for me, for now at least, it makes sence to keep my
hand in with vb style syntax as well as c style. I guess it comes down
to what other things you are working on.
Tim.
|
|
Tim wrote:
[Quoted Text] > I liked your article and I agree with a lot of your points -
> particularly vbscript's weakness in the arrays and error handling.
> Something you didn't mention is vbscripts wierd insistence on
> distinguishing between Subs and Functions and the oddities between
> passing arguments to subs with or without parentheses
Yes, I find this to be an annoyance as well. (Forcing the use of the Set
statement to assign object references is another one.)
> One thing I would say in vbscript's defence (and this will mean
> nothing to those who scrorn all things Micro$oft related - but since
> we all use the WSH here, this can't be any of us right? (-; ) is that
> vbscript has a lot in common with vba (for MS Word, Excel, PowerPoint
> etc) and Visual Basic. This makes it a heck of a lot easier to move
> useful script functions (and knowledge) between all things MS. As much
> as I dislike Vb6, applications are not going to get converted to .net
> overnight. So, for me, for now at least, it makes sence to keep my
> hand in with vb style syntax as well as c style. I guess it comes down
> to what other things you are working on.
Agreed, VBA is similar to VBScript, but if I understand it correctly,
VBA is more like VB6 than it is like VBScript.
Thanks for writing.
--
Bill Stewart
|
|
"Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message
news:OfmaYHcuHHA.4572[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] > Tim wrote:
>
>> I liked your article and I agree with a lot of your points -
>> particularly vbscript's weakness in the arrays and error handling.
>> Something you didn't mention is vbscripts wierd insistence on
>> distinguishing between Subs and Functions and the oddities between
>> passing arguments to subs with or without parentheses
>
> Yes, I find this to be an annoyance as well. (Forcing the use of the Set
> statement to assign object references is another one.)
For the record, I do not find this an annoyance. I suspect that it was not
an arbitrary decision to make it work that way, but the result of other
design decisions.
/Al
>> One thing I would say in vbscript's defence (and this will mean
>> nothing to those who scrorn all things Micro$oft related - but since
>> we all use the WSH here, this can't be any of us right? (-; ) is that
>> vbscript has a lot in common with vba (for MS Word, Excel, PowerPoint
>> etc) and Visual Basic. This makes it a heck of a lot easier to move
>> useful script functions (and knowledge) between all things MS. As much
>> as I dislike Vb6, applications are not going to get converted to .net
>> overnight. So, for me, for now at least, it makes sence to keep my
>> hand in with vb style syntax as well as c style. I guess it comes down
>> to what other things you are working on.
>
> Agreed, VBA is similar to VBScript, but if I understand it correctly, VBA
> is more like VB6 than it is like VBScript.
>
> Thanks for writing.
>
> --
> Bill Stewart
|
|
"Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message
news:eQOxb9ZuHHA.1184[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] > Anthony Jones wrote:
>
> Hi Anthony,
>
> Thanks for writing.
>
>> None of the 8 points address an issue specifically related to Windows
>> Administrators. Hence I think all it is saying is that Javascript is a
>> better language to use. That is a highly subjective POV.
>>
>> 1.) JScript is more widely user.
>>
>> Are you sure? How much content in the vbscript group is about windows
>> admin. Compare that wih the amount of content in the Jscript group about
>> windows admin. From a windows admin point of view VBScript is far more
>> widely used.
>
> Perhaps I didn't say this too clearly. I meant that JavaScript solves
> problems in more problem spaces than VBScript does.
That is how I understood you. But then your article is aimed at system admin
types who you try to convince jscript is better because it is used for
functions they have no interest in. Someone interested in a small,
economical car is not going to be pursuaded to get a maserati because they
could enter races with it.
>> 2). JScript is Alive and Well
>>
>> 1.5 is. 2.0 isn't implemented yet. VScript is also Alive and Well.
>
> Yes, VBScript is alive (barely), but it's on life support. MS is not going
> to be updating it.
I'm going to take exception to the implications of the "life support"
characterization. VBScript is what it is, and it does what it does. And on a
given platform that supports it now, it will likely continue to do so for
the foreseeable future.
>> 3) JScript is Easy to Learn
>>
>> That is true. That isn't true. The syntax is smaller so there is
>> initally
>> less to learn. However, the use of } where VBScript would have used the
>> more
>> explicit End If or End Select etc makes it harder to read. Also to use
>> JScript effectively takes more 'sideways' thinking where VBScript is more
>> obvious although utlimately limiting.
>
> I agree that this is somewhat subjective, but my point was that JScript
> has gotten a bad rap for being hard to learn.
Then instead of entitling reason no. 3 as: "JScript is easy to learn" you
should have called it: "JScript is not as hard to learn as you might have
heard".
A quick re-read indicates this section to have been very objective, as you
do not even imply that it is easier to learn than vbscript, just that the
two languages are perhaps on a par in this respect. Rather than this fact
being a reason to learn it, it would be truer to say that its being harder
to learn is no reason for not learning it, because that assumption is
untrue.
I believe that, because our brains do not all think exactly the same way,
that we find some languages more naturally attuned to our thought processes
than others. Like, which is harder to learn in school: chemistry or physics?
My wife says chemistry and I say physics - which of us is wrong? And this, I
think, has more to do with your affinity for jscript than a stack of ECMA
standard documents.
> And if you're going to learn a scripting language, JScript (because
> it's JavaScript) is a better addition to your resume.
Ah, yes, I have heard this one before. It might indeed be true, however, it
quite possibly depends on the job market you happen to be in. Definitely so
if you are moving towards web development (although javascript might be more
appropriate there), but not if you are applying for a job in a shop that
does a lot of admin scripting in vbscript. Still, given that you feel this
way, I am surprised it did not appear as reason number Nine.
>> 4) JScript Is Object-Oriented
>>
>> This is true, VBScript is to a degree but not with JScript's flexibility.
>> However a balanced treatment would point out that a VB Class can define
>> Properties but a JScript class can't (you can only define functions).
>
> If I understand what you're saying, that's not correct. JScript objects
> can have properties (?).
>
>> It would also be worth pointing out that data hiding (a fundemental
>> precept
>> in OO ( although not the entirely overriding one as many believe)) is
>> implemented using the private keyword in VBScript. In JScript this gives
>> you a choice. You can either make all your values publically available
>> on
>> 'this' so that functions attached to the prototype can access them OR you
>> define all your values and functions in the constructor and add some of
>> the
>> functions (the ones to be public) to 'this' but then you can't benefit
>> from
>> the prototype approach.
>
> This starts to get a bit technical, but you can, in fact, implement data
> hiding in JScript with closures.
And I do "data hiding" in vbscript using the "private" keyword outside of
the context of a class (where it has exactly the same effect as "public")
combined with a particular methodology regarding how I structure my code. I
had a Fortran colleague years ago who said of the coming technologies:
"objects, smobjects, we can just structure our fortran code to do exactly
the same thing". Of course, he was dead wrong; but in the context of
vbscript, I am right to say virtually the same thing ;-)
>> 5) JScript's Regular Expression Handling Is Better
>>
>> Again this is subjective and I think you are confusing fewer lines of
>> code
>> with 'better'. VBScirpts verbosity is not necessarily a weakness. The
>> VBScript is IMO more clear in its intentions and operation.
>>
>> Also take a look at this:-
>>
>> SearchTarget = "I want this AB1234 and this DC4568"
>>
>> Set RE = New RegExp
>> With RE
>> .Pattern = "([A-Z]{2})([0-9]{4})"
>> .Global = True
>> End With
>>
>> Set oMatches = RE.Execute(SearchTarget)
>> For Each oMatch In oMatches
>> MsgBox oMatch.SubMatches(0)
>> MsgBox oMatch.SubMatches(1)
>> Next
>>
>> What does that look like in JScript and honestly how 'easy' was it to
>> write.
>
> Equivalent JScript code would be something like this:
>
> var searchtarget = "I want this AB1234 and this DC4568";
> var re = /([A-Z]{2})([0-9]{4})/g;
> var matches = re.exec(searchtarget);
> while (matches != null) {
> var a = RegExp.$1; // returns first submatch
> var b = RegExp.$2; // returns second submatch
> matches = re.exec(searchtarget);
> }
You didn't say how easy that was, however, it is my experience that when one
is working in a language of choice in which one is proficient, almost any
task is easier than in an unliked, unfamiliar language.
>> 6) JScript Arrays Are Much More Powerful
>>
>> They are more powerfull but again not for the reasons you highlight.
>>
>> First off if I define an array with a fixed size I mean just that, a
>> fixed
>> size, something that JScript actually can't do. If my code were to
>> attempt
>> to assign a value to the 6th element of a 5 element array I would much
>> rather it error than to blindly carry on doing something it shouldn't be
>> doing.
>
> One philosophy is that scripting language design should give you more
> flexibility, not less. My own opinion is that I don't want to have to
> worry about array bounds checking in a scripting language.
I strongly suspect that you have been conditioned to think that way because
of your platform of choice. Similarly, those of us fonder of vbscript have
adapted to that language's minor inflexibility in this area.
>> The true reason that JScript arrays are more powerful is the prescence of
>> a
>> number of useful methods such as splice, shift, pop etc.
If this is because arrays are objects, then I agree. In fact, that is one
thing I think is great about powershell: everything is an object.
>> The dictionary object is not anymore designed to overcome the limitations
>> of
>> the VBScript array it has a different function. You use of it in a
>> Jscript
>> example is utterly bewildering. What point are you trying to make here?
>> How does the JScript array differ from the VBArray that makes the
>> Dictionary
>> object unnecessary in the JScript case?
>
> I think VBScript's limited arrays had a great deal to do with why MS
> created the the Dictionary object because VBScript has no list or hash
> type.
Your basic disagreement, and one that may never be fully resolved.
>> 7) JScript Date Handling Avoids Local Time Problems
>>
>> Now this makes sense JScript date time handling is better the VBScript
>> and I
>> can't think of anything that you can do VBScript that can't be done in
>> JScript. You even managed a Windows Admin oriented example.
>>
>> Adding 200 minutes to a date in VBScript is DateAdd("nn", 200, dat)
>> whereas
>> in JScript is dat.setMinutes(dat.getMinutes() + 200). The JScript
>> syntax
>> isn't as obvious, it's another example of the 'sideways' thinking the
>> JScript requires.
>
> Agreed, that JScript date handling is better.
>
>> 8) JScript has better Exception Handling
>>
>> More sense here also. The Error handling in VBScript is next to useless.
>
> Agreed, that try ... catch is better than On Error Resume Next/On Error
> GoTo 0.
>
>> Conclusion
>>
>> Overall I tend to agree that JScript has more to recommend it than
>> VBScript
>> but your reasoning in this article leaves some significant room for
>> improvement.
>>
>> As to whether it is better for admins I'm not so sure. Technically it is
>> but commercially it may not be. Are you going to be the sysadmin for
>> your
>> current systems forever? Who is going to have to maintain your clever OO
>> Jscript code after you? Is it possible to be a system administrator who
>> writes scripts and NOT know how to do them in VBScript? If you wanted to
>> move to a 'better' language would not Powershell be a more a obvious
>> choice?
>
> I like PowerShell, but at this time it exists in a slightly different
> problem space than WSH.
Yes. But one of its definite strengths is in the admin problem space, where
it seems more naturally positioned than either WSH language. Leading me to
my earlier comment that the js/vbs argument is old news, at least insofar as
admin scripting is concerned.
/Al
|
|
"Anthony Jones" <Ant[ at ]yadayadayada.com> wrote in message
news:edJSlXYuHHA.3544[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > > "Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message > news:uTbqCjQuHHA.1212[ at ]TK2MSFTNGP05.phx.gbl... >> Hi all, >> >> I've published an article titled _Eight Reasons Windows Administrators >> Should Learn JScript Instead of VBScript_ on O'Reilly's >> windowsdevcenter.com site. I'd love to hear any feedback. >> >> > http://www.windowsdevcenter.com/pub/a/windows/2007/06/19/eight-reasons-windows-administrators-should-learn-jscript-instead-of-vbscript.ht>> >> Thanks! >> >> -- >> Bill Stewart > > None of the 8 points address an issue specifically related to Windows > Administrators. Hence I think all it is saying is that Javascript is a > better language to use. That is a highly subjective POV.
Agreed, and well stated.
<snip>
/Al
|
|
"mayayana" <mayaXXyana1a[ at ]mindXXspring.com> wrote in message
news:PyOgi.1733$rR.134[ at ]newsread2.news.pas.earthlink.net...
[Quoted Text] >> That is not the point of Bill's article at all. It is a thoughtfully
>> presented argument for a language that many people may not be aware of
>> or realize the benefits.
>
> It's an opinion piece, celebrating one language over
> another. That just invites an endless debate over the
> pros and cons of different languages.
>
> Luckily for us, most of the Perl people are already convinced
> that they've got the best language, so they don't feel a need to
> spam us with a salespitch. :)
And thank goodness the Pascal/Fortran flame war seems finally to be over!
;-)
/Al
|
|
"Jeffery Hicks" <jhicks[ at ]sapien.com> wrote in message
news:ucQN%23CYuHHA.4952[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] >S Moran wrote: >> why not just let people do what they want to do and YOU do what YOU want >> to do? youre like one of those religious freaks that knock on my door >> trying to push their beliefs on me. >> get a life pal >> >> >> >> "Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message >> news:uTbqCjQuHHA.1212[ at ]TK2MSFTNGP05.phx.gbl... >>> Hi all, >>> >>> I've published an article titled _Eight Reasons Windows Administrators >>> Should Learn JScript Instead of VBScript_ on O'Reilly's >>> windowsdevcenter.com site. I'd love to hear any feedback. >>> >>> http://www.windowsdevcenter.com/pub/a/windows/2007/06/19/eight-reasons-windows-administrators-should-learn-jscript-instead-of-vbscript.ht>>> >>> Thanks! >>> >>> -- >>> Bill Stewart >> > > That is not the point of Bill's article at all. It is a thoughtfully > presented argument for a language that many people may not be aware of or > realize the benefits.
That is certainly how I understood him. But at the same time, he does seem
to stray over the line of objectivity just the teeniest little bit.
> JScript doesn't get nearly the visibility of VBScript and Bill is
> merely pointing out what we're missing. I'm a firm adherent to the right
> tool for the job philosophy and knowing when JScript is the right tool can
> only make your own job easier.
Agreed. However, Bill seems to feel (if I read him correctly) the need to
point out the view that VBScript is almost never the right tool for the job
because of its lack of compliance to the ECMA standard. Surely there is room
for disagreement without some of us having to be wrong.
Yes, I may be extrapolating his opinions somewhat. Perhaps Bill just sought
to avoid a more balanced comparison because the apparent weight of popular
opinion seems so heavily weighed in favour of vbscript for admin
programming. And if that were not the case, he probably would not have
written the article in the first place.
/Al
|
|
"Tim" <TimJordanVBS[ at ]hotmail.com> wrote in message
news:1183060881.150104.267250[ at ]o61g2000hsh.googlegroups.com...
[Quoted Text] > Bill,
>
> I liked your article and I agree with a lot of your points -
> particularly vbscript's weakness in the arrays and error handling.
> Something you didn't mention is vbscripts wierd insistence on
> distinguishing between Subs and Functions and the oddities between
> passing arguments to subs with or without parentheses
As with most languages one can find detractors for, many such "weirdnesses"
spring from a gap in one's understanding of the actual nature of the
language.
> eg - check this out:
>
> a=1
> AddOne a
> MsgBox a
> 'now a = 2 as expected
>
> AddOne(a)
> MsgBox a
> 'hah, foolish n00b ! a = 2 still !!!
But, once one realises why "(a)" does not provide the sub the address of the
variable "a", but an address to where the resultant value of the expression
"a" is stored, the weirdness of this vanishes.
> Sub AddOne(ByRef a)
> a= a +1
> End Sub
I certainly agree that this is one detail that has bitten more than a few
n00b's, and sometimes more than once. Coming from a Fortran background, I
found the apparent looseness and forgiveness of syntax a bit confusing,
especially when one added a second argument to a sub:
sub test(a, b)
msgbox a & vbnewline & b
end sub
as the correct way to call this sub would be either:
call test ("dog", "cat")
or:
test "dog", "cat"
whereas
test ("dog", "cat")
throws an error. And, strangely enough, the text of the error message is
"cannot use parentheses when calling a sub", even though:
a) the error message is the same when the sub is converted to a function,
and:
b) when you are calling a sub with CALL, rather than invoking it with just
its name, then parentheses are actually required.
As to what you refer to as: "vbscripts wierd insistence on distinguishing
between Subs and Functions...", this is, imho, a carry-over from earlier
programming languages, and it can be a useful tool for scripters with
procedural language backgrounds. Personally, I code all my subs as
functions, because that is completely valid, and a bit simpler.
> One thing I would say in vbscript's defence (and this will mean
> nothing to those who scrorn all things Micro$oft related - but since
> we all use the WSH here, this can't be any of us right? (-; ) is that
> vbscript has a lot in common with vba (for MS Word, Excel, PowerPoint
> etc) and Visual Basic.
This is a good point that I hadn't thought of. As with Bill's "more widely
used" point, what it really means to a particular individual really depends
on what other things that person is doing, I do very little VBA and no VB,
so that would not be a compelling argument for me to take up VBScript (if
one were needed).
> This makes it a heck of a lot easier to move
> useful script functions (and knowledge) between all things MS. As much
> as I dislike Vb6, applications are not going to get converted to .net
> overnight. So, for me, for now at least, it makes sence to keep my
> hand in with vb style syntax as well as c style. I guess it comes down
> to what other things you are working on.
Oooops, I wrote my most recent sentence above before I noticed you said much
the same thing.
/Al
|
|
"Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message
news:eQOxb9ZuHHA.1184[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] > Anthony Jones wrote:
>
> Hi Anthony,
>
> Thanks for writing.
>
> > None of the 8 points address an issue specifically related to Windows
> > Administrators. Hence I think all it is saying is that Javascript is a
> > better language to use. That is a highly subjective POV.
> >
> > 1.) JScript is more widely user.
> >
> > Are you sure? How much content in the vbscript group is about windows
> > admin. Compare that wih the amount of content in the Jscript group
about
> > windows admin. From a windows admin point of view VBScript is far more
> > widely used.
>
> Perhaps I didn't say this too clearly. I meant that JavaScript solves
> problems in more problem spaces than VBScript does.
I don't believe that. Care to offer an example of a 'Problem space' that
JScript can handle and VBScript can't?
>
> > 2). JScript is Alive and Well
> >
> > 1.5 is. 2.0 isn't implemented yet. VScript is also Alive and Well.
>
> Yes, VBScript is alive (barely), but it's on life support. MS is not
> going to be updating it.
When was the last time C++ was updated? Is it a dead language?
>
> > 3) JScript is Easy to Learn
> >
> > That is true. That isn't true. The syntax is smaller so there is
initally
> > less to learn. However, the use of } where VBScript would have used the
more
> > explicit End If or End Select etc makes it harder to read. Also to use
> > JScript effectively takes more 'sideways' thinking where VBScript is
more
> > obvious although utlimately limiting.
>
> I agree that this is somewhat subjective, but my point was that JScript
> has gotten a bad rap for being hard to learn. And if you're going to
> learn a scripting language, JScript (because it's JavaScript) is a
> better addition to your resume.
Again highly subjective. If the HR dept is looking for someone to maintain
thousands of lines of Windows Admin code written in VBScript ther're not
looking for someone with JScript on the CV.
>
> > 4) JScript Is Object-Oriented
> >
> > This is true, VBScript is to a degree but not with JScript's
flexibility.
> > However a balanced treatment would point out that a VB Class can define
> > Properties but a JScript class can't (you can only define functions).
>
> If I understand what you're saying, that's not correct. JScript objects
> can have properties (?).
Javascript can, JScript can't. If that isn't true please post the code
demonstrating that here.
>
> > It would also be worth pointing out that data hiding (a fundemental
precept
> > in OO ( although not the entirely overriding one as many believe)) is
> > implemented using the private keyword in VBScript. In JScript this
gives
> > you a choice. You can either make all your values publically available
on
> > 'this' so that functions attached to the prototype can access them OR
you
> > define all your values and functions in the constructor and add some of
the
> > functions (the ones to be public) to 'this' but then you can't benefit
from
> > the prototype approach.
>
> This starts to get a bit technical, but you can, in fact, implement data
> hiding in JScript with closures.
Yes I did make that point above. It has it's downside that you can't easily
implement a prototype based solution in combination with data hiding. Using
closures requires each instance to redefine all the functions.
>
> > 5) JScript's Regular Expression Handling Is Better
> >
> > Again this is subjective and I think you are confusing fewer lines of
code
> > with 'better'. VBScirpts verbosity is not necessarily a weakness. The
> > VBScript is IMO more clear in its intentions and operation.
> >
> > Also take a look at this:-
> >
> > SearchTarget = "I want this AB1234 and this DC4568"
> >
> > Set RE = New RegExp
> > With RE
> > .Pattern = "([A-Z]{2})([0-9]{4})"
> > .Global = True
> > End With
> >
> > Set oMatches = RE.Execute(SearchTarget)
> > For Each oMatch In oMatches
> > MsgBox oMatch.SubMatches(0)
> > MsgBox oMatch.SubMatches(1)
> > Next
> >
> > What does that look like in JScript and honestly how 'easy' was it to
write.
>
> Equivalent JScript code would be something like this:
>
> var searchtarget = "I want this AB1234 and this DC4568";
> var re = /([A-Z]{2})([0-9]{4})/g;
> var matches = re.exec(searchtarget);
> while (matches != null) {
> var a = RegExp.$1; // returns first submatch
> var b = RegExp.$2; // returns second submatch
> matches = re.exec(searchtarget);
> }
Why does the second re.exec(searchtarget) not return the same result as the
first? Where does the RegExp object come from? My point is that this is IMO
not easier. It works but it looks mad, it takes some scrutiny and detailed
knowledge of JScript regex objects to understand.
>
> > 6) JScript Arrays Are Much More Powerful
> >
> > They are more powerfull but again not for the reasons you highlight.
> >
> > First off if I define an array with a fixed size I mean just that, a
fixed
> > size, something that JScript actually can't do. If my code were to
attempt
> > to assign a value to the 6th element of a 5 element array I would much
> > rather it error than to blindly carry on doing something it shouldn't be
> > doing.
>
> One philosophy is that scripting language design should give you more
> flexibility, not less. My own opinion is that I don't want to have to
> worry about array bounds checking in a scripting language.
Fine if that's your philosphy all well and good but your article is trying
tell others that also. I don't agree, in some cases bounds checking is a
good thing.
>
> > The true reason that JScript arrays are more powerful is the prescence
of a
> > number of useful methods such as splice, shift, pop etc.
> >
> > The dictionary object is not anymore designed to overcome the
limitations of
> > the VBScript array it has a different function. You use of it in a
Jscript
> > example is utterly bewildering. What point are you trying to make here?
> > How does the JScript array differ from the VBArray that makes the
Dictionary
> > object unnecessary in the JScript case?
>
> I think VBScript's limited arrays had a great deal to do with why MS
> created the the Dictionary object because VBScript has no list or hash
type.
>
True it has no list or hash type. Whats that got do with arrays?? JScript
array type doesn't support hashing either. That's fine thats not what arrays
are for. If you need a hashlist then you need another type of object. The
Dictionary does this adequately for VBScript. A JScript object does it
natively and more elegantly.
Don't get me wrong I agree JScript arrays are better (IMO) but not for the
reasons you outline in the article.
> > 7) JScript Date Handling Avoids Local Time Problems
> >
> > Now this makes sense JScript date time handling is better the VBScript
and I
> > can't think of anything that you can do VBScript that can't be done in
> > JScript. You even managed a Windows Admin oriented example.
> >
> > Adding 200 minutes to a date in VBScript is DateAdd("nn", 200, dat)
whereas
> > in JScript is dat.setMinutes(dat.getMinutes() + 200). The JScript
syntax
> > isn't as obvious, it's another example of the 'sideways' thinking the
> > JScript requires.
>
> Agreed, that JScript date handling is better.
>
> > 8) JScript has better Exception Handling
> >
> > More sense here also. The Error handling in VBScript is next to
useless.
>
> Agreed, that try ... catch is better than On Error Resume Next/On Error
> GoTo 0.
>
> > Conclusion
> >
> > Overall I tend to agree that JScript has more to recommend it than
VBScript
> > but your reasoning in this article leaves some significant room for
> > improvement.
> >
> > As to whether it is better for admins I'm not so sure. Technically it
is
> > but commercially it may not be. Are you going to be the sysadmin for
your
> > current systems forever? Who is going to have to maintain your clever
OO
> > Jscript code after you? Is it possible to be a system administrator who
> > writes scripts and NOT know how to do them in VBScript? If you wanted
to
> > move to a 'better' language would not Powershell be a more a obvious
choice?
>
> I like PowerShell, but at this time it exists in a slightly different
> problem space than WSH.
What is this 'problem space' thing anyway? If PowerShell doesn't exist in
the 'Windows Admin' problem space what space does it occupy?
>
> Thanks for writing; I appreciate your input.
>
> --
> Bill Stewart
|
|
"Al Dunbar" <AlanDrub[ at ]hotmail.com.nospaam> wrote in message
news:Ofr9RwfuHHA.4572[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >
> "Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message
> news:OfmaYHcuHHA.4572[ at ]TK2MSFTNGP02.phx.gbl...
> > Tim wrote:
> >
> >> I liked your article and I agree with a lot of your points -
> >> particularly vbscript's weakness in the arrays and error handling.
> >> Something you didn't mention is vbscripts wierd insistence on
> >> distinguishing between Subs and Functions and the oddities between
> >> passing arguments to subs with or without parentheses
> >
> > Yes, I find this to be an annoyance as well. (Forcing the use of the Set
> > statement to assign object references is another one.)
>
> For the record, I do not find this an annoyance. I suspect that it was not
> an arbitrary decision to make it work that way, but the result of other
> design decisions.
>
Utlimately the design decision that has brought this confusion about is to
allow COM Interfaces to define a default property. This IMO opinion was a
mistake.
Given that rs is an ADO recordset object In VBScript:-
Dim vnt, fld
vnt = rs("field") 'This gets the value of the field
Set fld = rs("field") 'This gets the field object
Whereas in JScript
var vnt = rs("field").Value //This gets the value of the field
var fld = rs("field") //This gets the field object
Default properties are ignored in JScript assignments.
Without default properties then accessing a value would look like:-
rs.Fields.Item("field").Value
with the inclusion of an accessor property (which does make sense) it could
have returned to
rs("field").Value
Which I think would have been a good compromise and would have avoided all
the Set confusion.
Anthony
|
|
|
[Quoted Text] > > Luckily for us, most of the Perl people are already convinced
> > that they've got the best language, so they don't feel a need to
> > spam us with a salespitch. :)
>
> And thank goodness the Pascal/Fortran flame war seems finally to be over!
> ;-)
>
:) Yes, I guess there's a lot to be thankful for. Now
if we could only see the death of C-chauvinism, that
would be the icing on the cake.
|
|
[Quoted Text] > What is this 'problem space' thing anyway
>
Oh, that's easy. A problem space is where cutting
edge solutionizing gets leveraged. :)
|
|
Anthony Jones wrote:
[Quoted Text] > I don't believe that. Care to offer an example of a 'Problem space' that
> JScript can handle and VBScript can't?
Some examples: Client-side scripting in a browser other than IE; OOo
scripting; Adobe applications; etc.
> When was the last time C++ was updated? Is it a dead language?
Nobody has explicitly said C++ will never again be updated (at least,
not that I'm aware of). Microsoft has explicitly said this about VBScript.
> Javascript can, JScript can't. If that isn't true please post the code
> demonstrating that here.
function Thing(thingname) {
this.label = thingname; // label is a property
}
var mything = new Thing("Thing 1");
var result = mything.label; // returns "Thing 1"
> Why does the second re.exec(searchtarget) not return the same result as the
> first? Where does the RegExp object come from? My point is that this is IMO
> not easier. It works but it looks mad, it takes some scrutiny and detailed
> knowledge of JScript regex objects to understand.
The RegExp object is a global object that gets updated each time the
exec method gets executed. Its a good example of how, with JScript
regular expressions are a built-in part of the language, whereas with
VBScript, it's an add-on object. I think JScript's implementation is
cleaner and more concise.
> Fine if that's your philosphy all well and good but your article is trying
> tell others that also. I don't agree, in some cases bounds checking is a
> good thing.
I agree if you're talking about a language where you need worry about
things like buffer overflows. I think it's handy when the scripting
language can handle this kind of stuff for you.
Thanks again for writing. All the input is appreciated.
--
Bill Stewart
|
|
Anthony Jones wrote:
[Quoted Text] > Utlimately the design decision that has brought this confusion about is to
> allow COM Interfaces to define a default property. This IMO opinion was a
> mistake.
You are correct, and I agree. This is a huge source of confusion.
--
Bill Stewart
|
|
"Bill Stewart" <llib.trawets[ at ]yrautromhcnerf.moc> wrote in message
news:%233kLxYmuHHA.3480[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] > Anthony Jones wrote:
>
> > I don't believe that. Care to offer an example of a 'Problem space'
that
> > JScript can handle and VBScript can't?
>
> Some examples: Client-side scripting in a browser other than IE; OOo
> scripting; Adobe applications; etc.
>
So a 'problem space' == 'host application'? Have you tried using JScript in
Word or Excel?
This is hardly a basis to state that one language is better than another.
> > When was the last time C++ was updated? Is it a dead language?
>
> Nobody has explicitly said C++ will never again be updated (at least,
> not that I'm aware of). Microsoft has explicitly said this about VBScript.
>
So you're only interested in a language that will change in the future then?
Any language which definitely won't change is somehow inferior to one that
will? Why? And is that a reason not to use a language?
> > Javascript can, JScript can't. If that isn't true please post the code
> > demonstrating that here.
>
> function Thing(thingname) {
> this.label = thingname; // label is a property
> }
> var mything = new Thing("Thing 1");
> var result = mything.label; // returns "Thing 1"
Ok perhaps I wasn't explicit enough:-
Class MyClass
Private aPrivateMember
Private hammerTime
Public Property Get Member()
Member = aPrivateMember
End Property
Public Property Let Member(Value)
'Code to validate Value e.g. Value is the correct type.
aMember = Value
'Code to perform other useful activity here
End Property
Public Property Get ReadOnly()
ReadOnly = hammerTime 'You can't touch this
End Public
End Class
>
> > Why does the second re.exec(searchtarget) not return the same result as
the
> > first? Where does the RegExp object come from? My point is that this is
IMO
> > not easier. It works but it looks mad, it takes some scrutiny and
detailed
> > knowledge of JScript regex objects to understand.
>
> The RegExp object is a global object that gets updated each time the
> exec method gets executed. Its a good example of how, with JScript
> regular expressions are a built-in part of the language, whereas with
> VBScript, it's an add-on object.
Doing 'new RegExp' in VBScript makes it an add-on how do you figure that?
How do you define a Date in JScript? With 'new Date' so does that make Date
an Add-on to JScript?
> I think JScript's implementation is cleaner and more concise.
It's more concise but concise doesn't equate to better. I've seen plenty of
concise C code that'll make you hair curl.
Clean? You are joking? In order to access the sub matches of the match you
have to access another object altogether which has properties called $1 and
$2. Do you honestly consider that clean? To be frank it appears to me that
RegEx has been grafted in to Javascript at a later stage with some ugly
consequences.
>
> > Fine if that's your philosphy all well and good but your article is
trying
> > tell others that also. I don't agree, in some cases bounds checking is
a
> > good thing.
>
> I agree if you're talking about a language where you need worry about
> things like buffer overflows. I think it's handy when the scripting
> language can handle this kind of stuff for you.
You've missed the point. VBScript is no more prone to Buffer overflows than
JScript in fact I can't see why you've mentioned them. The point is that
bounds checking can be useful, VBScript forces it in on you, in JScript you
need to do that yourself. Saying JScript is better because it doesn't do
bounds checking and will allow any number of elements be added to an array
is again subjective.
Anthony
|
|
In microsoft.public.scripting.vbscript message <edJSlXYuHHA.3544[ at ]TK2MSFT
NGP03.phx.gbl>, Thu, 28 Jun 2007 14:11:50, Anthony Jones
<Ant[ at ]yadayadayada.com> posted:
[Quoted Text] >
>Adding 200 minutes to a date in VBScript is DateAdd("nn", 200, dat) whereas
>in JScript is dat.setMinutes(dat.getMinutes() + 200). The JScript syntax
>isn't as obvious, it's another example of the 'sideways' thinking the
>JScript requires.
However, as VBS dates are held as a Double of Days, 200 minutes cannot
be added *exactly*, which can lead to problems later (e.g. in iteration)
if not understood. Consider
K = 0
for J = 0 to 23 : K = K + 1/24 : next
document.write K, " ", K=1 ' 1 false
However, DateAdd deals correctly with adding 60 minutes 24 times.
JS dates are held as a Double of milliseconds, and the resolution is
such that any number of milliseconds within the allowed range is held
exactly.
--
(c) John Stockton, Surrey, UK. ?[ at ]merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
|
|
|