Using JScript from VBScript (most cruelly)
![Alex K. Angelopoulos [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Alex K. Angelopoulos [MVP]
using very simplistic wrapups of JScript objects to access them almost
directly from VBScript, like in the following WSF example.
If anyone has, are there any intriguing uses people have found for this
(other than making Mr. Hickman laugh, that is <g>)?
===============================================
<?xml version="1.0" encoding="ISO-8859-1" ?>
<job>
<script language="JScript"><![CDATA[
function jsArray(){return(new Array());};
function jsBoolean(){return(new Boolean());};
function jsDate(){return(new Date());};
function jsFunction(){return(new Function());};
function jsGlobal(){return(new Global());};
function jsMath(){return(new Math());};
function jsNumber(){return(new Number());};
function jsObject(){return(new Object());};
function jsRegExp(){return(new RegExp());};
function jsError(){return(new Error());};
function jsString(){return(new String());};
]]></script>
<script language="VBScript"><![CDATA[
Set a = jsArray()
for i = 1 to 10
WScript.Echo a.push(i)
next
do while a.length > 0
wscript.echo a.pop()
loop
]]></script>
</job>
Al Dunbar [MS-MVP]
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:u41ZvHu...@tk2msftngp13.phx.gbl...
> Just woondering whether anyone has done any significant experimentation
with
> using very simplistic wrapups of JScript objects to access them almost
> directly from VBScript, like in the following WSF example.
>
> If anyone has, are there any intriguing uses people have found for this
> (other than making Mr. Hickman laugh, that is <g>)?
"Laugh"? Surely you mean "cry", don't you? ;-)
/Al
Gerry Hickman
> Just woondering whether anyone has done any significant experimentation with
> using very simplistic wrapups of JScript objects to access them almost
> directly from VBScript, like in the following WSF example.
Well I think the example speaks for itself - it's not exactly elegant
(?), and why on earth would anyone want to do this? It would be like
taking a super-efficient PERL web-log parser and saying "look I re-wrote
it in Visaul Basic with MID$ and LEN$", LOL!
Array handling in JScript absolutely KILLS anything VBScript has to
offer, and since arrays are needed all the time, this fact alone seems
to put VBScript out of the running for any serious work. JScript also
makes the distinction between an "enumeration" and an "array".
I've just had another look at the VBScript docs (in case I've be deluded
all these years), and it's JUST AS HORRIBLE as ever!
--
Gerry Hickman (London UK)
Roland Hall
Just wondering, how does one execute client script when it has been disabled
or are you referring to server-side only? One would assume you are
referring only to server-side since only IE supports JScript on the
client-side, does it not? Are you saying JScript overall is more powerful
than VBScript or just relating it to arrays?
I don't think a 'super-efficient' Perl parser compared to the limit of
VBScript mid and len is a true comparison. Isn't programming efficiency
relative to the developer's knowledge and understanding of the language they
are developing in?
"Gerry Hickman" <gerry...@yahoo.co.uk> wrote in message
news:e6ZMW4wp...@TK2MSFTNGP12.phx.gbl...
Bob Barrows
>
> Array handling in JScript absolutely KILLS anything VBScript has to
except multi-dimensional arrays :-)
Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
>> Just woondering whether anyone has done any significant
>> experimentation with using very simplistic wrapups of JScript objects
>> to access them almost directly from VBScript, like in the following
>> WSF example.
>
> Well I think the example speaks for itself - it's not exactly elegant
> (?), and why on earth would anyone want to do this? It would be like
> taking a super-efficient PERL web-log parser and saying "look I re-wrote
> it in Visaul Basic with MID$ and LEN$", LOL!
The real comparison wouild be enabling acess to a Perl web-log parser from
Visual Basic, not rewriting it. And the rationale is the usual one for
interop - making it possible to use tools written in one language from
another. Even though a well-built native VB component that uses API doping
would likely be faster in execution, why rewrite if there's a good one
already available and it can be accessed easily?
> Array handling in JScript absolutely KILLS anything VBScript has to
> offer, and since arrays are needed all the time, this fact alone seems
> to put VBScript out of the running for any serious work. JScript also
> makes the distinction between an "enumeration" and an "array".
OK, you have my permission to do all of your arrays in JScript. :)
Let me point out, however, that arrays and enumerations are not the language
in either JScript or VBScript; they are part of the runtime library, both
logically and in real binary structure. VBScript handles enumerations
available to it just fine.
> I've just had another look at the VBScript docs (in case I've be deluded
> all these years), and it's JUST AS HORRIBLE as ever!
The docs? I actually think they're pretty decent. Not perfect since
real-world use brings to light new things which
Roland Hall
Don't get me wrong, I like JScript/Javascript and VBScript. I use them for
different things but I think overall, VBScript can save a lot of time and
code over trying to work out certain things like getting the hex value of a
number, among other things. I write the function in VBScript to convert the
integer and call it from JScript/Javascript.
Roland
"Bob Barrows" <reb0...@NOyahoo.SPAMcom> wrote in message
news:OtfDEN4p...@TK2MSFTNGP10.phx.gbl...
Bob Barrows
> er.. Bob? That should read Gerry Hickman wrote:, not I.
>
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
> Array handling in JScript absolutely KILLS anything VBScript has to
> offer, and since arrays are needed all the time, this fact alone seems
> to put VBScript out of the running for any serious work.
Gerry, I've had to come back and think about this a couple of times, and I'm
not sure I follow you on the details...
I'm not clear on what "KILLS" means. I think the second item means that you
find sets of indexed items to be used in a wide variety of situations, which
is true - everywhere is stretching the point, but if were not possible to
handle a group of objects in a language at all it would be a serious
impairment.
I just don't see how the well-known differences between a JScript array and
a VB array translate directly into VBScript being "out of the running" for
any serious work. In fact, if one is working in VBScript and needs
something with precisely the behavior of a JScript array, it is directly
available. Or am I missing something here?
SIDE NOTE, for people here who aren't that familiar with JScript: its
runtime library has an Array object accessible which benefits from
object-oriented design. Although this Array cannot be multidimensional in
the classical sense, it provides a large range of native methods for basic
1-D array manipulation. Eliminating certain redundant elements, the critical
methods which are available consist of concat, join, pop, push, reverse,
shift, slice, sort, splice, unshift, and length. This feature is not a
detail of the syntactic language, of course, but runtime library which is
instantiated automatically.
Alex K. Angelopoulos [MVP]
And you forgot to mention the speed difference, too. <g>
Gerry Hickman
> Just wondering, how does one execute client script when it has been disabled
> or are you referring to server-side only?
I'm referring to all, (ASP on web server, Admin of network, WMI, ADSI,
ADO, WBEM, patch management etc. etc.) no one in their right mind would
use VBScript for browser client side, in fact after reading the last few
posts I'm worndering why anyone would use VBScript for ANYTHING? Alex
proved twice that it's inferior, and he's like a GOD! According to the
Microsoft site the reason for writing examples in VBScript is because
it's "easier to learn". Well I'm sorry, but this isn't playschool, this
is the world of big-iron networks and big-bucks enterprise computing. I
don't care about "easy to learn", I care about "which is best", and
which most closely aheres to world standards such as the ECMA. It's also
more closely related to PERL (the most superior scripting language) than
VBScript.
Basically, Microsoft refuse to bundle PERL with Windows, so we have to
choose the next best thing.
> client-side, does it not? Are you saying JScript overall is more powerful
> than VBScript or just relating it to arrays?
Not more powerful, just "better". I don't want "Wend" and "End Sub" in
my code, waste of space and looks like something from high-school. I
don't want LBound and UBound, it looks like something from 1981. As for
the Arrays, they're just plain silly.
> I don't think a 'super-efficient' Perl parser compared to the limit of
> VBScript mid and len is a true comparison.
I think it's a good example. What's the point of wrapping it up in VB
when you can just call it direct? Alex is saying "look I wrapped this
up", and I'm saying "yes but why".
Gerry Hickman
>>Array handling in JScript absolutely KILLS anything VBScript has to
>
> except multi-dimensional arrays :-)
Personally, I've never worried about this "limitation", in fact I don't
see it as a limitation, I see it as a plus; it's just like using
pointers in C. Each element can be an object, so you can really do what
ever you like. Actually, I think the Arrays in JScript are key here.
Multi-Dim Arrays in VBScript look like something out of a 1980s "QBasic
for Beginners" guide to me.
Gerry Hickman
> The real comparison wouild be enabling acess to a Perl web-log parser from
> Visual Basic, not rewriting it.
Yes, bad choice of words. Let me put it this way, why write a wrapper
for VB when you can call it direct?
> And the rationale is the usual one for
> interop - making it possible to use tools written in one language from
> another.
Yes, I completely agree we need interop, but not between JScript and
VBScript! Maybe between .NET and Apache/Solaris or whatever.
> Even though a well-built native VB component that uses API doping
> would likely be faster in execution, why rewrite if there's a good one
> already available and it can be accessed easily?
Again, I say, why not just call it direct? The superior language is
sitting there, but for some reason everyone wants to "call it from
something else", making life far more complicated than it should be?
> Let me point out, however, that arrays and enumerations are not the language
> in either JScript or VBScript; they are part of the runtime library, both
> logically and in real binary structure. VBScript handles enumerations
> available to it just fine.
Yes, but we're talking about the languages, NOT the runtime. I'm just
saying JScript makes the distinction.
> The docs? I actually think they're pretty decent. Not perfect since
> real-world use brings to light new things which
I don't mean the docs are bad, I mean the docs have reminded me just bad
VBScript is!
Torgeir Bakken (MVP)
> I'm referring to all, (ASP on web server, Admin of network, WMI, ADSI,
> ADO, WBEM, patch management etc. etc.) no one in their right mind would
> use VBScript for browser client side, in fact after reading the last few
> posts I'm worndering why anyone would use VBScript for ANYTHING? Alex
> proved twice that it's inferior, and he's like a GOD! According to the
> Microsoft site the reason for writing examples in VBScript is because
> it's "easier to learn". Well I'm sorry, but this isn't playschool, this
> is the world of big-iron networks and big-bucks enterprise computing. I
> don't care about "easy to learn", I care about "which is best", and
> which most closely aheres to world standards such as the ECMA. It's also
> more closely related to PERL (the most superior scripting language) than
> VBScript.
Hi
One of the reason we choose VBScript over JScript for admin scripting was that
JScript has some issues with COM interfaces (e.g. ByRef) that VBScript does not
have. We use 3rd party and in-house COM objects heavily from scripts, so this was
important for us.
--
torgeir
Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of the 1328 page Scripting
Guide: http://www.microsoft.com/technet/scriptcenter
Gerry Hickman
> different things but I think overall, VBScript can save a lot of time and
> code over trying to work out certain things like getting the hex value
OK, but that's very much a "beginner" way of looking at it. Beginners
like VBScript because it has dozens of keywords and functions, but when
you get onto more serious projects, the fewer keywords the better. You
only have to look at the JScript docs to see this is true; much more
streamlined than what you see for VBScript. The tools for hex are there
in JScript and I'd say are also more powerful in terms of what you can
do (shifting etc). It takes five more minutes to write your first ever
hex function in JScript, but once it's in your codelib, that's it! If
you look at advanced Math functions, I think you'll find
ECMA/JavaScript/JScript comes to the fore quite early on.
Gerry Hickman
> And you forgot to mention the speed difference, too. <g>
What's this? You've written some fancy code that proves VBScript arrays
are faster than JScript Arrays?
Gerry Hickman
> I'm not clear on what "KILLS" means.
As in:
.NET running on IIS 'KILLS' PHP running on Apache
C 'KILLS' QBasic
C++ 'KILLS' Visual Basic
PERL 'KILLS' VBScript and JScript
JScript 'KILLS' VBScript
C# 'KILLS' JScript.NET and VB.NET
> I think the second item means that you
> find sets of indexed items to be used in a wide variety of situations, which
> is true - everywhere is stretching the point,
Well, I'm looking at my script folder now, and regardless of whether I'm
doing FileSynch, ADSI, ADO, HTA, WMI or WSH, they all require good Array
handling and good Enumerations. (e.g. Array of file objects, Array of
domain users, Array of exclusion list items, Array of <OPTIONS>, Array
of NetBIOS names, Array of default gateways). These are all real-world
tasks, and having decent Array handling is essential to me, and (I
believe) saves me hours in the long run.
> I just don't see how the well-known differences between a JScript array and
> a VB array translate directly into VBScript being "out of the running" for
> any serious work.
Well that's how I feel based on the above...
> In fact, if one is working in VBScript and needs
> something with precisely the behavior of a JScript array, it is directly
> available. Or am I missing something here?
So why the wrapper?
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
>
>> And you forgot to mention the speed difference, too. <g>
>
> What's this? You've written some fancy code that proves VBScript arrays
> are faster than JScript Arrays?
Yes, although its intuitive if someone looks closely at the manner in which
a VBArray and a JSArray work. For statically sized arrays, the time to fill
an array seems to be roughly an exponential function of array size for
JScript; for VBScript, it appears to be nearly linear. If you experiment
around with different indices in the following code examples, you can see
this.
dim t: t = timer
dim a(500000)
for i = 0 to ubound(a)
a(i) = i
next
t = timer - t
WScript.Echo t
var t = new Date();
var a = new Array(500000);
for (i = 0; i <= 500000; i++) {
a[i] = i;
}
t = new Date() - t;
WScript.Echo(t);
That's a very specific case, though, and although they have the same names,
they are not both arrays in the same sense so this comparison - like most of
specific elements in JScript and VBScript - are to a great extent
comparisons of apples and oranges.
Alex K. Angelopoulos [MVP]
That's not scripting language. That's a library routine, written in C++.
JScript has no truly internal math functions. If you want to argue
languages, my choice of dueling grounds is syntax.
If you confine yourself to syntax, there are still enough ugly bits to pick
on. :)
Alex K. Angelopoulos [MVP]
> ..., in fact after reading the last few
> posts I'm worndering why anyone would use VBScript for ANYTHING? Alex
> proved twice that it's inferior...
No. I've just pointed out some intriguing things available in JScript's
runtime library that are not in VBScript's runtime library. Remember, the
library is not the language.
>..., and he's like a GOD!
You must have seen my "George Burns" Halloween costume. :)
> ... According to the
> Microsoft site the reason for writing examples in VBScript is because
> it's "easier to learn". Well I'm sorry, but this isn't playschool, this
> is the world of big-iron networks and big-bucks enterprise computing. I
> don't care about "easy to learn", I care about "which is best", and
> which most closely aheres to world standards such as the ECMA. It's also
> more closely related to PERL (the most superior scripting language) than
> VBScript.
I'll bite on this Gerry: give me your definition of best.
> Basically, Microsoft refuse to bundle PERL with Windows, so we have to
> choose the next best thing.
Stop it!!! <g>
They like Perl. They encourage it; they haven't bundled it with Windows,
but there has not been a groundswell of users asking for it. There has
never been a refusal, and if enough people asked and demonstrated that they
were indeed using it, they would bundle it.
> Not more powerful, just "better". I don't want "Wend" and "End Sub" in
> my code, waste of space and looks like something from high-school.
This is indeed a core language element - syntax. I understand that Wend may
appear ugly to you, and "End Sub" as well.
They may also appear to be needlessly "wasteful" in a sense to you. A
minimalist, orthogonal language could be constructed that would, for
example, merely use the keyword "function" for all procedures, then cue
actual code start and end with a simple construct like {} as JScript and
others. This would eliminate the use of End If, End While, Loop, Wend, End
Sub, End With, End Function, End Property, End Class, Next, etc.
Is that what your point is about Wend and End Sub?
> don't want LBound and UBound, it looks like something from 1981. As for
> the Arrays, they're just plain silly.
This goes back to the issue of transitional learning and evolutionary growth
of languages. Since you don't like VBScript arrays, though, it's a moot
point; you would use another library object instead.
> I think it's a good example. What's the point of wrapping it up in VB
> when you can just call it direct? Alex is saying "look I wrapped this
> up", and I'm saying "yes but why".
What's the point in recoding and calling it direct when you can just call it
externally? <g>
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
>> I'm not clear on what "KILLS" means.
>
> As in:
> .NET running on IIS 'KILLS' PHP running on Apache
> C 'KILLS' QBasic
> C++ 'KILLS' Visual Basic
> PERL 'KILLS' VBScript and JScript
> JScript 'KILLS' VBScript
> C# 'KILLS' JScript.NET and VB.NET
Got it - 'KILLS' means "is roughly contemporaneous with, and may or may not
be used for the same problem set as..."
>> I think the second item means that you
>> find sets of indexed items to be used in a wide variety of situations,
>> which is true - everywhere is stretching the point,
>
> Well, I'm looking at my script folder now, and regardless of whether I'm
> doing FileSynch, ADSI, ADO, HTA, WMI or WSH, they all require good Array
> handling and good Enumerations. (e.g. Array of file objects, Array of
> domain users, Array of exclusion list items, Array of <OPTIONS>, Array
> of NetBIOS names, Array of default gateways). These are all real-world
> tasks, and having decent Array handling is essential to me, and (I
> believe) saves me hours in the long run.
VBScript's arrays work fine for this for me. I've written code to provide
specialty methods to array constructs, but it was a thought experiment -
never had a real use for it.
One thing that also de-emphasizes arrays for me, though, is that I tend to
write most admin scripts anymore as stream-oriented widgets, so I'm really
dealing with simple alphanumerics passed sequentially.
>> I just don't see how the well-known differences between a JScript
>> array and a VB array translate directly into VBScript being "out of
>> the running" for any serious work.
>
> Well that's how I feel based on the above...
In that case, it doesn't matter. I won't force you to use VBScript. We'll
save that until the VBScript Anti-Defamation League kidnaps you.
>> In fact, if one is working in VBScript and needs
>> something with precisely the behavior of a JScript array, it is
>> directly available. Or am I missing something here?
>
> So why the wrapper?
Because they didn't expose those classes correctly for general use from
COM-enabled languages. The classes are very elegant, though, even if they
are overkill for most situations.
Gerry Hickman
Yes, this is sometimes cited as a reason. I'm not exactly sure which
components exhibit the problem, but it's not something I've run into
personally.
Torgeir Bakken (MVP) wrote:
> Gerry Hickman wrote:
> One of the reason we choose VBScript over JScript for admin scripting was that
> JScript has some issues with COM interfaces (e.g. ByRef)
--
Gerry Hickman (London UK)
Al Dunbar [MS-MVP]
For once, I will agree with you. Except that I would only be applying the
nasty adjective to the "VBScript docs", and not "VBScript" by itself...
/Al
Al Dunbar [MS-MVP]
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
Although you are doing a much better job than I could of defending vbscript
against the infidel :-), I am going to add my two bits here.
Gerry mentioned earlier his loathing for ubound and lbound (among many other
built-in functions), saying (if I were to trust my memory) that JScript is
much simpler, as it doesn't have all of those functions, throwback to the
yesteryear of programming.
And now you give us a mini-tutorial on the JScript "Array" object, that
comes along with what appears to be as syntactically kludgy and
old-fashioned as lbound/ubound - at least to me, they do.
Sure, they are in the library and not "part of the language". But if
JScript's native arrays were so good, what would be the need of the array
object? And if they are not so good that the object is necessary, well,
then, the effect on the programmer is much the same, whether the hated
"functions" are functions or object methods.
/Al
Roland Hall
considered a beginner. :(...
"Gerry Hickman" <gerry...@yahoo.co.uk> wrote in message
news:el315m8p...@TK2MSFTNGP09.phx.gbl...
Gerry Hickman
> an array seems to be roughly an exponential function of array size for
> JScript; for VBScript, it appears to be nearly linear.
Interesting, but importance in real-life would be rare. I mean if you're
iterating over 100 computers and applying a patch, the few extra
microseconds you save will be blown away by the time it takes to
instantiate an RPC session and run the remote process.
If one were doing numerical analysis, that would be valid, but then you
would not be using script anyway, you'd be using C or whatever.
Gerry Hickman
>>proved twice that it's inferior...
>
> No. I've just pointed out some intriguing things available in JScript's
> runtime library that are not in VBScript's runtime library. Remember, the
> library is not the language.
But this doesn't help the poor scripter at all. Unless he's going dump
the WSH libs and write his own script engine or something, we have to
live with what we have - JScript and VBScript. You proved that JScript
is better for dates, better for Arrays(), and more closely adheres to
world standards, proving my point that it's better.
I think it's a valid debate; choosing languages and tools for big
enterprise projects in a minefield; you have to try and predict what
will last, and what you can maintain for months/years down the line.
I chose JScript in the early days, before VBScript had regex handling
and Classes. I made the right choice, because all that code is still
viable today; my friends who chose VBScript (back then) had to re-write
everything from scratch. I also get the advantage (like John Stockton)
of being able to jump client/server with ONE language; why would anyone
want to mess around with 2 languages when there's no need? In some ways
JScript kills PERL in this regard, because you can't do client browser
stuff in PERL; with JScript you can do anything and everything!
JScript does have a few "issues" though
1. If you add a custom method to the built-in Array object, it skews the
indicies by one! However, since you can't do this in VBScript anyway (to
my knowledge), it's not a point of competition. The simple solution is
just not to do it.
2. In WMI, you can't pass parameters into some provider objects all on
one line in JScript. Instead you have to use the InParameters object. At
first I found this horrible, but I've actually come to like it. It makes
for very concise code, and once it's wrapped in a higher level function
you don't notice it. I've no idea why this happens.
3. You can't use SAFEARRAYS directly with JScript, so you have to
construct a dictionary object first, but it's one tiny function and once
you've got it, this also goes away. I don't know if this is a limitation
of JScript, my guess is that it's more to do with the underlying workings.
>>Basically, Microsoft refuse to bundle PERL with Windows, so we have to
>>choose the next best thing.
> They like Perl. They encourage it; they haven't bundled it with Windows,
> but there has not been a groundswell of users asking for it.
Unless you know something I don't, I completely dispute this. There's
not a shred of evidence on Microsoft's Scripting sites that they "like
PERL". The only time they came close to endorsing it was with the NT4
resource kit, and even then you had to pay, and it was hidden in a
sub-folder.
> There has
> never been a refusal, and if enough people asked and demonstrated that they
> were indeed using it, they would bundle it.
This isn't how it works; Windows didn't get VBScript because people
"asked" for it, it got there because Microsoft put it there. It's not a
democratic process! Microsoft decides what people want, NOT the people.
If the latter were true we'd not have talking paper clips and
anti-privacy policies in WMP9 and DirectX.
> They may also appear to be needlessly "wasteful" in a sense to you. A
> minimalist, orthogonal language could be constructed that would, for
> example, merely use the keyword "function" for all procedures, then cue
> actual code start and end with a simple construct like {} as JScript and
> others. This would eliminate the use of End If, End While, Loop, Wend, End
> Sub, End With, End Function, End Property, End Class, Next, etc.
>
> Is that what your point is about Wend and End Sub?
Yes, that's what I'm saying, it's a waste of space and offensive to the
eyes!
> What's the point in recoding and calling it direct when you can just call it
> externally? <g>
Yes, the wise scripter would have chosen the "correct" language in the
first place <g>
Gerry Hickman
> Got it - 'KILLS' means "is roughly contemporaneous with, and may or may not
> be used for the same problem set as..."
No, it means "is better than". I think my examples are fair, based on
the problem set they'd be expected to solve?
> One thing that also de-emphasizes arrays for me, though, is that I tend to
> write most admin scripts anymore as stream-oriented widgets, so I'm really
> dealing with simple alphanumerics passed sequentially.
Really? So let's say you had an array of <OPTION> elements ready for a
<SELECT> element (each of which is an object in itself). How would you
do this using streams?
> Because they didn't expose those classes correctly for general use from
> COM-enabled languages.
Well I completely AGREE with this part!
Gerry Hickman
> Gerry mentioned earlier his loathing for ubound and lbound
Hey don't try to make them look "neat" by using all lower case <g>!
> (among many other
> built-in functions), saying (if I were to trust my memory) that JScript is
> much simpler, as it doesn't have all of those functions, throwback to the
> yesteryear of programming.
That's right. None of this LEN$, MID$ nonsense. No 'End If', 'End Sub',
'Wend' and so on. Just lean and clean all the way.
> And now you give us a mini-tutorial on the JScript "Array" object, that
> comes along with what appears to be as syntactically kludgy and
> old-fashioned as lbound/ubound - at least to me, they do.
I must have missing this part; how can push, pop and length be "Kludgy",
it's straight from the excellent ANSI compliant STD<> template libs. A
work of ART compared to a[i][j]=20, LOL!
> Sure, they are in the library and not "part of the language". But if
> JScript's native arrays were so good, what would be the need of the array
> object?
I'm not sure I follow?
> And if they are not so good that the object is necessary,
Again I don't follow, you just type Array() and it works, it's always
been there in JScript...? Are you saying that calls in VBScript are
somehow more "native" than those of JScript?
Gerry Hickman
> No wonder nobody will hire me. After 25 years of programming, I'm still
> considered a beginner. :(...
LOL! I knew this would be taken the wrong way. I didn't say YOU were a
beginner, I said it's a "beginner way of looking at it".
My point was that beginners tend to get stuck as soon as there's no
built-in function to do what they're trying to do. Instead of "feeling
the force" and jumping straight into bitwise arithmetic, they get
annoyed when they can't find the HEX$ function (or whatever).
I've just had another look at VBScript operators - HORRIBLE!
String concatenation and special characters such as TAB and NEWLINE,
elegant in JScript but it's a joke in VBScript right? Where's the C++
style increment and decrement operators? Intead of the intuitive '!'
symbol for negation, you have an ugly keyword 'NOT', hehehehe!
Al Dunbar [MS-MVP]
> Al Dunbar [MS-MVP] wrote:
> > Gerry mentioned earlier his loathing for ubound and lbound
>
> Hey don't try to make them look "neat" by using all lower case <g>!
Sorry, I was just a bit lazy there... ;-)
> > (among many other
> > built-in functions), saying (if I were to trust my memory) that JScript
is
> > much simpler, as it doesn't have all of those functions, throwback to
the
> > yesteryear of programming.
>
> That's right. None of this LEN$, MID$ nonsense. No 'End If', 'End Sub',
> 'Wend' and so on. Just lean and clean all the way.
... until you decide to use the Array() object, apparently ...
> > And now you give us a mini-tutorial on the JScript "Array" object, that
> > comes along with what appears to be as syntactically kludgy and
> > old-fashioned as lbound/ubound - at least to me, they do.
>
> I must have missing this part; how can push, pop and length be "Kludgy",
> it's straight from the excellent ANSI compliant STD<> template libs. A
> work of ART compared to a[i][j]=20, LOL!
Kludginess is in the eye of the beholder, to some extent. I don't happen to
use lots of arrays in my miniscule admin scripting, and very few (if any)
multidimensional arrays. Alex said:
"Eliminating certain redundant elements, the critical methods which are
available consist of concat, join, pop, push, reverse, shift, slice, sort,
splice, unshift, and length. This feature is not a detail of the syntactic
language, of course, but runtime library which is instantiated
automatically."
(Coming originally from Fortran in a galaxy far, far away) I am more
comfortable in a more syntactically sparse environment where the main
"method" of an array is: "here is a list of values...". Yes, I realize that
vbscript includes functions that are somewhat more than primitive, but I
would say the same of the above list. More so, in fact. Since I started
scripting with vbscript (well, after batch), and have found it sufficient
for my purposes, I have not felt the need to either look for anything
better, or to investigate what others say might be better. This might change
in time, but there is nothing forcing me to do so now.
> > Sure, they are in the library and not "part of the language". But if
> > JScript's native arrays were so good, what would be the need of the
array
> > object?
>
> I'm not sure I follow?
You say JScript is syntactically simple in and of itself (and I can't
disagree). But then it needs/uses these objects automatically instantiated
from a library which I (coming from a Fortran background and NOT a C one)
find to be doing things that I do not need done or would do in a different
way, and which have their own details that one needs to learn (never mind
someone coming from C would perhaps have less to learn).
Take string parsing, for example. I don't like the MID$, INSTR$, and etc
functions either, but manage to get lots done with vbscript's split and join
functions. One example: a routine that reads kixtart script, converting all
assignment statements (with and without endline comments, with and without
string delimeters ['] and ["]) to produce an equivalent *.ini file. I'd have
gone nuts trying to walk through the source with mid and instr, but things
fell into place rather quickly for me with split and join. Of course a C
purist would not like the fact that more CPU cycles than the absolute
minimum were burned; I don't care about that, however, as the more expensive
resource in my case was the development time.
> > And if they are not so good that the object is necessary,
>
> Again I don't follow, you just type Array() and it works, it's always
> been there in JScript...? Are you saying that calls in VBScript are
> somehow more "native" than those of JScript?
No, I'm not saying that. Perhaps my lack of knowledge of JScript (strike
that word "perhaps") is getting in the way of me explaining why it does not
appeal to me. All I am trying to say is JScript seems to me harder to follow
and read. Yeah, I know I will eventually give it a go, and when I do I will
have to "brace" myself. Until then, I do not have any particular quarrels
with "End if" (except that I would have preferred it be one word), "End
Sub", and etc. I don't like WHILE-WEND, however, preferring the more
complete DO-LOOP with WHILE/UNTIL at the top or bottom.
Having said this, I am not trying to convince you that you are wrong to
dislike the syntax; just that you are wrong to say that I am wrong to like
it enough to use it.
/Al
Roland Hall
I can just see you sitting there reading the latest from:
-=Perl Dude=-
Superior Scripting for Superior Minds (subliminal marketing slogan...works
like a charm..*giggle*)
...when all of a sudden your [Perl induced] buddies come over and y'all
start shootin' the s**t. !!! (<- see bang) Suddenly to liven things up you
pull out an old tattered "VBScript for Dummies!" you obtained when one day
you saw someone walking against the light who was hit by a truck. His books
flying into the air and this one, this mysterious looking yellow and black
book passing itself off information on scripting. You chuckle beneath your
breath as you pick it up take it with you. That 'dummy' won't be needing it
anymore anyhow. As you wave the book in the air and scream out, "OMG! What
is this?", there is a moment of silence and then you all, in surround-sound,
cry out, "HORRIBLE!" You all get a good laugh, someone sighs, and the mood
has passed. Still feeling the fire, you get online, head to
msnews.microsoft.com and continue your assault on the VBScript community
with only one thing in mind, "CONVERT OR DIE!...
KILL!...KILL!...KILL!"(Hitchcock's "Psycho" bathroom scene music plays in
background).
No, I've never taken any screen writing lessons but I did stay in a Holiday
Inn Express last night... ~sigh~
I didn't take offense and although I think you're obsessed with wanting to
single-handedly convert everyone away from VBScript and towards Perl (the
easy scripting language), I don't see you as offensive, just out there, like
the rest of us.
I'll never convert but then I don't rate VBScript against
Jscript/JavaScript. I've been writing in JavaScript so long and VBScript
for ASP that I'm not as up to date with VB as I'd like to be. Currently I'm
finding C# to be an easier transition instead of VB for .NET.
I thought ! = bang and you're saying that it should be read as 'thought !=
bang' which means thought NOT EQ bang. How confusing. In networking it's
bang and in programming it's NOT? *smirk*
How does the parser interpret <!--? Does it mean start of HTML comment
block or LESS THAN NOT LESS THAN MINUS LESS THAN?
Why is in an HTML comment block if it's within a script block? I'm so
confused. *holds head and screams silently within*
"Gerry Hickman" <gerry...@yahoo.co.uk> wrote in message
news:uGICKeJq...@TK2MSFTNGP09.phx.gbl...
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
>> an array seems to be roughly an exponential function of array size for
>> JScript; for VBScript, it appears to be nearly linear.
>
> Interesting, but importance in real-life would be rare. I mean if you're
> iterating over 100 computers and applying a patch, the few extra
> microseconds you save will be blown away by the time it takes to
> instantiate an RPC session and run the remote process.
Depends on the way that you do things; the memory loading is what would
really be important.
> If one were doing numerical analysis, that would be valid, but then you
> would not be using script anyway, you'd be using C or whatever.
I used to think that too, but there are some intriguing possibilities
inherent in doing scientific computing in scripting languages. It would be
ridiculous to use it for intensive FEA, but scripting is marvelous for most
flexible problem sets where user time is significantly more valuable than
computational time. Most algorithms can be benchmarked in script on modern
PCs as executing in substantially less real time than the same algorithms in
binary code on PCs of 5 years ago, so absolute time is not an issue.
Python has made a substantial name for itself here, as has Ruby; NASA has
been occasionally working with both for specific purposes for the past few
years.
This is actually a pretty interesting topic area. The intriguing thing is
that for many real-world problems, neither end-to-end performance nor
calculation accuracy is noticeably affected by using scripting languages.
Alex K. Angelopoulos [MVP]
> Roland Hall wrote:
>> No wonder nobody will hire me. After 25 years of programming, I'm
>> still considered a beginner. :(...
>
> LOL! I knew this would be taken the wrong way. I didn't say YOU were a
> beginner, I said it's a "beginner way of looking at it".
>
> My point was that beginners tend to get stuck as soon as there's no
> built-in function to do what they're trying to do. Instead of "feeling
> the force" and jumping straight into bitwise arithmetic, they get
> annoyed when they can't find the HEX$ function (or whatever).
>
> I've just had another look at VBScript operators - HORRIBLE!
>
> String concatenation and special characters such as TAB and NEWLINE,
> elegant in JScript but it's a joke in VBScript right?
I don't get it. You don't like Tab and Newline?
> ... Where's the C++
> style increment and decrement operators?
I just checked, and they're still in my C++ compilers. Maybe your compiler
has a leak?
>... Intead of the intuitive '!'
> symbol for negation, you have an ugly keyword 'NOT', hehehehe!
Exactly the point. "!" is nice, but most people don't recognize that it is
usable for "Not".
Alex K. Angelopoulos [MVP]
> ...Where's the C++
> style increment and decrement operators?
If C++ has taught me one thing, it's this: a system can be consistent and
still be the work of Satan.
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
>> Got it - 'KILLS' means "is roughly contemporaneous with, and may or
>> may not be used for the same problem set as..."
>
> No, it means "is better than". I think my examples are fair, based on
> the problem set they'd be expected to solve?
Problem sets vary. If we have to pick a single problem set to deal with,
though, we might as well pick the trendiest - then we'll see that the
problem is really something different:
http://weblog.burningbird.net/fires/000581.htm
Alex K. Angelopoulos [MVP]
> Having said this, I am not trying to convince you that you are wrong to
> dislike the syntax; just that you are wrong to say that I am wrong to
> like it enough to use it.
Al, I think syntax sums up a great deal about why VBScript is so valuable
for so many people.
The general family VBScript belongs to is languages which have a LOT of
redundancy in constructs. This makes code longer and gives the parser more
headaches, but gives more contextual clues to meaning and structure and
allows easier transference of natural language skills.
It's not reflexively self-similar, it's not imperative, it's not
super-efficient. It can't run on Unix. It doesn't support one-sided
operators. If you don't need those, though, it's a pretty fun language. :)
Gerry Hickman
>>That's right. None of this LEN$, MID$ nonsense. No 'End If', 'End Sub',
>>'Wend' and so on. Just lean and clean all the way.
>
> ... until you decide to use the Array() object, apparently ...
Not at all, the JScript Array() object is the most superior
implementation of array handling ever conceived in a scripting language,
except perhaps PERL. It's clean, has plenty flexibility and it's code is
easy to read. Much better than a[i][j]=20, For x = LBound(a) ...
> Kludginess is in the eye of the beholder, to some extent.
Well if you call this kludgy, you must be calling the ANSI and ECMA
kludgy too, because that's EXACTLY what they prescribe.
> (Coming originally from Fortran in a galaxy far, far away) I am more
> comfortable in a more syntactically sparse environment where the main
> "method" of an array is: "here is a list of values...".
And that's exactly what you get in JScript. None of this "dimentions"
nonsense and "bounds", what's that for? The computer doesn't care about
dimensions or bounds, it's just contiguous memory, it's only put there
so the lesser humans can cope.
> scripting with vbscript (well, after batch), and have found it sufficient
> for my purposes,
I nearly fell into the same trap when I started with ASP on IIS4, mainly
due to Microsoft's illogical promotion of VBScript, but quickly realized
JScript was better.
> You say JScript is syntactically simple in and of itself (and I can't
> disagree). But then it needs/uses these objects automatically instantiated
> from a library which I (coming from a Fortran background and NOT a C one)
> find to be doing things that I do not need done or would do in a different
> way, and which have their own details that one needs to learn (never mind
> someone coming from C would perhaps have less to learn).
But this is even WORSE in VBScript! You don't HAVE to use an Array()
object in JScript if you don't want one, it's just there if you need it.
> Having said this, I am not trying to convince you that you are wrong to
> dislike the syntax; just that you are wrong to say that I am wrong to like
> it enough to use it.
I'm not saying you're wrong to like it, I'm just saying JScript is better.
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
>>> posts I'm worndering why anyone would use VBScript for ANYTHING? Alex
>>> proved twice that it's inferior...
>>
>> No. I've just pointed out some intriguing things available in JScript's
>> runtime library that are not in VBScript's runtime library. Remember,
>> the library is not the language.
>
> But this doesn't help the poor scripter at all. Unless he's going dump
> the WSH libs and write his own script engine or something, we have to
That's one of the beautiful things about VBScript. I don't have to write my
own script engine; I just use other tools that are available from inside
VBScript. VBScript is not a programming language, it is a glue.
(Javascript can be that way as well, although it has a few minor limitations
due to design - event-driven programming seems to be annoying, for example
:P ).
>... You proved that JScript
> is better for dates, better for Arrays(), and more closely adheres to
> world standards, proving my point that it's better.
Did not! (bonk!!)
The JScript Date() classes have a more well-rounded implementation for
international manipulation; since nothing else is a JScript Array(), of
course nothing else is as good at being a JScript Array(); and world
standards compliance depends. It certainly is ECMA-262 compliant generally -
;). It enshrines terminology which directly contradicts ISO-8601 as well,
though.
If we want to make a sweeping statement along these lines, I've just proven
that all imperative languages are inferior to JScript also. I don't this is
true though, and I think you're focusing on the wrong set of issues if you
want to make an abstract judgment about good and bad.
> I think it's a valid debate; choosing languages and tools for big
> enterprise projects in a minefield; you have to try and predict what
> will last, and what you can maintain for months/years down the line.
>
> I chose JScript in the early days, before VBScript had regex handling
> and Classes. I made the right choice, because all that code is still
> viable today; my friends who chose VBScript (back then) had to re-write
> everything from scratch. I also get the advantage (like John Stockton)
> of being able to jump client/server with ONE language; why would anyone
> want to mess around with 2 languages when there's no need? In some ways
> JScript kills PERL in this regard, because you can't do client browser
> stuff in PERL; with JScript you can do anything and everything!
Here's where we get into the "what's your context" question. If I was
writing library tools that could be used by any computer in the world, I
would pick Javascript in a heartbeat. In fact, if we picked one criterion
for a single file, being able to run on the most computers in the world in
some way with zero code modification or recompilation, and nothing at all
added to the system beyond the file, javascript would be hands down the
winner: every web browser since the 3.x era supports it, and some systems
support native execution as well.
> JScript does have a few "issues" though
>
> 1. If you add a custom method to the built-in Array object, it skews the
> indicies by one! However, since you can't do this in VBScript anyway (to
> my knowledge), it's not a point of competition. The simple solution is
> just not to do it.
> 2. In WMI, you can't pass parameters into some provider objects all on
> one line in JScript. Instead you have to use the InParameters object. At
> first I found this horrible, but I've actually come to like it. It makes
> for very concise code, and once it's wrapped in a higher level function
> you don't notice it. I've no idea why this happens.
That's one of the effects Torgeir was talking about. JScript always passes
by value instead of by reference.
I assume that InParameters has side effects for garbage collection, then?
> 3. You can't use SAFEARRAYS directly with JScript, so you have to
> construct a dictionary object first, but it's one tiny function and once
> you've got it, this also goes away. I don't know if this is a limitation
> of JScript, my guess is that it's more to do with the underlying
> workings.
I believe this is the byref/byval issue in another guise.
>>> Basically, Microsoft refuse to bundle PERL with Windows, so we have to
>>> choose the next best thing.
>
>> They like Perl. They encourage it; they haven't bundled it with
>> Windows, but there has not been a groundswell of users asking for it.
>
> Unless you know something I don't, I completely dispute this. There's
> not a shred of evidence on Microsoft's Scripting sites that they "like
> PERL". The only time they came close to endorsing it was with the NT4
> resource kit, and even then you had to pay, and it was hidden in a
> sub-folder.
This is a non-issue; I was simply pointing out the fact that there is no
evidence of the refusal, and even an attitude that suggests the opposite.
They don't include it on their website because the version they use is
maintained and developed by ActiveState, and I suspect concerns about
lawsuits from the Open Source movement are another reason they don't
actually provide the software. If you want a good feel for the attitudes
about Perl, you can get a feel for things by Googling Microsoft for Perl.
Here's a few examples:
+ Andrew Clinick probably can be considered the foremost authority on
Microsoft's "scripting" attitude towards Perl. See his "Perl of Wisdom"
article:
http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting012299.asp
+ Check the MSKB; they talk at length about using Perl on systems, primarily
as an IIS-related tool, but of course the web development and Active
Scripting development was tied together.
+ They continue to suggest it, bundle it with the RK, and even tell you how
to get it for free:
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/IISbook/c03_configuring_a_script_interpreter.asp
+ To this day, they use Perl for hardware device driver validation scripts,
and again tell you how to get it; look up ChkInf.
+ As far as current attitudes go, I can tell you that the Windows 2003
Administrator's Companion even used Perl as the scripting language of
choice. The implementation was weak due to time constraints, but the lead
author picked that as the language to use for examples and there was
absolutely zero problem with doing that - in what is supposed to be the lead
book on the latest and greatest OS! (source: lengthy personal communications
with the lead author).
This is really just said by me to convince you that you're barking up the
wrong tree saying they "refuse" to distribute it, other than the sense in
which they "refuse" to distribute other useful applications they don't hold
a copyright for. They do distribute some, but they are ones which are
high-demand minimally-interactive tools, usually for purposes such as disk
defragmentation and terminal emulation.
> > There has
>> never been a refusal, and if enough people asked and demonstrated that
>> they were indeed using it, they would bundle it.
>
> This isn't how it works; Windows didn't get VBScript because people
> "asked" for it, it got there because Microsoft put it there. It's not a
> democratic process! Microsoft decides what people want, NOT the people.
> If the latter were true we'd not have talking paper clips and
> anti-privacy policies in WMP9 and DirectX.
This comes down to they do things that they perceive as making them money on
the system. VBScript was not free to create, but it was cheap. Paper clips
and talking dogs in search boxes make it "pretty".
Writing an internal implementation of Perl, then integrating and debugging
it would not have been cheap, and whatever you may say about it, even Larry
Wall will never claim Perl is "pretty!".
You're talking about a chainsaw, and it would need to be available in a
model that ran silently and came in non-scratch pastel colors to even be in
the running for OS integration.
>> They may also appear to be needlessly "wasteful" in a sense to you. A
>> minimalist, orthogonal language could be constructed that would, for
>> example, merely use the keyword "function" for all procedures, then cue
>> actual code start and end with a simple construct like {} as JScript
>> and others. This would eliminate the use of End If, End While, Loop,
>> Wend, End Sub, End With, End Function, End Property, End Class, Next,
>> etc.
>>
>> Is that what your point is about Wend and End Sub?
>
> Yes, that's what I'm saying, it's a waste of space and offensive to the
> eyes!
This is another "bonk!" item. Ask anyone who deals with linguistics about
the role of redundancy in natural languages. A scripting language is for
gluing by humans, not for computational elegance.
If you're after visual offenses, though, your lack of familiarity with
VBScript betrayed you; you should have picked REM. (I will grant that WEnd
does run a close second to it).
>> What's the point in recoding and calling it direct when you can just
>> call it externally? <g>
>
> Yes, the wise scripter would have chosen the "correct" language in the
> first place <g>
Toooooo late. I glued JScript into VBScript, and it already dried. You have
been "borged". :-)
Gerry Hickman
> msnews.microsoft.com and continue your assault on the VBScript community
> with only one thing in mind, "CONVERT OR DIE!...
> KILL!...KILL!...KILL!"
Hehehehe, yes but Alex post was (quite correctly) cross-posted here, I'm
not even subscribed to the VBScript group. I'm on WSH, otherwise I'd not
be in this thread at all...
> (Hitchcock's "Psycho" bathroom scene music plays in
> background).
LOL!
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
>> Got it - 'KILLS' means "is roughly contemporaneous with, and may or
>> may not be used for the same problem set as..."
>
> No, it means "is better than". I think my examples are fair, based on
> the problem set they'd be expected to solve?
I forgot to mention - Roland and I used your name in vain over in
microsoft.public.windows.server.scripting. See the thread "Prefered
Scripting Language Opinions", thread begins about 21:16 UTC time 2003-11-10.
We're playing rock/paper/scissors with the word KILLS and forgot to invite
you. :)
Oh, yeah, I think I suggested Perl.
Gerry Hickman
> Depends on the way that you do things; the memory loading is what would
> really be important.
I'm not sure I follow, are you saying if I iterate over my 600 computers
in order to apply patches, I'm "overloading" my memory more if I use
JScript than if I were using VBScript?
> I used to think that too, but there are some intriguing possibilities
> inherent in doing scientific computing in scripting languages.
Interestingly I'm writing a forest plotter with client-side JavaScript
and CSS! It's not quite ready yet, but it gives C a run for it's money;
I mean you don't need any kludgy graphics libraries for a start, and
on-screen rendering is almost instant, you can even use DHTML in real
time to adjust the graphs. Not only that, but you don't need any silly
.NET frameworks or Microsoft proprietary technologies, you can run it in
Mozilla for example and it's all compliant with the W3C.
Gerry Hickman
>>String concatenation and special characters such as TAB and NEWLINE,
>>elegant in JScript but it's a joke in VBScript right?
>
> I don't get it. You don't like Tab and Newline?
No, I like \t \n just like they use in REAL programming languages, and
anyway according to the docs, it's vbTab and vbNewLine - more wasted space!
> I just checked, and they're still in my C++ compilers. Maybe your compiler
> has a leak?
Yes, and SOME more forward thinking languages (e.g. PERL, JScript) have
them too!
>>... Intead of the intuitive '!'
>>symbol for negation, you have an ugly keyword 'NOT', hehehehe!
>
> Exactly the point. "!" is nice, but most people don't recognize that it is
> usable for "Not".
But if Microosft had seen the bigger picture five years ago, none of
this would matter, we'd all be using standards compliant languages and
they'd use things like '!' for NOT by default.
This reminds me of when they teach kids "twice" in schools. They first
teach them the "kids" version of the topic, and then the "real" version,
thereby causing confusion and wasting a whole year having to get them to
"unlearn" all the kidstuff, and finally get them to learn it properly.
When I started out it was Fortran, Cobol and Algol. I found it
difficult, and a year later when BASIC came out I was really pleased; it
felt like suddenly I could write programs, but years later I now see
this was the worst thing that could have happened. I was so busy writing
playschool programs in BASIC that when I left college I was
unemployable. Big corporates would just laugh when I said I could "do"
BASIC. If I'd stuck with Algol I could have moved into C and got the top
jobs. As it turned out I was unemployed for over 5 years. I then had to
unlearn all the bad habits of BASIC and start again.
Gerry Hickman
> Problem sets vary. If we have to pick a single problem set to deal with,
> though,
OK, here's my problem set. A massive corporate phones up and they want a
complete overhall of their systems; they're fed up with broken VB
"client applications" from multiple vendors, COM objects that are no
longer supported, an intranet that doesn't work and two databases that
won't talk to each other. They want everything to work from any computer
any time with no installations and they want everything as standards
compliant as possible and in plain text, so they're not locked in to
what I deliver. They want super fast browser objects that snap into
place, and disconnected recordsets on the client so there's not too much
load on the server.
You know it's going to run into thousands of lines of code, you know
you're going to be in trouble if you can't maintain it in three years
time. Which do you choose VBScript or JScript?
Alex K. Angelopoulos [MVP]
And in fact, the only reason I didn't bother crossposting to .jscript
because I knew Gerry would "catch" this via .wsh. <g>
Al Dunbar [MS-MVP]
/Al
"Roland Hall" <nobody@nowhere> wrote in message
news:uHbv0WQq...@TK2MSFTNGP11.phx.gbl...
Al Dunbar [MS-MVP]
> Alex K. Angelopoulos [MVP] wrote:
>
> >>String concatenation and special characters such as TAB and NEWLINE,
> >>elegant in JScript but it's a joke in VBScript right?
> >
> > I don't get it. You don't like Tab and Newline?
>
> No, I like \t \n just like they use in REAL programming languages, and
> anyway according to the docs, it's vbTab and vbNewLine - more wasted
space!
Only wasted if one does not take the opportunity to use the constants as a
form of internal documentation.
> > I just checked, and they're still in my C++ compilers. Maybe your
compiler
> > has a leak?
>
> Yes, and SOME more forward thinking languages (e.g. PERL, JScript) have
> them too!
>
> >>... Intead of the intuitive '!'
> >>symbol for negation, you have an ugly keyword 'NOT', hehehehe!
> >
> > Exactly the point. "!" is nice, but most people don't recognize that it
is
> > usable for "Not".
>
> But if Microosft had seen the bigger picture five years ago, none of
> this would matter, we'd all be using standards compliant languages and
> they'd use things like '!' for NOT by default.
Only way you are going to get this fact to change is to develop a time
machine and go visit Bill in his dad's garage. Hey, with luck, even Steve
will be there!
(oops, sorry for ending that last sentence with a negation - NOT!)
> This reminds me of when they teach kids "twice" in schools. They first
> teach them the "kids" version of the topic, and then the "real" version,
> thereby causing confusion and wasting a whole year having to get them to
> "unlearn" all the kidstuff, and finally get them to learn it properly.
Heh, my son wrote a VB3 adventure-like program in high school. When I asked
him if he used arrays to keep track of where all the objects were that you
could pick up and carry around, he said with a puzzled look: "arrays?". When
I said, "you know, an array is like a set of variables with the same name
and you reference the different elements with a numeric index" he said with
that same puzzled look: "variables"? Apparently he taught himself to
"program" in the same way that he taught himself to use object linking and
embedding in Windows Write.
> When I started out it was Fortran, Cobol and Algol. I found it
> difficult, and a year later when BASIC came out I was really pleased; it
> felt like suddenly I could write programs, but years later I now see
> this was the worst thing that could have happened. I was so busy writing
> playschool programs in BASIC that when I left college I was
> unemployable.
Ahhh, then, it finally dawns on us why you have such a personal distaste for
anything with *BASIC* in the name. All is forgiven.
> Big corporates would just laugh when I said I could "do"
> BASIC. If I'd stuck with Algol I could have moved into C and got the top
> jobs. As it turned out I was unemployed for over 5 years. I then had to
> unlearn all the bad habits of BASIC and start again.
This is as much BASIC's fault as the high murder rate is the responsiblity
of the actual guns themselves... Hey, there are those that would blame bad
practice on someone having started out with FORTRAN IV.
/Al
Al Dunbar [MS-MVP]
Hmmm, you've got me there. Fortuntaely for me, I don't ever work in that
problem domain ;-)
Wait a minute! That is a trick question. Of course you'd be a fool to
propose a vbscript solution to a company that is complaining of broken VB
"client applications"!
/Al
Joe Earnest
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:uPiAm6Uq...@TK2MSFTNGP09.phx.gbl...
Well put, Alex!!! One to add to the Medieval Latin quote.
In fact, philosophically speaking (heh, heh), while a chaotic system may
produce "good" or "bad" results, only a consistent system can be "evil".
(Perl and C++ may be candidates. :-) I want to congradulate you all on
managing to raise, in the context of scripting, many of the same issues as
those in the mass of neo-Hegelian social-state versus anti-(left or
right)Hegelian, anti-totalitarian literature of the 1950's and 1960's. (Is
it apparent that I'm decompensating?)
Regards,
Joe Earnest
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 09-23-03
Joe Earnest
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:uFnM7XVq...@TK2MSFTNGP09.phx.gbl...
| Al, I think syntax sums up a great deal about why VBScript is so valuable
| for so many people.
|
| The general family VBScript belongs to is languages which have a LOT of
| redundancy in constructs. This makes code longer and gives the parser
more
| headaches, but gives more contextual clues to meaning and structure and
| allows easier transference of natural language skills.
|
| It's not reflexively self-similar, it's not imperative, it's not
| super-efficient. It can't run on Unix. It doesn't support one-sided
| operators. If you don't need those, though, it's a pretty fun language. :)
As we've discussed before, this is an ambiguous area and a touchy analogy.
Using a natural language metaphor, it's *sort of* like preferring English,
with its messy, multi-source, mongrel, highly duplicative and redundant
words and syntax, to a "purer" source language with more controlled syntax
and precisely articulate shadings and variations. Learning to express
yourself articulately is simply different from language to language, and one
language may better suit a different personality type. But remember that
articulation is a beneficial side effect of a language, not its driving
force. The great bulk of linguistic use is not in lengthy poetic or
philosophic outpourings, but in pragmatically useful single-phrase
salutations, declarations, exclamations and assertions leading to action.
All successful computer language syntax seems to me to be modeled,
more-or-less, after the mathematical symbolic logic that was the
intellectual rage from the 1910's through the 1960's. I agree that BASIC
was decidedly an American-English vernacular twist on that syntax -- it was
simply and patently (well) conceived as a "common man's" language. Many
other languages try (almost always superficially) to stay closer to the
original mathematical-logical syntax, and quickly fall into a host of
arbitrary non-mathematical and even non-logical syntactical issues. The
revealed point is, I think, that a computer language, to be useful, cannot
be simply logical, and real preferences arise from the way that pragmatic
applications are conceived and handled in the various languages.
Roland Hall
although he prefers you call him Michael.
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:uPiAm6Uq...@TK2MSFTNGP09.phx.gbl...
Roland Hall
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:uUqmsyVq...@TK2MSFTNGP12.phx.gbl...
Alex K. Angelopoulos [MVP]
> .. !!! (<- see bang) ...
Apropos of nothing at all -
Standard spoken Commonwealth Hackish pronounces the character "!" as
"pling".
Alex K. Angelopoulos [MVP]
> Hi Alex,
>
> "Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
> news:uPiAm6Uq...@TK2MSFTNGP09.phx.gbl...
>> Gerry Hickman wrote:
>>
>>> ...Where's the C++
>>> style increment and decrement operators?
>>
>> If C++ has taught me one thing, it's this: a system can be consistent
>> and still be the work of Satan.
>
> Well put, Alex!!! One to add to the Medieval Latin quote.
Actually I think I stole that line. So my 15 minutes of fame is denied. :(
> In fact, philosophically speaking (heh, heh), while a chaotic system may
> produce "good" or "bad" results, only a consistent system can be "evil".
> (Perl and C++ may be candidates. :-) I want to congradulate you all on
> managing to raise, in the context of scripting, many of the same issues
> as those in the mass of neo-Hegelian social-state versus anti-(left or
> right)Hegelian, anti-totalitarian literature of the 1950's and 1960's.
> (Is it apparent that I'm decompensating?)
So philosophically speaking... although people have written good code and
bad code in the various versions of Basic over the years, no one has ever
written truly evil code in Basic...?
SCORE!!!!!
Alex K. Angelopoulos [MVP]
> Hi Alex,
>
> "Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
> news:uFnM7XVq...@TK2MSFTNGP09.phx.gbl...
>> Al, I think syntax sums up a great deal about why VBScript is so
>> valuable for so many people.
>>
>> The general family VBScript belongs to is languages which have a LOT of
>> redundancy in constructs. This makes code longer and gives the parser
>> more headaches, but gives more contextual clues to meaning and
>> structure and allows easier transference of natural language skills.
>>
>> It's not reflexively self-similar, it's not imperative, it's not
>> super-efficient. It can't run on Unix. It doesn't support one-sided
>> operators. If you don't need those, though, it's a pretty fun
>> language. :)
>
> As we've discussed before, this is an ambiguous area and a touchy
> analogy.
shhhh... That's why used the phrase "transference of natural language
skills". There are things that still escape me from that discussion, but it
stood out quite clearly that I could not refer to it as being natural.
> ... Using a natural language metaphor, it's *sort of* like
> preferring English, with its messy, multi-source, mongrel, highly
> duplicative and redundant words and syntax, to a "purer" source
> language with more controlled syntax and precisely articulate shadings
> and variations. Learning to express yourself articulately is simply
> different from language to language, and one language may better suit a
> different personality type. But remember that articulation is a
> beneficial side effect of a language, not its driving force. The great
> bulk of linguistic use is not in lengthy poetic or philosophic
> outpourings, but in pragmatically useful single-phrase salutations,
> declarations, exclamations and assertions leading to action.
>
> All successful computer language syntax seems to me to be modeled,
> more-or-less, after the mathematical symbolic logic that was the
> intellectual rage from the 1910's through the 1960's. I agree that
> BASIC was decidedly an American-English vernacular twist on that syntax
> -- it was simply and patently (well) conceived as a "common man's"
> language. Many other languages try (almost always superficially) to
> stay closer to the original mathematical-logical syntax, and quickly
> fall into a host of arbitrary non-mathematical and even non-logical
> syntactical issues. The revealed point is, I think, that a computer
> language, to be useful, cannot be simply logical, and real preferences
> arise from the way that pragmatic applications are conceived and
> handled in the various languages.
Vaguely related to this, I showed someone who is completely unfamiliar with
computing languages some comparative examples last night, asking her to give
an honest opinion of which was easier to understand on sight. Here's the
conversation between myself and our test audience (I'll call her "T").
A: "Here is something written in the warm, friendly, natural language we
will call simply #1.."
A: "...And here is something written in that rigid, semicolon-ridden
monstrosity known as #2. Which is easier for you to 'read'?"
(silence; Jeopardy music plays in background).
T: "#1.."
(audience cheers, then silence descends...)
T: "...But they're both crap."
===================
So much for "readability". :(
Alex K. Angelopoulos [MVP]
> OK, here's my problem set. A massive corporate phones up and they want a
(1) complete overhaul of systems
I think you mean their various business applications here; they want to
completely re-asses things. Not really a discrete item then, but I would
push for internal declaration of a systems standard.
(2) broken VB "client applications" from multiple vendors
You will find that most of the problems are (a) issues with file versioning,
(b) issues with runtime permissions in an environment migrating from 9x to
NT family systems, (c) fubared code which has weird things like app
directory data storage and hardcode paths, and (d) misconfiguration in the
case of database driver dependencies.
Problem is not a scripting issue unless switching; if we are, then both
languages can do this.
One handy thing with so many of these solutions which are actually VBA is
that if internally developed, they can often be ported out to VBScript in a
matter of minutes.
That doesn't weigh against JScript, because you can also call VBScript from
JScript. I would advise getting someone competent to wrap up migrating code
in classes, though, to make sure this is clean.
(3) COM objects are no longer supported
In many ways, if they actually ARE problems, this is the same as (2). Both
languages work; examples in documentation of scripting are probably
VBScript. Where source is available for VB COM objects, they can be ported
out to VBScript quickly.
(4) intranet doesn't work
Dollars get you donuts they have an infrastructure that mirrors the chaos of
their software systems. Not scripting at this point.
(5) two databases that won't talk to each other
Insufficient information to tell how this fits in. Not scripting at this
point.
(6) Solutions work from any computer any time with no installations
If we're scripting, there is no barrier to either VBScript or JScript; they
use Windows systems. The important issue here is what they're going to do
about their platform infrastructure disaster.
(7) plain text and standards compliance to prevent vendorlockin
Both VBScript and JScript can do this.
(8) super fast browser objects that snap into place
Both VBScript and JScript are possible. If some things eventually turn out
to be too slow, VBScript can be ported to VB quickly; this can increase
execution speed for those critical sections of code by a factor of 10 to 100
(worst case of only 10 times is relative base time for simple function calls
into COM objects).
(9) disconnected recordsets on the client to reduce server load
Both VBScript and JScript can do this.
(10) will run into thousands of lines of code
Both VBScript and JScript can handle long code.
(11) will need to be maintainable in 3 years
Both VBScript and JScript can be maintained.
Solution:
There is nothing locking out either language; there are some issues which
are more important than even working on the named solution, though; they
have problems they don't understand.
A - THE MOST IMPORTANT ITEM: FIND THE REAL PROBLEMS. Analysis of information
systems, especially to clear up fuzzy issues. Before we even talk cleanup,
I would want to make sure the foundation is good, otherwise we're building a
nice, elegant place to live on top of quicksand.
This is an incredibly critical step. These cleanups always produce
significant improvements in performance for everyone, and within days you
have introduced hope, faith, and have motivated people to believe in you.
This will be important later on.
B - INCREMENTAL CHANGES.
To prevent total disruption of a complex, real system which is in semistable
equilibrium, I would want to tackle this in pieces; the starting point would
be analyzing their business needs and tools, then trying to remove small bad
bits while getting an initial feel for the system.
In abstract, you don't need to do this. In reality, replacing it all at once
is like transplanting a brain. Even if you can do it, the new body behaves
nothing like the old one and people need to learn everything from scratch.
C - Clear documentation of problems and heavy commenting of solutions is a
necessity. So is version control.
D - Chosen solution would be VBScript, for the following reasons:
(a) I am intimately familiar with it; in absence of other overbalancing
factors, this means I would do my best work in it.
(b) You indicate several situations where there may be a large body of
working code or information available which can be easily leveraged.
(c) If certain components of the system turn out to need better performance
than can be achieved in script, they can readily be turned into compiled
code which can run on legacy systems, or converted into VB.NET eventually.
Source code would be available, and automated documentation generation is
straightforward when doing these conversions (as is automated code
conversion).
(d) Wide knowledge of the underlying language family further reduces
lockin.
Alex K. Angelopoulos [MVP]
> I think I suggested that Perl was 'superior.' *cough*
OK, well I KNOW I talked about VBScript. And mentioned Monad.
Was there anything important we overlooked? ;)
Adam D. Barratt
<#HKNImcq...@TK2MSFTNGP11.phx.gbl>, Alex K. Angelopoulos [MVP]
Adam
--
Dennis Ritchie: "So fsck was originally called something else"
Question: "What was it called?"
Dennis Ritchie: Well, the second letter was different.
-- Q&A at Usenix
Joe Earnest
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:#NJ65ocq...@TK2MSFTNGP10.phx.gbl...
| So philosophically speaking... although people have written good code and
| bad code in the various versions of Basic over the years, no one has ever
| written truly evil code in Basic...?
|
| SCORE!!!!!
Welcome to the "guns don't kill people ..." argument. One can certainly
argue that BASIC and BASIC code isn't evil because a user concocts an evil
scheme and utilizes it. BASIC may have significant "good" or "bad"
potential social aspects (as do guns), which require a realistic analysis of
its place in society (as do guns). I concede that even C++ may not "evil",
but it feels that way when I try to use it. To paraphrase the great line
from the 'Toon Town movie, "It's not evil, it's just drawn that way." ;-)
Regards,
Joe
Gerry Hickman
> Did not! (bonk!!)
You say "did not", then basically prove it all over again!
> If we want to make a sweeping statement along these lines, I've just proven
> that all imperative languages are inferior to JScript also.
That's right.
>>2. In WMI, you can't pass parameters into some provider objects all on
>>one line in JScript.
> That's one of the effects Torgeir was talking about. JScript always passes
> by value instead of by reference.
I don't know it it's related or not. It only occurs in WMI. Regarding
whether JScript always passes by value, the Microsoft docs appear to
conflict, here an extract form the latest user guide:
--start--
Objects, arrays, and functions are copied, passed, and compared by
reference. When you copy or pass by reference, you essentially create a
pointer to the original item, and use the pointer as if it were a copy.
If you then change the original, you change both the original and the
copy (and vice versa). There is really only one entity; the "copy" is
not actually a copy, it's just another reference to the data.
-- end --
An other document says the same as Torgeir, and that the reason is "to
adhere to the ECMA".
> I assume that InParameters has side effects for garbage collection, then?
What makes you say that?
>>3. You can't use SAFEARRAYS directly with JScript,
> I believe this is the byref/byval issue in another guise.
Again, I don't know. Maybe the COM people only consulted with the VB
team and not the JScript team, so it didn't get implemented properly.
>>>>Basically, Microsoft refuse to bundle PERL
> maintained and developed by ActiveState, and I suspect concerns about
> lawsuits from the Open Source movement are another reason they don't
> actually provide the software.
So how is it that Microsoft press were not sued? This did cross my mind
though (licensing). If Microsoft included PERL in Windows, sales would
rocket, and they'd be accused of cashing in on free software.
> + Andrew Clinick probably can be considered the foremost authority on
> Microsoft's "scripting" attitude towards Perl. See his "Perl of Wisdom"
> article:
> http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting012299.asp
Thanks for the articles, but this is not the Script Center. These
articles are side-lined where no one will find them.
But this is academic, until PERL is simply an other ScriptEngine option,
it's of no use to anyone.
> + As far as current attitudes go, I can tell you that the Windows 2003
> Administrator's Companion even used Perl as the scripting language of
> choice.
Yes, and this really is pitiful. They created a new O/S, wrote the
companion KNOWING that PERL is best, but then "ooops" forgot to put it
in the O/S.
> This is really just said by me to convince you that you're barking up the
> wrong tree saying they "refuse" to distribute it,
But they ARE refusing! The fact that a few guys who write books are
promoting it, doesn't mean it's getting done.
> other than the sense in
> which they "refuse" to distribute other useful applications they don't hold
> a copyright for.
Again I agree, can't they just buy-out the "PERL corporation" - or what
ever it's called? They could then ban future versions on Linux and
everyone would have to switch to Windows?
> This is another "bonk!" item. Ask anyone who deals with linguistics about
> the role of redundancy in natural languages. A scripting language is for
> gluing by humans, not for computational elegance.
I thought it was for programming computers?
> If you're after visual offenses, though, your lack of familiarity with
> VBScript betrayed you; you should have picked REM. (I will grant that WEnd
> does run a close second to it).
Yes, but they've got the apostrophe these days:)
Gerry Hickman
> This is as much BASIC's fault as the high murder rate is the responsiblity
> of the actual guns themselves...
No I don't blame "BASIC", I blame the educators of the day (and this
hasn't changed since). Universities still churn out computer graduates
with all the wrong qualifications.
Gerry Hickman
> Hmmm, you've got me there. Fortuntaely for me, I don't ever work in that
> problem domain ;-)
It's not easy. I don't know the answer either. I could say JScript, but
then what if Microsoft dropped it six months later? Then I've made the
wrong choice.
> Wait a minute! That is a trick question. Of course you'd be a fool to
> propose a vbscript solution to a company that is complaining of broken VB
> "client applications"!
NO! I was serious. I think the managers of these corporates could be
shown how VBScript is nothing to do with VB.
Gerry Hickman
> other languages try (almost always superficially) to stay closer to the
> original mathematical-logical syntax, and quickly fall into a host of
> arbitrary non-mathematical and even non-logical syntactical issues.
I agreed with you up to this point, but I don't agree with the above.
JScript has proved for the first time, that you can have logic AND grace.
C# is basically a rip off of JScript. Few would dispute that C# was
conceived by the greatest programming minds on the planet, so why do you
think they stole from JScript? Simple - because it was the best.
Everyone in the .NET world (except students) knows that C# is the only
language worth bothering with for .NET development. I analysed all
three, and after about 10 minutes it was obvious that C# was the one.
JScript ~= C#
Gerry Hickman
> bad code in the various versions of Basic over the years, no one has ever
> written truly evil code in Basic...?
Exactly my point. It's too weak to do anything really "evil". Now if
someone invented superB++ (or whatever) we could have some fun for a change!
Gerry Hickman
> will call simply #1.."
>
> A: "...And here is something written in that rigid, semicolon-ridden
> monstrosity known as #2. Which is easier for you to 'read'?"
Nice test! But fatally flawed. Have you seen the code examples ADSI
docs? Quite a few of them show C++ next to VB. The C++ code looks REALLY
ugly to me, and yet to the learned eye, they probably view it as a work
of art.
I don't think you HAVE to use the ; in JScript anymore.
Readability, is when you have to go through code a year later and try to
remember why you coded it like "THAT"?? JScript is more concise and more
compact than VBScript and the braces mean you know exactly which block
you're in. All properties and methods are case sensitive and all methods
must have parentheses, Enums and Arrays() are not coded the same (unlike
VBScript). This makes it VERY clear what's going on, especially if you
don't have the object model to hand for the object it's making calls to.
Roland Hall
Other than Gerry has announced B++ (the new BASIC EVIL TWIN [good hack
name]) is in development and will soon replace all other languages, I think
that about covers it.
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:uOCnrqdq...@tk2msftngp13.phx.gbl...
Roland Hall
"Gerry Hickman" <gerry...@yahoo.co.uk> wrote in message
news:uHtLK4hq...@TK2MSFTNGP12.phx.gbl...
Joe Earnest wrote:
"...why do you
Gerry Hickman
> I'm gonna' tell Perl you said that.
Good point, but
1. As I said before, JScript is more closely related to PERL than is
VBscript.
2. Microsoft do not recogize PERL exists, and would never allow one of
their dev teams to "copy" it. They can copy JScript because they hold
the copyright, but copying PERL could have resulted in legal problems
and very bad publicity.
In other words, they looked at everything they had, realized PASCAL was
a joke (the guy used to work on Delphi but that was soon written off),
realised VB was an even bigger joke, and invented C# - a WORK OF ART to
behold. The only reason VB.NET exists is to try and avoid complaints
from people who wrongly invested time and money in VB6, and also to
avoid complaints from so-called "educators" who know nothing about REAL
programming and advocate VB.
Al Dunbar [MS-MVP]
> Alex K. Angelopoulos [MVP] wrote:
> > A: "Here is something written in the warm, friendly, natural language we
> > will call simply #1.."
> >
> > A: "...And here is something written in that rigid, semicolon-ridden
> > monstrosity known as #2. Which is easier for you to 'read'?"
>
> Nice test! But fatally flawed.
Ditto, but mainly because Alex was asking leading questions ;-)
> Have you seen the code examples ADSI
> docs? Quite a few of them show C++ next to VB. The C++ code looks REALLY
> ugly to me, and yet to the learned eye, they probably view it as a work
> of art.
So then, ugliness is also in the eye of the beholder?
> I don't think you HAVE to use the ; in JScript anymore.
>
> Readability, is when you have to go through code a year later and try to
> remember why you coded it like "THAT"?? JScript is more concise and more
> compact than VBScript and the braces mean you know exactly which block
> you're in. All properties and methods are case sensitive and all methods
> must have parentheses, Enums and Arrays() are not coded the same (unlike
> VBScript). This makes it VERY clear what's going on, especially if you
> don't have the object model to hand for the object it's making calls to.
Well, I *have* looked at old vbscript code of mine older than a year. I
found it embarrassing, as my style has evolved in the meantime. But I don't
generally have much trouble figuring out what is going on in the code.
Whether that is because of the "readability" of vbscript or because I force
myself to code in a way that I myself find maintainable is perhaps arguable.
But at the very least it means that the nature of language itself does not
make it impossible to be readable.
I expect my JScript code (were I to write any) would evolve into an
equivalent form. I would most certainly prefer it for the purpose of
readability to one of the really old basics where line numbers were
required!
/Al
Al Dunbar [MS-MVP]
/Al
"Roland Hall" <nobody@nowhere> wrote in message
news:eEj8Zfjq...@TK2MSFTNGP10.phx.gbl...
Joe Earnest
[snip]
"Gerry Hickman" <gerry...@yahoo.co.uk> wrote in message
news:uHtLK4hq...@TK2MSFTNGP12.phx.gbl...
| Joe Earnest wrote:
|
| > other languages try (almost always superficially) to stay closer to the
| > original mathematical-logical syntax, and quickly fall into a host of
| > arbitrary non-mathematical and even non-logical syntactical issues.
|
| I agreed with you up to this point, but I don't agree with the above.
| JScript has proved for the first time, that you can have logic AND grace.
I fear that we're discussing apples and oranges here. If it helps, think
"a-logical" and "a-mathematical" in the above-statement, instead of
non-logical or non-mathematical. And we're on different tracks as to the
phrase "mathematically logical."
Mathematical logic is a formal system that exists to validate mathematical,
meta-mathematical, dual-state logical, set- and model-theoretical, and other
abstracted operations, and to prove computability, permutability,
completeness, etc. It doesn't *do* anything, at least in the sense of a
pragmatic operation; nor does it design anything, as would, say, a model
theorist or a topological theorist. It does, however, have a complex
structure (far more complex and abstract than computing languages), some few
"syntactical" aspects of which were historically connected with the
development of the computer, and have probably served as models for, the
inherent structure of computing languages -- functions, free and bound
variables, mathematical and logical (i.e., set-theoretical) operators,
certain deductive rules, properties and methods of theorems and postulates,
(set theoretical) arrays, parenthetical groupings, etc. Everything in a
mathematical-logical analysis, however, is (1) self-contained (no outside
interfaces), (2) logic built solely on logic, and (3) contrary to popular
belief, not inherently binary in nature.
Except when cranking out a mathematically defined result, high-level
computer languages are designed to *do* something, i.e., to facilitate
accomplishing something through an interface with the machine language of
the CPU or, more commonly, a construct of the OS or the computer hardware.
The only common aspects of high-level languages that are mathematically
logical are the math and "logical" operators, and, because computers are
binary, the "logical" operators are universally reduced to simplistic
"boolean" grouped-bitwise or single dual-state status, not the classic
mathematical-logic set-theoretical symbols or actions for unions, junctions,
disjunctions, inverses and converses, reductions, expansions,
transformations, etc., much less the articulation of different trans-finite
sets or infinities that often preoccupies mathematical logical proofs.
Actual JScript and PERL symbols and operations, or C++ functions and
pointers, generally have no more relationship to mathematical logic than do
those in BASIC syntax, although highly abstracted languages have more
superficial similarity.
In fact, the bulk of what a computing language *does* has nothing to do with
"logic" in a classic mathematical sense. To establish an interface through
a high-level scripting language (with an object, organized data on a disc, a
video interface, etc.), the language is simply adapting to whatever
lower-level construct has been engineered into the chip, OS or hardware.
This is a straight-forward process of complying with an external definition,
and is far closer to engineering concepts and operations (as in the early
mainframe punch-card electrical-engineering-symbol program flowcharts) than
"logical" operations.
These interfaces, and the languages' inherent functions that encompass them,
are the arbitrary non-mathematical and non-logical syntactical issues of
which I spoke. They must be symbolized in some manner. My point was that,
at a high level, a language oriented toward recognizable linguistic
action-verbs or engineering terminology may, overall, be more cognizable and
"usable" than a "categorizing" or "abstacting" syntax, even if the latter is
more efficient. But in any event, the fact that none of this is "logical"
in a traditional sense, is certainly no comment on which language may be
more syntactically "coherent", have more productive inherent functions, or
be more "evolved" toward current computer configurations.
While I once studied mathematical logic, I personally have little use for a
high-level programming language that "looks like" a mathematical-logical
abstraction. I'd rather have one that reminds me, in terms I understand, of
what it is doing, even if that adds a bit of awkwardness and a complex
(instead of simple) syntactical coherence. From my perspective, JScript (to
some degree) and PERL (to an extreme) are just not as intuitively obvious.
I am concerned that my position is somewhat that of an "old fogey". My
background has a classical linguistic-mathematical knowledge base, that has
adapted computers to it. A preference for more abstract languages with
highly simplistic syntactical structures may well reflect a newer
generation's close familiarity and comfort with computer languages
independent of its source, as well as the increasing specialization and
isolation of the computer "administrator" from the general computer-literate
public in the social workplace.
Roland Hall
"Al Dunbar [MS-MVP]" <Alan-no-...@hotmail.com> wrote in message
news:%23xfBj7k...@TK2MSFTNGP09.phx.gbl...
Alex K. Angelopoulos [MVP]
> Hi Alex,
>
> "Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
> news:uPiAm6Uq...@TK2MSFTNGP09.phx.gbl...
>> Gerry Hickman wrote:
>>
>>> ...Where's the C++
>>> style increment and decrement operators?
>>
>> If C++ has taught me one thing, it's this: a system can be consistent
>> and still be the work of Satan.
>
> Well put, Alex!!! One to add to the Medieval Latin quote.
I think I would like to claim the phrase:
"A system can be consistent and still be the spawn of Satan."
Alliterative, concise, and applicable to many other purposes. :)
Alex K. Angelopoulos [MVP]
> Alex K. Angelopoulos [MVP] wrote:
>>> 2. In WMI, you can't pass parameters into some provider objects all on
>>> one line in JScript.
>
>> That's one of the effects Torgeir was talking about. JScript always
>> passes by value instead of by reference.
>
> I don't know it it's related or not. It only occurs in WMI. Regarding
> whether JScript always passes by value, the Microsoft docs appear to
> conflict, here an extract form the latest user guide:
> --start--
>
> Objects, arrays, and functions are copied, passed, and compared by
> reference. When you copy or pass by reference, you essentially create a
> pointer to the original item, and use the pointer as if it were a copy.
> If you then change the original, you change both the original and the
> copy (and vice versa). There is really only one entity; the "copy" is
> not actually a copy, it's just another reference to the data.
>
> -- end --
>
> An other document says the same as Torgeir, and that the reason is "to
> adhere to the ECMA".
Yep. I did some more looking at this, trying to puzzle out what InParameters
was - I didn't realize it was a WMI element (it isn't necessary in languages
where you can pass values by reference).
I don't know the full rationale behind this; the pseudo-incompatibility
makes sense though, because by forcing pass by value, the ECMA spec kills
off a significant source of possible cross-platform errors. Pass by
reference would certainly have made JScript more powerful, and data types
could be tested, but the net gain would be minor weighed against all the
possible coding problems it would produce.
>> I assume that InParameters has side effects for garbage collection,
>> then?
>
> What makes you say that?
I misunderstood; it won't matter since it's inside the WMI call.
>>> 3. You can't use SAFEARRAYS directly with JScript,
>
>> I believe this is the byref/byval issue in another guise.
>
> Again, I don't know. Maybe the COM people only consulted with the VB
> team and not the JScript team, so it didn't get implemented properly.
SAFEARRAYS don't meet ECMA spec, and they were already a typical feature of
COM. That's why they made the VBARRAY object for JScript to use.
Almost all of this discussion above goes back to the fact that historically
languages have implemented their own special kinds of data structures and
function calls. The standard .NET data types still have some flaws (no
standardization of unsigned integer types other than uint8) but go a long
way towards making this better.
>> + Andrew Clinick probably can be considered the foremost authority on
>> Microsoft's "scripting" attitude towards Perl. See his "Perl of Wisdom"
>> article:
>> http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting012299.asp
> Thanks for the articles, but this is not the Script Center. These
> articles are side-lined where no one will find them.
OK, I'll ask Dean and Greg to link them from the Script Center. Will that be
better? Sorry, but the articles were written well before the Script Center
was a gleam in Bob Wells' eye. And it wasn't written by the Scripting Guys
in their pre-Scripting Guy history; it was written by the guy who was
guiding Active Scripting development ;)
> Again I agree, can't they just buy-out the "PERL corporation" - or what
> ever it's called? They could then ban future versions on Linux and
> everyone would have to switch to Windows?
Gerry, look up the background of Perl, the development of it at ActiveState,
and the role of Microsoft vis-a-vis Perl and ActiveState. I can see how
given a certain set of starting information and guesses you would develop
the opinions you have, but I think if you look at what actually has happened
you would adjust those ideas.
>> ... A scripting
>> language is for gluing by humans, not for computational elegance.
>
> I thought it was for programming computers?
Depends on the role in which you look at it. The purpose of the compiled
code, or the code in the act of interpretation, is to make a computer do
something; at every other stage in its use, though, it is a blueprint.
This gets very complicated; Joe and I had lengthy discussions about this
which raised questions to me about the role and meaning of "language" and
drove home for me the point that it is a mistake to think of computer code
as language in any sense stronger than that people use similar skills to
understand it.
Programming is of course a role. If you haven't looked at one of my
favorite papers, John Ousterhout's "Scripting: Higher Level Programming for
the 21st Century" (http://home.pacbell.net/ouster/scripting.html) you may
want to. It has some interesting points, ones which are valid no matter what
you think of the alleged "argument" between Stallman and Ousterhout about
creating a scripting language as a scripting language.
In fact, you may also want to look up the original post by Richard Stallman
from 1994 that started "The First TCL War". Stallman's post was short and
precise, was grounded in actual experiences from the development of Emacs,
and you will probably find that you have some strong common ground with his
ideas.
>> If you're after visual offenses, though, your lack of familiarity with
>> VBScript betrayed you; you should have picked REM. (I will grant that
>> WEnd does run a close second to it).
>
> Yes, but they've got the apostrophe these days:)
and the other reflexive operators in the VB family, where it fits
syntactically that is.
Al Dunbar [MS-MVP]
/Al
"Roland Hall" <nobody@nowhere> wrote in message
news:OUCyXdoq...@TK2MSFTNGP10.phx.gbl...
Al Dunbar [MS-MVP]
"Joe Earnest" <joeear...@SPAMqwest.netPLEASE> wrote in message
news:un5bktl...@TK2MSFTNGP11.phx.gbl...
> Hi,
>
> [snip]
>
> "Gerry Hickman" <gerry...@yahoo.co.uk> wrote in message
> news:uHtLK4hq...@TK2MSFTNGP12.phx.gbl...
> | Joe Earnest wrote:
> |
> | > other languages try (almost always superficially) to stay closer to
the
> | > original mathematical-logical syntax, and quickly fall into a host of
> | > arbitrary non-mathematical and even non-logical syntactical issues.
> |
> | I agreed with you up to this point, but I don't agree with the above.
> | JScript has proved for the first time, that you can have logic AND
grace.
>
> I fear that we're discussing apples and oranges here.
Exactly. Gerry's claim above that JScript itself has proven something has
more to do, I believe, with his personal preferences than with any kind of
mathematical proof, the nature of which you so ably detail below.
<snip>
> While I once studied mathematical logic, I personally have little use for
a
> high-level programming language that "looks like" a mathematical-logical
> abstraction. I'd rather have one that reminds me, in terms I understand,
of
> what it is doing, even if that adds a bit of awkwardness and a complex
> (instead of simple) syntactical coherence. From my perspective, JScript
(to
> some degree) and PERL (to an extreme) are just not as intuitively obvious.
>
> I am concerned that my position is somewhat that of an "old fogey".
Old fogey's that expound as effectively as you do are nothing to be sneezed
at. In fact, I fear for a world without them. But I will never see that; as
long a I am alive, there will be at least one old fogey still breathing!
> My
> background has a classical linguistic-mathematical knowledge base, that
has
> adapted computers to it. A preference for more abstract languages with
> highly simplistic syntactical structures may well reflect a newer
> generation's close familiarity and comfort with computer languages
> independent of its source, as well as the increasing specialization and
> isolation of the computer "administrator" from the general
computer-literate
> public in the social workplace.
You go too far there. I think that you seem to have sensed the need to
abstract what computers and programming systems are from what they might
look like either in the real world, or in other scientific disciplines. We
sometimes benefit from metaphorizing what we do with computers, but at the
same time this can also provide limitations.
And don't get me started on the desktop metaphor. My screen looks nothing
like the top of my desk, and operates in a way completely different. And I
don't even need to try double-clicking on that stack of paper in a vain
attempt to open it up to know it will not work.
/Al
Gerry Hickman
> Yep. I did some more looking at this, trying to puzzle out what InParameters
> was - I didn't realize it was a WMI element (it isn't necessary in languages
> where you can pass values by reference).
Sorry, I thought you'd mentioned WMI in the past, and assumed you'd know
what I meant. Are you saying that this is "definitely" related to
passing by reference or "maybe"?
>>>>3. You can't use SAFEARRAYS directly with JScript,
> SAFEARRAYS don't meet ECMA spec, and they were already a typical feature of
> COM. That's why they made the VBARRAY object for JScript to use.
Yes, but VBARRAY is next to useless. It's OK if you want to retrieve
something from COM, but not if you need to pass something into COM! It's
typical that the only thing in the whole of JScript with a VB prefix, is
the one thing that doesn't work properly! Here's my code snippet for
setting DefaultIPGateways on a NetworkAdapter. "oSettings" is a simple
JScript object containing network settings - some of which are arrays.
// Set up Gateways
result = oAdapter.SetGateways(vbConv(oSettings.DefaultIPGateway));
_trace("Result of setting gateways " + result);
function vbConv(arrJS) {
// Use Dictionary object to convert JScript Array to SAFEARRAY
// oDict is a global var
oDict.RemoveAll();
for (var i in arrJS) {
oDict.Add(i, arrJS[i]);
}
return oDict.Items();
}
What that basically does is pass a SAFEARRAY back to WMI.
> OK, I'll ask Dean and Greg to link them from the Script Center. Will that be
> better?
Absolutely! But only if they believe in it, not just because they've
been asked to.
> Gerry, look up the background of Perl, the development of it at ActiveState,
> and the role of Microsoft vis-a-vis Perl and ActiveState. I can see how
> given a certain set of starting information and guesses you would develop
> the opinions you have, but I think if you look at what actually has happened
> you would adjust those ideas.
I was hardly in disagreement. As I said the whole licensing issue and PR
would be hard to reconcile. BUT there's another angle - if Microsoft
REALLY wanted PERL in their o/s, they would HAVE it, and no silly law
would get in the way. That's how things work in the real world. You can
be sure that if PERL was a route into bullet-proof DRM, Microsoft would
have a DLL written within minutes.
> the 21st Century" (http://home.pacbell.net/ouster/scripting.html) you may
> want to.
Well, I don't have a problem with ANY of this paper. I've been
converting companies away from VB6 and client apps for some time, and
they LOVE their new JScript systems, especially when they have to roll
out 600 new PCs and realise they don't need to install anything!
Gerry Hickman
> Exactly. Gerry's claim above that JScript itself has proven something has
> more to do, I believe, with his personal preferences
Not at all! I looked at both very carefully, in fact my first web
commercial web project was written in VBScript. I remember validating
the form field for a person's e-mail - in VBScript it was HORRIBLE, then
realized it could be done so compact in JScript I had to give it a try.
I then had to parse thousands of web logs, again JScript absolutely
killed basic for this task at the time I was writing it.
Once I found the ANSI style STD<> template libs, and object
extensibility I was hooked. VBScript caught up in some regards about 2
years later, but that was too late for me.
We actually discuss these matters at high level meetings once a month.
You are surely aware that big corporates require strategy based on more
than just one guy's opinion? At present we feel C# is the king of .NET
and JScript is the king of Windows scripting (bear in mind we have a ton
of client side code too). We also think Windows 2000 is superior to
Windows XP.
Al Dunbar [MS-MVP]
> Al Dunbar [MS-MVP] wrote:
> > Exactly. Gerry's claim above that JScript itself has proven something
has
> > more to do, I believe, with his personal preferences
>
> Not at all! I looked at both very carefully, in fact my first web
> commercial web project was written in VBScript. I remember validating
> the form field for a person's e-mail - in VBScript it was HORRIBLE, then
> realized it could be done so compact in JScript I had to give it a try.
> I then had to parse thousands of web logs, again JScript absolutely
> killed basic for this task at the time I was writing it.
I was not implying that there was anything invalid about your opinion. But
even you must admit that, personally, you happen to believe that JScript is
syntactically better than VBScript. That *is* your personal opinion, whether
it came from personal experience (as you say above), reading the comments of
others, comparing it to accepted technical standards, or you just somehow
like the look for some particularly obtuse reason.
But then you went and said that "JScript has proved for the first time, that
you can have logic AND grace". It may have proven this to*you*, but, being
an inanimate object lacking any cognitive skills of its own, it lacks the
ability to prove anything. To anyone. At any time. Same goes, of course, for
every other programming language. If proofs have been made, they have been
made by humans. But you offer no proof beyond saying it is so.
No matter the qualifications of those who agree with you, it is my opinion
that the "logic AND grace" claim is merely opinion. As such, it is as valid
for them as any of my opinions might be for me. But not significantly more
valid for me than my opinions may be for them.
> Once I found the ANSI style STD<> template libs, and object
> extensibility I was hooked. VBScript caught up in some regards about 2
> years later, but that was too late for me.
Ahhh, so, given a different timing for your experiences, you might have come
to a different conclusion. Interesting, but I won't push that point...
> We actually discuss these matters at high level meetings once a month.
> You are surely aware that big corporates require strategy based on more
> than just one guy's opinion?
Of course not.
> At present we feel C# is the king of .NET
> and JScript is the king of Windows scripting (bear in mind we have a ton
> of client side code too). We also think Windows 2000 is superior to
> Windows XP.
But, by that "we feel" statement, you have conceded *my* point that the
"grace" of JScript is based on the opinions of those who think it has this
grace.
I have nothing against those that some would call "language bigots", as many
interesting discussions result. Where some people cross the line is to
extrapolate their strongly held beliefs as absolute or independent of their
opinion, or as beliefs that, if not held by others, mark those others as
being wrong.
In summary, I am not saying you are wrong to think of JScript as having
grace, just that documented "proof" of this theory has not been made
unequivocally, either by you or by JScript itself. Now if someone else has
published such a proof, well, that would be another thing.
/Al
Gerry Hickman
> I was not implying that there was anything invalid about your opinion. But
> even you must admit that, personally, you happen to believe that JScript is
> syntactically better than VBScript. That *is* your personal opinion,
No it comes from the IT managers as a whole. For a start they don't want
to pay 2 teams; one for client and one for server. When I told them we
could do both client _AND_ server _AND_ SysAdmin _AND_ have near W3C
compliance with JScript they were almost writing blank checks on the
desks! This is the way to sell a concept.
> But then you went and said that "JScript has proved for the first time, that
> you can have logic AND grace". It may have proven this to*you*, but, being
> an inanimate object lacking any cognitive skills of its own,
You could apply this argument to any work of art. It does'nt mean it's
suddenly not a work of art just because it's inanimate?
> No matter the qualifications of those who agree with you, it is my opinion
> that the "logic AND grace" claim is merely opinion.
Fair enoough.
> As such, it is as valid
> for them as any of my opinions might be for me.
I completely agree.
> Ahhh, so, given a different timing for your experiences, you might have come
> to a different conclusion. Interesting, but I won't push that point...
It's a valid point. If VBScript and JScript suddenly appeared today -
with all the new capabilities, what would we choose? If you say VBScript
I'm listening...
> But, by that "we feel" statement, you have conceded *my* point that the
> "grace" of JScript is based on the opinions of those who think it has this
> grace.
I probably should have made the point stronger but didn't want to
offend! Put it this way, we have thousands of dollars of "XP budget"
sitting in our bank at this point in time. We were so disgusted with
what we saw, we decided not to upgrade. Same with Office 2003.
We're aware that file format limitations will become a problem if we
hold out too long, and are working on backward compatible converters.
It seems since Bill Gates handed over power they've lost the plot - at
least in terms of the enterprise - the home entertainment market is a
different issue.
> extrapolate their strongly held beliefs as absolute or independent of their
> opinion, or as beliefs that, if not held by others, mark those others as
> being wrong.
I agree with this, but the day someone can prove VB is superior (or even
talk about it with some passion) will be a grand day indeed!
> In summary, I am not saying you are wrong to think of JScript as having
> grace, just that documented "proof" of this theory
Well, there's always the docs?
However, you seem to underestimate Microsoft's "opinion" on this. The
bottom line is that Microsoft's opinion is the only one that counts. If
they decide they don't like JScript, that will be the end of it.
Gerry Hickman
> (1) complete overhaul of systems
> I think you mean their various business applications here; they want to
> completely re-asses things. Not really a discrete item then, but I would
> push for internal declaration of a systems standard.
Yes, that's the kind of thing; the word "standard" in your reply has a
certain ring!
> (2) broken VB "client applications" from multiple vendors
> You will find that most of the problems are (a) issues with file versioning,
> (b) issues with runtime permissions in an environment migrating from 9x to
> NT family systems, (c) fubared code which has weird things like app
Arrhhhh! But they've already been over that 100 times with their
previous vendors. They don't want to hear it anymore, they want me to
come up with something new and exciting, and something that works "out
of the box".
> One handy thing with so many of these solutions which are actually VBA is
> that if internally developed, they can often be ported out to VBScript in a
> matter of minutes.
Hmm. I've got a massive Access 2000 VBA app here that used to be Access
2.0 and uses DAO. It's implemented as an Access add-in. It has various
API calls such as GetOpenFileName() and custom fill functions for Combo
boxes - anyone remember those? I don't think it's going to take five
minutes!
> (5) two databases that won't talk to each other
> Insufficient information to tell how this fits in. Not scripting at this
> point.
Looks like scripting to me. We can use JScript to extract the data from
both Borland Interbase and mySQL, merge the data and display it in their
chosen internet browser.
> If we're scripting, there is no barrier to either VBScript or JScript
I agree to a point, but we have to choose one. We can't employ multiple
teams and end up with disparate code, which do we chose?
> (7) plain text and standards compliance to prevent vendorlockin
> Both VBScript and JScript can do this.
Yes, except VBScript is not standards compliant and will not work in
Mozilla. Hell it won't even work for Macros in Adobe.
> (9) disconnected recordsets on the client to reduce server load
> Both VBScript and JScript can do this.
Are you seriously saying you would code VBScript client side?
> (11) will need to be maintainable in 3 years
> Both VBScript and JScript can be maintained.
I agree.
> I would want to make sure the foundation is good, otherwise we're building a
> nice, elegant place to live on top of quicksand.
> This is an incredibly critical step.
I agree again, clean up is key.
> These cleanups always produce
> significant improvements in performance for everyone, and within days you
> have introduced hope, faith, and have motivated people to believe in you.
Yup.
> C - Clear documentation of problems and heavy commenting of solutions is a
> necessity. So is version control.
Yes.
> D - Chosen solution would be VBScript, for the following reasons:
> code which can run on legacy systems, or converted into VB.NET eventually.
(Heavily snipped), but BIZARRE choices?!
Al Dunbar [MS-MVP]
> Al Dunbar [MS-MVP] wrote:
> > I was not implying that there was anything invalid about your opinion.
But
> > even you must admit that, personally, you happen to believe that JScript
is
> > syntactically better than VBScript. That *is* your personal opinion,
>
> No it comes from the IT managers as a whole. For a start they don't want
> to pay 2 teams; one for client and one for server. When I told them we
> could do both client _AND_ server _AND_ SysAdmin _AND_ have near W3C
> compliance with JScript they were almost writing blank checks on the
> desks! This is the way to sell a concept.
OK, sell to them that way. Mind you, this does not mean that Alex might not
have been able to sell them on vbscript if he put his mind to it...
> > But then you went and said that "JScript has proved for the first time,
that
> > you can have logic AND grace". It may have proven this to*you*, but,
being
> > an inanimate object lacking any cognitive skills of its own,
>
> You could apply this argument to any work of art. It does'nt mean it's
> suddenly not a work of art just because it's inanimate?
We're getting way off-point here, but while we are talking art, surely you
appreciate that there are no absolutes there either. Sure, there are pockets
of consensus, but I know people who do not like Dali, or think that
Picasso's works were not art.
So, I'll admit that JScript has the grace you claim it has, in that at least
*some* of us think so.
> > But, by that "we feel" statement, you have conceded *my* point that the
> > "grace" of JScript is based on the opinions of those who think it has
this
> > grace.
>
> I probably should have made the point stronger but didn't want to
> offend!
Don't worry about offending me, you haven't so far.
> > extrapolate their strongly held beliefs as absolute or independent of
their
> > opinion, or as beliefs that, if not held by others, mark those others as
> > being wrong.
>
> I agree with this, but the day someone can prove VB is superior (or even
> talk about it with some passion) will be a grand day indeed!
My point exactly! I'm not going to try to prove to anyone that VB(script) is
superior, mainly because I think you are capable of picking a platform
suitable to your problem domain. My opposition to your claiming this (with
passion) for JScript is not to say that vbscript is better, just that your
appeals to the emotion are not highly amenable to a dispassionate
discussion.
In fact, I do really like working with vbscript. I just don't think that
everyone has to agree with me.
> > In summary, I am not saying you are wrong to think of JScript as having
> > grace, just that documented "proof" of this theory
>
> Well, there's always the docs?
Hmmm, I guess I will have to read them to find where they prove this.
/Al
Roland Hall
potato, three potato, four...]
Alex K. Angelopoulos [MVP]
> I probably should have made the point stronger but didn't want to
> offend!
Don't worry about that - you don't have the right personality to be a troll
<g>.
Alex K. Angelopoulos [MVP]
This is where the real tradeoff for VBScript/JScript becomes visible.
You're going to see me fence-hopping a bit below, and I've snipped out
completely sections where I think it was a draw or dependent on what we did.
Gerry Hickman wrote:
> Alex K. Angelopoulos [MVP] wrote:
>> (2) broken VB "client applications" from multiple vendors
[ ... frequent causes snipped ]
> Arrhhhh! But they've already been over that 100 times with their
> previous vendors. They don't want to hear it anymore, they want me to
> come up with something new and exciting, and something that works "out
> of the box".
We're nibbling around the edges of an issue here which you may not think of,
but which will probably make sense if you think about it: It IS easy for
people who are not good coders to pick up and write VBish code, but that
does not make them good coders! If the VB family has one Achilles heel, it
is the morass of trash that this produces. We can see the same thing in any
arena where universal literacy and access is possible: it has a lot of
positive side effects, but a lot of negative ones as well.
The net result is that there are a lot of shops with a VB compiler that hang
out their shingle as a solutions vendor and proceed to promise things then
repeat the same mistakes made by a thousand people before them.
In the case of a really crappy system which should be redone from scratch,
side effects and fallout be damned, writing in JScript implies at least 3
immediate advantages to the new system - and they are ones which partially
derive from what I call the inherently less "humanly accessible" nature of
JScript:
+ JScript literacy goes hand-in-hand with a somewhat stronger understanding
of computing logic.
It's not a clear correlation, but the CODERS who are available to work on
this kind of thing will generally be more literate. This is probably the
single most significant thing that can make a difference in a coding
project, no matter what the specified language is.
+ Coding in a new language FORCES rebuild.
You can't copy-paste little code snippets with hidden gotchas from the old
system. Thus the new system is truly clean and probably more consistent
(not to imply that it will be the spawn of Satan).
+ Inaccessibility to "helpers".
One incredible bonus of script, no matter the language, is that the source
is always available for inspection. One great detriment of it is that it is
always available for modification. Certainly the developers and their
successors should be able to modify it, but touchable code is usually
touched too often. That's why standard open source distributions always
have a maintainer who coordinates revisions.
>> One handy thing with so many of these solutions which are actually VBA
>> is that if internally developed, they can often be ported out to
>> VBScript in a matter of minutes.
>
> Hmm. I've got a massive Access 2000 VBA app here that used to be Access
> 2.0 and uses DAO. It's implemented as an Access add-in. It has various
> API calls such as GetOpenFileName() and custom fill functions for Combo
> boxes - anyone remember those? I don't think it's going to take five
> minutes!
This is the "ugly code" problem. Quite frankly, most of those funky little
calls should probably have been implemented as class constructs, and they
aren't usable as is, aren't even wanted. If they had been implemented well,
they would be accessible with no rework via COM interfaces to any Active
Scripting language; of course if they had been well-designed, this problem
would likely not be here anyway. :)
>> (7) plain text and standards compliance to prevent vendorlockin
>> Both VBScript and JScript can do this.
> Yes, except VBScript is not standards compliant and will not work in
> Mozilla. Hell it won't even work for Macros in Adobe.
It is correct to say "there is no ECMA/ISO specification for VBScript". The
interfaces do comply with the Active Scripting and COM interface
specifications.
>> (9) disconnected recordsets on the client to reduce server load
>> Both VBScript and JScript can do this.
>
> Are you seriously saying you would code VBScript client side?
I'm not concerned with Unix systems much, nor do I have to deal with
cross-platform browsing. If my situation was different, here is how I would
approach solutions.
(1) Web browsers only, cross-platform:
Javascript is the clear, hands-down, no-one-else-in-the-field winner, rather
like HTML for web pages. There is no comparison to be made, because
Javascript is the only scripting language which will run in every scriptable
browser on every OS/hardware combination that supports browsers.
This is not because it is superior in an abstract sense or because of an
IDE - it is because it is superior in a very clear and concrete sense: you
can run it in all of those browser-based situations.
It was nice of you to NOT insert the phrase "they insist that is must be
usable on their Unix server and their Macintosh systems in the art
department"; that would have been a cruel way to shut down the debate. Very
boring, too. :)
>> D - Chosen solution would be VBScript, for the following reasons:
>
>> code which can run on legacy systems, or converted into VB.NET
>> eventually.
>
> (Heavily snipped), but BIZARRE choices?!
Basic choices. VISUAL Basic choices!
Alex K. Angelopoulos [MVP]
rest of my response.
(2) If I had "system scripting" or support coding to do which has a
cross-platform requirement, I would have to further determine what the heck
I was doing on multiple systems and what those systems are. Javascript would
generally NOT be in the running, because on Unix systems it really can't do
the direct system scripting work that JScript can on Windows, even though
there is no real technical barrier to this if someone implemented a host for
it (there may even be one out there, I just haven't seen it).
Hands-down first choice for this case would be Perl. I would hate it, but it
generally does the best job of making interfaces look the same for both
Windows and Unix systems, and thus it is head and shoulders the best choice
for this job.
(3) Scientific/Technical Scripting or Game Scripting, Cross-Platform
Python. No solid competition, lots of standardized freely-available
packages, and lots of interfacing choices.
Al Dunbar [MS-MVP]
one that introduced the off-topic issue of throwing fuel on the fire.
/Al
"Roland Hall" <nobody@nowhere> wrote in message
news:OggI3w0q...@TK2MSFTNGP11.phx.gbl...
Al Dunbar [MS-MVP]
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
> Gerry,
>
> This is where the real tradeoff for VBScript/JScript becomes visible.
> You're going to see me fence-hopping a bit below, and I've snipped out
> completely sections where I think it was a draw or dependent on what we
did.
You can only be considered as hopping the fence if the intent of the
discussion is to determine the OPSL, or "One Perfect Scripting Language".
I hope I am not violating any copy right on the myiads of discussions in
newsgroups a few decades back about the theoretical "OPL". Needless to say,
that discussion never reached a final answer either.
> Gerry Hickman wrote:
> > Alex K. Angelopoulos [MVP] wrote:
>
> >> (2) broken VB "client applications" from multiple vendors
> [ ... frequent causes snipped ]
>
> > Arrhhhh! But they've already been over that 100 times with their
> > previous vendors. They don't want to hear it anymore, they want me to
> > come up with something new and exciting, and something that works "out
> > of the box".
>
> We're nibbling around the edges of an issue here which you may not think
of,
> but which will probably make sense if you think about it: It IS easy for
> people who are not good coders to pick up and write VBish code, but that
> does not make them good coders! If the VB family has one Achilles heel,
it
> is the morass of trash that this produces.
Note to Gerry: Alex's "this" refers not to VBish languages themselves, but
to the fact that there are poor VBish coders.
As an aside, I find it interesting that the result of Microsoft trying to
make programming more accessible to more people has had this negative impact
on overall software quality. Perhaps democratic ideals are not compatible
with some technologies.
> We can see the same thing in any
> arena where universal literacy and access is possible: it has a lot of
> positive side effects, but a lot of negative ones as well.
>
> The net result is that there are a lot of shops with a VB compiler that
hang
> out their shingle as a solutions vendor and proceed to promise things then
> repeat the same mistakes made by a thousand people before them.
As I said, you are not hopping the fence so much as making cogent
observations.
> In the case of a really crappy system which should be redone from scratch,
> side effects and fallout be damned, writing in JScript implies at least 3
> immediate advantages to the new system - and they are ones which partially
> derive from what I call the inherently less "humanly accessible" nature of
> JScript:
>
> + JScript literacy goes hand-in-hand with a somewhat stronger
understanding
> of computing logic.
> It's not a clear correlation, but the CODERS who are available to work on
> this kind of thing will generally be more literate. This is probably the
> single most significant thing that can make a difference in a coding
> project, no matter what the specified language is.
A very interesting observation, and one that I cannot refute.
/Al
Alex K. Angelopoulos [MVP]
> As an aside, I find it interesting that the result of Microsoft trying
> to make programming more accessible to more people has had this
> negative impact on overall software quality. Perhaps democratic ideals
> are not compatible with some technologies.
You're pushing us into more profundities, Al (hopefully, Joe Earnest checks
this subthread as well since he probably can make better comments than I can
on this).
The incompatibility is a weak but significant inverse correlation between
universality and quality. In every nation of the world, as literacy has
risen, the average "quality" of writing goes down - because people with
little native skill or interest now write. Similarly, if you go from 5% of
your population attending college to 75%, the average quality of college
attendees is then lower.
This gives us a simple tradeoff: quality of output versus quantity of
workers available, and as you seem to think, it isn't an easy thing to
decide one way or another. Jacques Ellul talked about this in a somewhat
extreme way in his book "The Technological Society", and the problem is
perennial. You can get a lot of calories quickly and cheaply at McDonald's,
but the flipside of that is to paraphrase William Russo's paraphrase of
Ellul*, loss of dinner hour rituals, further breakdown of family structures,
and coarsening of taste.
Before someone else steals it, I hereby claim the acronym HML ("Happy Meal
Language") as MINE.
======
* http://www.nhinet.org/russo.htm#b8
Gerry Hickman
> OK, sell to them that way. Mind you, this does not mean that Alex might not
> have been able to sell them on vbscript if he put his mind to it...
I completely agree, except perhaps when it gets to the standards
compliance and client side scripting?
> In fact, I do really like working with vbscript. I just don't think that
> everyone has to agree with me.
Quite, but what I'm saying is:
What about when you're sitting round the table with the bosses and
external consultants and they say "Right Al, what's your long term
strategy for this?"
At that point you can't just recommend what you personally "like", you
have to recommend what's best, and be ready for the consultants to tear
it to shreds. Are you confident VBScript (and/or VB.NET) can cut it in
this situation?
> Hmmm, I guess I will have to read them to find where they prove this.
Unfortunately, that's exactly what I had to do after Alex's post! Booo,
not much fun. I see VBScript now has classes, and regex so in many ways
it does come down to syntax, whereas there used to be a lot more to it.
I guess if you're going with VB.NET on the server (shudder to think?)
then VBScript would make sense as it's more consistent. If you're going
with C# on the server (like all the pros) then obviously JScript is the
better choice. Which ever of the above you choose, you've still got the
cross-platform browser object model to worry about. Look at Microsoft's
client-side world-facing code .... what language do they use?
Gerry Hickman
> + JScript literacy goes hand-in-hand with a somewhat stronger understanding
> of computing logic.
> It's not a clear correlation, but the CODERS who are available to work on
> this kind of thing will generally be more literate.
Good point! I never even considered this, but surely the way Microosft
negatively promotes JScript is also a factor in what people tend to
choose, I mean I started with VBScript. Why? Because that's what all the
examples were written in.
> + Coding in a new language FORCES rebuild.
> You can't copy-paste little code snippets with hidden gotchas
Again, a very good point. I put forward a very strong view on this about
a year ago, and my strategy was accepted, and from what I can tell
everyone is WAY pleased about it.
> + Inaccessibility to "helpers".
> One incredible bonus of script, no matter the language, is that the source
> is always available for inspection. One great detriment of it is that it is
> always available for modification.
Luckily we don't have that problem. Our two main projects each have a
"developer in charge". We use NT groups to assign permissions and we use
Frontpage Extensions to further divide responsibility, and anyone who
works in a sub area wouldn't dare mess with code outside their area
without asking first.
>>Hmm. I've got a massive Access 2000 VBA app here
>
> This is the "ugly code" problem. Quite frankly, most of those funky little
> calls should probably have been implemented as class constructs,
The facility just wasn't there in those days. If you needed a file
browser in Access 2.0, you had to make an API call, if you wanted to
custom combo, you had to use the bizarre fill functions.
> I'm not concerned with Unix systems much, nor do I have to deal with
> cross-platform browsing.
Ouch! You appear to be saying you'd consider VBScript for manipulating
client browser objects? STUNNED!
> (1) Web browsers only, cross-platform:
> Javascript is the clear, hands-down, no-one-else-in-the-field winner,
That's the same as what I'm saying. JScript covers both, you can share
you code and everyone goes home early...
> Basic choices. VISUAL Basic choices!
Hehehe!
Gerry Hickman
> (2) If I had "system scripting" or support coding to do which has a
> cross-platform requirement, I would have to further determine what the heck
> I was doing on multiple systems and what those systems are.
I should have said "Pure Windows AD network" in the original post.
> the direct system scripting work that JScript can on Windows, even though
> there is no real technical barrier to this if someone implemented a host for
> it (there may even be one out there, I just haven't seen it).
Yes, JScript is so good, I've actually heard UNIX guys requesting it. I
don't know if an engine was ever created.
> Hands-down first choice for this case would be Perl. I would hate it, but it
> generally does the best job of making interfaces look the same for both
> Windows and Unix systems, and thus it is head and shoulders the best choice
> for this job.
Many of the servers I work on have ChiliASP installed which (guess what)
suppports JScript! I can copy and paste the exact same files from
Windows and they run perfectly. Of course it helps if you code in a
neutral way to start with - porting becomes easier.
Gerry Hickman
> As an aside, I find it interesting that the result of Microsoft trying to
> make programming more accessible to more people has had this negative impact
Wait 'till Tweak-O-Matic gets going (or what ever it's called)!
I think it comes back to what I was saying before, about routes chosen
by the educators. If scripting had been pure JScript (or Python or PERL)
from the start this wouldn't be an issue. It may take some newbies 10
minutes (instad of 5) to write their first noughts and crosses game, but
so what? By the time they leave Universitey they'll have TOP skills.
Thing is, Microsoft had to back-track on this with VB.NET, basically
saying "sorry" to VB6 guys. "Sorry" as in "You'll have to learn to do
REAL programming now". You simply can't have the excellent .NET
framework co-existing with the Kludgy VB6 syntax and rules.
Gerry Hickman
> but the flipside of that is to paraphrase William Russo's paraphrase of
> Ellul*, loss of dinner hour rituals, further breakdown of family structures,
> and coarsening of taste.
Hahahaha! This is great!
Al Dunbar [MS-MVP]
"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
> Al Dunbar [MS-MVP] wrote:
>
> > As an aside, I find it interesting that the result of Microsoft trying
> > to make programming more accessible to more people has had this
> > negative impact on overall software quality. Perhaps democratic ideals
> > are not compatible with some technologies.
>
> You're pushing us into more profundities, Al
Thanks. Or sorry, as the case may be...
> (hopefully, Joe Earnest checks
> this subthread as well since he probably can make better comments than I
can
> on this).
>
> The incompatibility is a weak but significant inverse correlation between
> universality and quality. In every nation of the world, as literacy has
> risen, the average "quality" of writing goes down - because people with
> little native skill or interest now write. Similarly, if you go from 5% of
> your population attending college to 75%, the average quality of college
> attendees is then lower.
>
> This gives us a simple tradeoff: quality of output versus quantity of
> workers available, and as you seem to think, it isn't an easy thing to
> decide one way or another. Jacques Ellul talked about this in a somewhat
> extreme way in his book "The Technological Society", and the problem is
> perennial. You can get a lot of calories quickly and cheaply at
McDonald's,
> but the flipside of that is to paraphrase William Russo's paraphrase of
> Ellul*, loss of dinner hour rituals, further breakdown of family
structures,
> and coarsening of taste.
>
> Before someone else steals it, I hereby claim the acronym HML ("Happy Meal
> Language") as MINE.
Hmmm, based on the previous paragraph I was expecting HMTL ("Happy Meal
Throwup Language").
/Al
Al Dunbar [MS-MVP]
> Al Dunbar [MS-MVP] wrote:
>
> > OK, sell to them that way. Mind you, this does not mean that Alex might
not
> > have been able to sell them on vbscript if he put his mind to it...
>
> I completely agree, except perhaps when it gets to the standards
> compliance and client side scripting?
But, when you are selling something you simply minimize factors that are not
in your favour, do you not?
> > In fact, I do really like working with vbscript. I just don't think that
> > everyone has to agree with me.
>
> Quite, but what I'm saying is:
>
> What about when you're sitting round the table with the bosses and
> external consultants and they say "Right Al, what's your long term
> strategy for this?"
LOL, that's a good one, as something very similar happened a while back. The
result was that I rewrote our logon scripts in vbscript after a failed
attempt by a consultant (he only had the listings to go by, though). Of
course, it's only a logon script, not a life and death application.
> At that point you can't just recommend what you personally "like", you
> have to recommend what's best, and be ready for the consultants to tear
> it to shreds. Are you confident VBScript (and/or VB.NET) can cut it in
> this situation?
Well, I admitted that it was my personal preference, and then went on to
document why vbscript was a better choice than upgrading to a later version
of kixtart. Sure there were questions, but no shreds. The resulting vbscript
was a lot simpler than the original kixtart, and better structured so that
when the odd problem cropped up (and a few did), it was easily fixable.
Gave me a few palpitations when they rolled it out, as previously I had only
maintained the logon script for the facility I work in.
> > Hmmm, I guess I will have to read them to find where they prove this.
>
> Unfortunately, that's exactly what I had to do after Alex's post! Booo,
> not much fun. I see VBScript now has classes, and regex so in many ways
> it does come down to syntax, whereas there used to be a lot more to it.
So you are now saying that the two are functionally and capably equivalent,
with the only significant difference being syntax?
> I guess if you're going with VB.NET on the server (shudder to think?)
> then VBScript would make sense as it's more consistent. If you're going
> with C# on the server (like all the pros) then obviously JScript is the
> better choice. Which ever of the above you choose, you've still got the
> cross-platform browser object model to worry about. Look at Microsoft's
> client-side world-facing code .... what language do they use?
I picked a page at random and found JavaScript. They don't use vbscript *or*
jscript, but continue to develop and market them. What's up with that, I
wonder?
In our case, we deal with the cross-platform browser issue by enforcing
rigorous internal standards. Yes, we do have internet presence, but that is
done by a completely separate group.
/Al
Al Dunbar [MS-MVP]
> Alex K. Angelopoulos [MVP] wrote:
>
> > + JScript literacy goes hand-in-hand with a somewhat stronger
understanding
> > of computing logic.
> > It's not a clear correlation, but the CODERS who are available to work
on
> > this kind of thing will generally be more literate.
>
> Good point! I never even considered this, but surely the way Microosft
> negatively promotes JScript is also a factor in what people tend to
> choose, I mean I started with VBScript. Why? Because that's what all the
> examples were written in.
>
> > + Coding in a new language FORCES rebuild.
> > You can't copy-paste little code snippets with hidden gotchas
>
> Again, a very good point. I put forward a very strong view on this about
> a year ago, and my strategy was accepted, and from what I can tell
> everyone is WAY pleased about it.
In fact, this is one of the factors I mentioned in support of moving our
logon scripts from kixtart to vbscript, and perhaps the one that had the
greatest impact.
/Al
Gerry Hickman
> But, when you are selling something you simply minimize factors that are not
> in your favour, do you not?
I don't think you can in this case; what will you say when they ask
about how you'll keep the server load down, by using fancy client
scripting for working with disconnected recordsets? You can't just
ignore the question...
> of kixtart. Sure there were questions, but no shreds. The resulting vbscript
> was a lot simpler than the original kixtart, and better structured
I agree, sounds like you brought it into the 21st century!
> So you are now saying that the two are functionally and capably equivalent,
> with the only significant difference being syntax?
Yes, and I'm also saying that when you take all the other factors into
account (discussed in this thread and below) that JScript is the all
round winner.
> I picked a page at random and found JavaScript. They don't use vbscript *or*
> jscript, but continue to develop and market them. What's up with that, I
> wonder?
You found JavaScript, you found JScript! It makes no difference what you
type where it says 'language=', the engine used is the same! That's what
I'm saying, when it comes to world facing client code it's JScript all
the way. Why would anyone want to code in two languages when it can be
done in one? Client apps are dead, .NET client apps have not taken off
in the way everyone was expecting (hardly surprising when you look at
all the issues), and now everyone is crying out for training in HTAs. A
_complete_ U turn! In order to make HTAs you're dealing with browsers,
you could code it proprietary in VBScript, but why bother, when all you
need to do is add one line of code to pull in your fancy JScript/CSS
libraries that you've already written for your world facing web sites?
I don't know about you guys, but I like to leave work early! I've
already invented the wheel! Even if I change jobs, all I need is a few
Kb of text files on a floppy, and off I go again.
Roland Hall
VBS and, well frankly, it sucks! I'd elaborate but that would require
spending more time on something I evaluated as completely worthless.
"Gerry Hickman" <gerry...@yahoo.co.uk> wrote in message
news:eYOqUw8q...@TK2MSFTNGP12.phx.gbl...
Roland Hall
and chose to respond with the following:
Ok.
"Al Dunbar [MS-MVP]" <Alan-no-...@hotmail.com> wrote in message
news:uT4IvP6...@TK2MSFTNGP11.phx.gbl...