Vista - Are we 'programmers' or 'scripters'?

On Mon, 12 Feb 2007 23:59:24 -0800, RichS wrote:

> I've got a couple more comments on this one:
>
> I think programmers work at programming as their full time occupation
> whereas for scripters writing scripts tends to be only part of the job
>
> Programming usually has all the versioning & project life cycle stuff
> wrapped round it - how many scripters use source control?

I agree, but I think this should go to the next level. As administrative
scripting expands and grows in complexity, I would argue that we (as
scripters) should begin following programmer practices like source control
and documentation. Just be cause we're writing "scripts" doesn't mean they
are any less important or powerful than a compiled exe. In fact, I think
if we pushed for the same level of support from management (hopefully) they
would realize scripting is not just a toss-off task but can have enterprise
level ramifications,both positive and negative. I'm sure we could all write
a simple script that would bring our networks to their knees. In an ideal
organization I would have source control, scripting IDEs, peer code review,
a dedicated test lab....you get the picture.


--
Jeffery Hicks
SAPIEN Technologies - Scripting, Simplified. www.SAPIEN.com
VBScript & Windows PowerShell Training -
www.ScriptingTraining.com/classes.asp
Windows PowerShell? - www.SAPIENPress.com/powershell.asp

blog: http://blog.SAPIEN.com
blog: http://jdhitsolutions.blogspot.com

On Tue, 13 Feb 2007 08:02:13 -0500, Jeffery Hicks
<"jhicks[at]SAPIEN.com"> wrote:

>On Mon, 12 Feb 2007 23:59:24 -0800, RichS wrote:
>
>> I've got a couple more comments on this one:
>>
>> I think programmers work at programming as their full time occupation
>> whereas for scripters writing scripts tends to be only part of the job
>>
>> Programming usually has all the versioning & project life cycle stuff
>> wrapped round it - how many scripters use source control?
>
>I agree, but I think this should go to the next level. As administrative
>scripting expands and grows in complexity, I would argue that we (as
>scripters) should begin following programmer practices like source control
>and documentation. Just be cause we're writing "scripts" doesn't mean they
>are any less important or powerful than a compiled exe. In fact, I think
>if we pushed for the same level of support from management (hopefully) they
>would realize scripting is not just a toss-off task but can have enterprise
>level ramifications,both positive and negative. I'm sure we could all write
>a simple script that would bring our networks to their knees. In an ideal
>organization I would have source control, scripting IDEs, peer code review,
>a dedicated test lab....you get the picture.


So where is the tight integration of Powershell into Visual Studio
?

On Feb 13, 6:02 am, Jeffery Hicks <"jhicks[at]SAPIEN.com"> wrote:
> On Mon, 12 Feb 2007 23:59:24 -0800, RichS wrote:
> > I've got a couple more comments on this one:
>
> > I think programmers work at programming as their full time occupation
> > whereas for scripters writing scripts tends to be only part of the job
>
> > Programming usually has all the versioning & project life cycle stuff
> > wrapped round it - how many scripters use source control?
>
> I agree, but I think this should go to the next level. As administrative
> scripting expands and grows in complexity, I would argue that we (as
> scripters) should begin following programmer practices like source control
> and documentation. Just be cause we're writing "scripts" doesn't mean they
> are any less important or powerful than a compiled exe. In fact, I think
> if we pushed for the same level of support from management (hopefully) they
> would realize scripting is not just a toss-off task but can have enterprise
> level ramifications,both positive and negative. I'm sure we could all write
> a simple script that would bring our networks to their knees. In an ideal
> organization I would have source control, scripting IDEs, peer code review,
> a dedicated test lab....you get the picture.

I think if scripting becomes as complex as programming, then something
is wrong. I've read that the only reason .NET access is available in
PowerShell is because there wasn't enough time to include everything
the developers wanted (correct me if I'm wrong...).

The problem with someone wearing the hat of Administrator and
Programmer is the sheer amount of information they now have to
remember. Reverse Lookup Zone and Strongly Typed. LDAP and stack
tracing. Brick level backup and thread control.

Sure, each hat can dabble in the other's field, but to be an expert at
both would just be overwhelming. If you really tried, I'm sure you
could do it, but you'd have no time for anything else in life.

My ideal cycle is that the Admins keep the machines running smooth
that the programmers use to make software. In return, the programmers
can write tools that make the Admins life easier. It's a nice
circle.

-Joe

| I think if scripting becomes as complex as programming, then something
| is wrong.

Sometimes scripting is more complex then just some clear c# code. So it
works both way in my experience. Again, if your writing code, it is
programming.

| I've read that the only reason .NET access is available in
| PowerShell is because there wasn't enough time to include everything
| the developers wanted (correct me if I'm wrong...).

I think if someone is thinking that, they are missing some powerfull ideas
in powershell. Everythings an object - a .Net object. All the native types
are .Net types. Powershell makes it easy to work with those types. So .net
is an intergral part of the powershell feature set, you can't really
seperate them or fully abstract away .Net - nor would one want to.

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject

| So where is the tight integration of Powershell into Visual Studio ?

I believe that is comming. Coming from VS, I am getting tired of using
notepad++ (a nice editor btw).

> Sometimes scripting is more complex then just some clear c# code. So it
> works both way in my experience. Again, if your writing code, it is
> programming.

If I'm playing football in my backyard, I wouldn't consider myself a
professional player. Once professional rules need to be enforced in a
backyard game, I've obviously grown into something bigger. Thats just
how I've always viewed scripting and programming.

> I think if someone is thinking that, they are missing some powerfull ideas
> in powershell. Everythings an object - a .Net object. All the native types
> are .Net types. Powershell makes it easy to work with those types. So .net
> is an intergral part of the powershell feature set, you can't really
> seperate them or fully abstract away .Net - nor would one want to.

I agree that having .NET access in PowerShell only makes it more
powerful. I just remember reading (maybe it was O'Reilly's Monad) that
it wasn't an original intention.

It's up to you, and depends on your needs, but Powershell is an
extremely sophisticated language. In fact, Powershell jumped so far
out in front of the pack, in terms of sophistication, I bet it
surprised the heck out of a lot of people, and quite possibly it's own
designers. Some of the things now slowly gaining mainstream credence
(though by no means new) are things that as a Powersheller you might
already be doing every day. (Or not, just because it's there doesn't
mean you'll want to use it, or know how to.) Things like lambdas
(script blocks), "mini domain specific languages", duck typing,
"JSON", etc. You many not recognize these terms, but you might well
be using them without knowing it. If you read Payette's book, you'll
see some fairly sophisticated techniques, not necessarily pointed out
per se, but they are there. But you could also use Powershell in a
naive way, it all depends on your needs and interests and knowledge.

Some of the new things are shocking and revolutionary. Like putting
objects on the command line, and the inevitable merging of the command
line, the scripting world (admin or not), and the OO programming
world. This is the future, even though very few realize it yet. I
sure as heck did not see it coming, and I never heard any one else
talking about it either. There will be growing pains, obviously there
is an impedance mismatch, but they are much less than I expected. How
large can a Powershell program grow and stay maintainable, I have no
idea at this point. In fact, the biggest problem for me right now is
that it's hard to organize and group and consistently name an ever
increasing number of functions.

Even the command line versus IDE split already has it's fate sealed,
partially, and maybe a lot, by Powershell. Almost nobody realizes all
this yet, but at this point it's unstoppable. The genie is out of the
bottle. I wouldn't hold my breath, but it's all coming, and you are
already at the forefront, should you choose to accept this mission.

Mike

| If I'm playing football in my backyard, I wouldn't consider myself a
| professional player. Once professional rules need to be enforced in a
| backyard game, I've obviously grown into something bigger. Thats just
| how I've always viewed scripting and programming.

I understand what your saying and not trying to parse too fine here. But
not sure the analogy applies. With psh, you now have two rule books. The
..net book still applies, and is always there. The psh rule book is on-top
of that book and abstracts and simplifies the .net book. Much of the time
you live in the psh book and it takes care of the .net rule book for you.
However some of time, you need deeper knowledge of both books to figure out
what is going on and how to do things. The lines are blurred. Is Perl.Net
for VS a prog language or a script language? When psh integrates nicely
with VS, does it then become a programming language? What about when you
can mixin psh directly into your c# methods and have everything compile into
one thing? If c# can be done at the command line and in script file, does
that somehow make it a scripting language? The distinction gets blurry so I
just stay away from it and say they are programming languages. The
implementation details are just that and don't really matter.

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject

http://blogs.msdn.com/powershell/arc...languages.aspx

Greetings /\/\o\/\/ (Scripter)

"William Stacey [C# MVP]" <william.stacey@gmail.com> wrote in message
news:uY0iYJ6THHA.3592@TK2MSFTNGP03.phx.gbl...
>
> | If I'm playing football in my backyard, I wouldn't consider myself a
> | professional player. Once professional rules need to be enforced in a
> | backyard game, I've obviously grown into something bigger. Thats just
> | how I've always viewed scripting and programming.
>
> I understand what your saying and not trying to parse too fine here. But
> not sure the analogy applies. With psh, you now have two rule books. The
> .net book still applies, and is always there. The psh rule book is on-top
> of that book and abstracts and simplifies the .net book. Much of the time
> you live in the psh book and it takes care of the .net rule book for you.
> However some of time, you need deeper knowledge of both books to figure
> out
> what is going on and how to do things. The lines are blurred. Is
> Perl.Net
> for VS a prog language or a script language? When psh integrates nicely
> with VS, does it then become a programming language? What about when you
> can mixin psh directly into your c# methods and have everything compile
> into
> one thing? If c# can be done at the command line and in script file, does
> that somehow make it a scripting language? The distinction gets blurry so
> I
> just stay away from it and say they are programming languages. The
> implementation details are just that and don't really matter.
>
> --
> William Stacey [C# MVP]
> PCR concurrency library: www.codeplex.com/pcr
> PSH Scripts Project www.codeplex.com/psobject
>
>
>