Well, ya see, this makes life easier for a vee programmer. That is, future
vee ought to be totally .net, except it'll be graphical. Then we have, hard
coders using .net script, and gui coders using vee gui. Now if you out-run
NI ...
rufus
-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Thursday, October 07, 2004 7:38 AM
To: VRF
Subject: [vrf] RE: FW: RE: AW: RE: Do you use .NET in VEE?
> Oops didn't quite finish that message.
Gads! I got a ton of those too.
> For me, the major problem is the flat nature of the Win32 API.
Personally I wish it was a whole lot flatter.
> For me, it is easier to guess where something might be from a smaller
> set of names (namespaces) vs. the thousands of functions in the WIN32
> API.
Egads! I'm on the opposite side of this too. My biggest hurdle to learning
MFC was it's hierarchy. Were it not for the fold-out wall chart, I'd have
been lost. I see the FCL in the same light: yet another (and different)
hierarchy, yet another artificial view.
> Well Longhorn hasn't shipped yet and anything can happen between now
> and then but that is their current plan of record.
I may hope all I want, but I think this *will* come to pass soon. Originally
it was what was considered "common hardware" that killed the COM api. This
time around, nearly every serious developer has at least > 2GHz P4. Except
me of course But then I'm not really serious.
Thanks for the link. I haven't been watching current developments lately.
Too much denial!
> The question is whether you feel you are getting good return on the
> speed you give up.
My own answer is no, but I'm not John Q. Programmer. For VEE's target
audience, the answer will definitely be yes - as soon as we can all wrap our
heads around the hierarchy. With few exceptions, I don't think we as a group
are under the impression that we can cut hardware corners with software. At
least I hope not! Instrumentation is a lot less expensive than development
time.
> Yeah not everybody is ready to take the red pill. Sorry, The
> Matrix reference there.
Waitaminute! Didn't you mean blue? Sorry, Valium reference there!
> Anyway, my whole point in all of this is that of all the different
> technologies coming out of Redmond, I wouldn't write this one off
> right away. I think using VEE together with .NET can be very powerful.
It's component aspects (that which I have been focused on - um, in a "in my
spare time" sort of way - for almost a year now) are certainly much better
than COM. And it's a godsend for scripting. There are aspects that I really
abhor though. These mostly have to do with MS's planned commercial ".NET
Services" exploits. As much of their original plan has not come to pass, I
have a "wait and see" attitude.
As far as the VEE community is concerned, yes, it's going to be wonderful.
We don't need to be that concerned with speed, and that front will improve
with time anyway.
For those of us who were Windows programmers to begin with, it stinks to see
years of learning get flushed, but It's not like it hasn't happened before.
Most of us were DOS programmers at one time too.
I still plan to focus primarily on the CFI, so those of you who get stuck
with that can still count on me for help and advice. I'll experiment with
the new way as I work through my books, but it won't really be a priority.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
vee ought to be totally .net, except it'll be graphical. Then we have, hard
coders using .net script, and gui coders using vee gui. Now if you out-run
NI ...
rufus
-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Thursday, October 07, 2004 7:38 AM
To: VRF
Subject: [vrf] RE: FW: RE: AW: RE: Do you use .NET in VEE?
> Oops didn't quite finish that message.
Gads! I got a ton of those too.
> For me, the major problem is the flat nature of the Win32 API.
Personally I wish it was a whole lot flatter.
> For me, it is easier to guess where something might be from a smaller
> set of names (namespaces) vs. the thousands of functions in the WIN32
> API.
Egads! I'm on the opposite side of this too. My biggest hurdle to learning
MFC was it's hierarchy. Were it not for the fold-out wall chart, I'd have
been lost. I see the FCL in the same light: yet another (and different)
hierarchy, yet another artificial view.
> Well Longhorn hasn't shipped yet and anything can happen between now
> and then but that is their current plan of record.
I may hope all I want, but I think this *will* come to pass soon. Originally
it was what was considered "common hardware" that killed the COM api. This
time around, nearly every serious developer has at least > 2GHz P4. Except
me of course But then I'm not really serious.
Thanks for the link. I haven't been watching current developments lately.
Too much denial!
> The question is whether you feel you are getting good return on the
> speed you give up.
My own answer is no, but I'm not John Q. Programmer. For VEE's target
audience, the answer will definitely be yes - as soon as we can all wrap our
heads around the hierarchy. With few exceptions, I don't think we as a group
are under the impression that we can cut hardware corners with software. At
least I hope not! Instrumentation is a lot less expensive than development
time.
> Yeah not everybody is ready to take the red pill. Sorry, The
> Matrix reference there.
Waitaminute! Didn't you mean blue? Sorry, Valium reference there!
> Anyway, my whole point in all of this is that of all the different
> technologies coming out of Redmond, I wouldn't write this one off
> right away. I think using VEE together with .NET can be very powerful.
It's component aspects (that which I have been focused on - um, in a "in my
spare time" sort of way - for almost a year now) are certainly much better
than COM. And it's a godsend for scripting. There are aspects that I really
abhor though. These mostly have to do with MS's planned commercial ".NET
Services" exploits. As much of their original plan has not come to pass, I
have a "wait and see" attitude.
As far as the VEE community is concerned, yes, it's going to be wonderful.
We don't need to be that concerned with speed, and that front will improve
with time anyway.
For those of us who were Windows programmers to begin with, it stinks to see
years of learning get flushed, but It's not like it hasn't happened before.
Most of us were DOS programmers at one time too.
I still plan to focus primarily on the CFI, so those of you who get stuck
with that can still count on me for help and advice. I'll experiment with
the new way as I work through my books, but it won't really be a priority.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
environment, i.e. good memory management, clean interface to all i/o calls,
friendly with the OS when handling the reg space, etc., etc. And especially
working well with other code. Can you imagine, a tug of war over some
interrupt or some resource.
I don't think managed means managing the author, but more that the code is
well behaved, hence, managed by the OS.
Rufus
-----Original Message-----
From: HILL,KEITH (A-Loveland,ex1) [mailto:keith_hill@agilent.com]
Sent: Tuesday, October 05, 2004 1:29 PM
To: VRF
Subject: [vrf] RE: FW: RE: AW: RE: Do you use .NET in VEE?
> -----Original Message-----
> From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
> Sent: Tuesday, October 05, 2004 2:21 AM
> To: 'HILL,KEITH (A-Loveland,ex1)'; 'VRF'
> Subject: RE: [vrf] FW: RE: AW: RE: Do you use .NET in VEE?
>
> > I think that's the first time I've heard someone refer to the Win32
API
> > as simple.
>
> Well - granted drawing is a pain in the rear and it does take quite a
> while to ferret out some of the finesse functionality. Some of the
> security is really twisted too. But it's all your basic C API for the
most
> part. I've been using it for some time and feel quite at home with
it, so
> to me it looks more or less "simple". Maybe "not drastically
confusing"
> would be a better way to put it.
For me, the major problem is the flat nature of the Win32 API. I find the
hierarchical nature of the .NET namespace approach much more suitable to my
AR/neat-freak nature. For me, it is easier to guess where something might
be from a smaller set of names (namespaces) vs the thousands of functions in
the WIN32 API.
> > So the raw API of the future will be a managed API.
>
> I'm sincerely hoping this never comes to pass. This concept was
abandoned
> once before (or maybe more than once - once that was talked about
anyway)
> and I'm hoping that happens again. My hardware will not handle it. Or
at
> least I'm not willing to put up with the endless wait times I'm
getting
> from even simple .NET examples. I can't imagine waiting endlessly if
the
> whole OS works that way.
Well Longhorn hasn't shipped yet and anything can happen between now and
then but that is their current plan of record. Check out the Wikipedia on
this:
>
> > So what's the big deal about managed code?
>
> We'll just have to agree to disagree about this. Your "good" is my
"bad".
> I can live with that
>
> About access to a great library - well, it's always been there in the
form
> of the compiled function interface. With the exception of callbacks, I
> have yet to find a function I can't call from VEE with the CFI. Sure,
the
> framework makes it easier because you don't have to spoof types or
come up
> with definitions, but the cost of this convenience is a bit too high
for
> my taste.
>
> Qualify that with the admission that I'm a self-confessed prudy old
SOB. I
> squeeze the toothpaste tube from the bottom, AC/DC comes before Blue
> Oyster Cult, my tools are always where they are supposed to be... The
one
> exception is my hard drive space. They're all a total mess. Well, and
the
> laundry usually finds it's way into Bill Murray's "graduated" system
> ("This shirt? Hang it outside for 15 minutes - good as new).
>
> Although, I have yet to divine what hierarchical system this framework
> fits into. That's for later though. I'm still working on the guts of
MSs
> new way. Maybe someday the light bulb will go on.
>
> > The CLR provides automatic memory management so that folks
> > programming in a managed language don't have to worry about explicit
> > memory management.
>
> And here I say that explicit management is a good thing (again, your
bad
> is my good). It forces one to think about how data structures are laid
> out, how memory will be used and how to make the best of access,
> iteration, allocation, yadda yadda. Explicit management promotes
> efficiency. It's easy to argue that such fine attention to detail is
not
> necessary because of CPU speed and memory size, but "just because you
can
> doesn't mean you should." Why make a user wait ten seconds for an
answer
> when less than one second is sufficient given more careful
programming?
>
> Iterative processes, data processing, table indexing... these are
exactly
> the operations that need to be optimized in quality software yet these
are
> exactly the operations that suffer most under managed scenarios. I
have a
> really hard time giving up storage or speed just because it saves me a
day
> of programming.
>
> > The obtrusive and invasive CLR management you refer to is what makes
> > .NET valuable IMO.
>
> See! We disagree!
>
> > If you want to understand .NET from the bottom up, have a look at
the
> > book "Essential .NET" by Don Box or "Applied Microsoft .NET
Programming"
> > by Jeffrey Richter.
>
> Got the first, not the second though I have other Richter stuff. C#
> Unleashed is nice but confirms many of my reservations about
collections,
> string handling & even gives me a gloomy view of PInvoke - that which
I
> thought might be a godsend.
>
> I'll be quite interested to see MSs next-gen "managed" OS, though I'm
sure
> I probably won't run it and I doubt I'll write for it. I've been
watching
> this whole thing from a distance for several years now and it has
failed
> to excite me - much as Java fails to excite me. I've participated in
the
> "managed" concept for years. In fact, one of my first practical
programs
> was a managed user environment for DEC MU-BASIC under RT-11. It was
the
> only way I could prevent my classmates from stealing my source code!
>
> I didn't like it then, I didn't like it as I tried different
variations on
> it in the intervening years and I don't like it now. Unless of course
I'm
> the one managing things.
>
> I'm just a control freak
>
> At any rate, I'll keep an open mind. Just because I don't like it
doesn't
> mean I don't tinker with it now and again. After all, I didn't like
VEE
> when I first used it either. The CFI, type spoofing and MoFOs changed
all
> that. I've only been seriously looking at this for a year and I
haven't
> seriously dissected the library yet. It's possible that I'll find
> something that will make up for all the misgivings I have about this
whole
> .NET concept.
> -SHAWN-
---
You are currently subscribed to vrf as: rwarren@amti.net To subscribe send a
blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".