PowerShell is actually pretty cool.

I've been programming for almost 30 years and have worked on
Tandem/NSK, IBM, Bull/Unisys, Unix, Microsoft... (in order of time
spent). In those years I've programmed in well over 100 languages.
Last year circumstances took me to working extensively in a Windows
environment. A few months ago I stumbled on PowerShell and started
using it. My all time favorite is still TACL but PowerShell seems
like it could eventually overtake it if it's not abandoned and
nobody screws it up.

What would it take?

1) Tree structured directories of variables/functions. Not
artificial, manual support via synthetic objects with properties
hung off them but true native support. It's too hard to both allow
interaction (extensions to packages) while preventing unwanted
interaction (stepping on other writer's names) without something
like this. In TACL we've got #home and #uselist which are the
equivalent of PWD and Path in the file system world.

2) Some decent Text handling support. Objects are nice but you
can't do everything with a regex. Until you've worked in a language
that offers true editing functions against text variables you really
don't know what you are missing. TACL uses #DELTA which is an
embedded TECO-like language. Being able to move around in a string,
and do operations relative to a point is just so incredibly
useful....; and painfully missing here; especially when it comes to
doing lookahead parsing and dynamically generating code.

3) Once you've got directories of variables(functions) the door is
open to some type of #attachseg functionality. This is how large
collections of macros, functions and static variables are handled.
Something similar will eventually be needed for PowerShell or people
will go nuts waiting for a session to start up. Loading a bunch of
..ps1, ps1xml files... can't help but eventually get out of hand.
Basically this a method of attaching a pre-compiled set of features
so all the original sources don't all need to be located, validated,
and parsed one-by-one every time you start PowerShell. The one file
is validated when it is attached and everything that was in it when
it was created is now available without the text parsing step
needed.

BTW, in my opinion seperating variables and functions was a big
design mistake. Both are/should-be executable. Where is the
difference? If you want to list variables by 'type'. whether
string, function, psobject, whatever..., that's the job of a
function, not something so drastic as requiring them to go in a
seperate directory. Anyway I could really go on and on about how
wrong this is and I dare say it stems from the fact that you don't
support variable directories natively but since it seems we're stuck
with it I'll let it be.

My 10 cents worth.
Thanks

Rich,

I can't speak for others but I"ve never heard of TACL or like 80+ of the
languages you know. I did look this up and find a brief reference on
wikipedia along with a link to a $1500 course at HP site

What do you mean by "tree structured directoriess of variables and
functions". I'm reading this in terms that I know which would be namespaces
in C++. If tihs is what you stating I agree whole heartedly. When I
distribute functionality I don't want to step on others and most importantly
don't want them to step on me.

Hopefully we'll get this in time

#Delta's again I found a few references but I understand what you're saying.
Regular expression are currently my weakest area that I want to undersand
better but I've basically a novice. Are anchors anyting clsoe to #Detals?


#AttachSeg looks basically equivalent (in my 20 second view of HP's maunal)
to dot-sourcing a script in your powershell profile. My main gripe about
dot-sourcing is this brings in _every_ sundry function. You can help to
eliminate this with local functions. In regards to cmdlets the are compiled
and "loaded" into your environment as any application so I suspect this is
not your gripe.





"RickB" wrote:

RickB wrote: You can do the artificial method now by fully-qualifying cmdlet names with their
snapin name like so:

microsoft.powershell.core\Get-Command

But everything as you say ends up going into the same namespace. We talked to
Jeffrey Snover (the lead architect of powershell) about this on the
PowerScripting Podcast. I don't recall if it was the first or second half of
the interview, but you can find them both here: http://powerscripting.net. Look
at episodes 21 and 22.
You can't? I had always assumed otherwise because they look so complicated.
This sounds GREAT to me. My profile seems to grow by the day and it is already
taking about ten seconds to load. (As compared to powershell.exe -noprofile.)


--
Author, Tech Prosaic blog (http://halr9000.com)
Webmaster, Psi (http://psi-im.org)
Community Director, PowerShellCommunity.org
Co-host, PowerScripting Podcast (http://powerscripting.net)

On May 7, 9:25*pm, Bob Landau <BobLan...@xxxxxx>
wrote: In TACL, essentially any variable can hold a value, be a macro, a
function, or be a directory. Very much like any given filesystem
name can a directory or a text file or an executable of some kind.
The builtin variables #home and #uselist work like pwd and the path
environment variable.
I think every editor has a cursor. It's the thing you see that
tells you where text will appear if you type something. When you
use #delta the cursor starts at the beginning of the text. Commands
let you to move forward, backward, use if, search, loop, insert,
delete, copy a range of text to/from variables etc. Essentially it
puts you inside the string rather than operating on it from the
outside. It lets you focus on what you want to do rather than the
syntax needed to do it from the outside.

Probably all the functions one might perform in #delta can be done
in other ways. But that's true of every language. In fact, the
first machine language program I ever wrote I had to hand assemble
and 'poke' the numbers into memory and jump to them. I didn't even
have an assembler. It's about making it easier.
Basically it enhances consistency in commands availble across an
environment and enhances performance at the same time. It eliminates
the need to dot-source scripts.

In the Tandem world, as in most 'mainframe' environments, where the
'box' runs a massive variety of jobs continuously, the number of
automations it takes to understand the current state of processing
and to investigate and correct problems means having a rather large
number of commands at your fingertips. Almost as importantly, the
commands need to be extensible and able to interact and use each
other seamlessly if you want reliability and maintainability. This
typically means (over time) a person develops a huge number of
helper routines.

There is some synergy in TACL between supporting variable
directories and #attachseg. All your functions are pre-parsed and
loaded into your environment so you don't incur the performance hit
of locating and parsing a routine every time you use it. Moreover,
you know nobody has modified it and it has at least passed parsing.
The synergy comes in because all the functions don't necessarily
need to be 'visible' just like at a command prompt every program on
your system isn't necessarily executable without qualification.
Remember, there is #home and #uselist that work like PWD and PATH
in the variable world.

On Thu, 08 May 2008 08:31:51 -0400, Hal Rottenberg <hal@xxxxxx>
wrote:
LOL!

While I love a good regex I have great sympathy for opinion that they
can be a trifle complex on occasion. My regex skills have improved
with PS and are probably back up to where they were when I used to
bang on Perl a long while ago - but regexs don't always just roll off
the tongue do they...

I agree with the OP, I've always felt text processing was missing out
in this area with PS - lots of other scripting languages have simpler
approaches that still manage to solve the requirement (and, let's face
it, although we're moving to a world of objects, as admins we're still
dealing with legacy programs (that return text) for quite a lot of the
time).

My favourite alternative (and one I know Jeffrey Snover has some
positive feelings for) is the Rexx Parse statement - I'd love to see
that in PS. It would be easy to extend the Rexx syntax to optionally
include regexs - thus giving the best of both worlds.

Other language fans will have other favourites based on their own
personal heritage of course!

Cheers,
Chris

http://chrisjwarwick.spaces.live.com