Re: Visual Basic.net

On 2005-07-26, Frank Adam <fajp@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, 24 Jul 2005 00:48:34 -0500, Tom Shelton
><tshelton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>>> Aduh, where is the surprise ? Talk about cramming it all down our
>>> throats. As i've said, welcome to Lego programming.
>>> Programmers from now on will not be classed on logical ability, but on
>>> memory retention.
>>> "Can you remember all the class trees ? Then you're a *great*
>>> programmer and here is your bonus." See anything wrong with that ?
>>
>>Simply not true. I'm sorry, but all the class in the runtime do is
>>encapsulate a bunch of common functionality. They let you get on with
>>
> So are you saying they are just wrapper classes, with absolutely no
> added error trapping, no overhead, extra flavouring, or water added ?
> Nothing that wouldn't be there if the API was accessed directly ? I
> very much doubt that, Tom.

I'm not saying that at all Frank, but it is all code I would have ended
up writing anyway...

> I have written a number of wrapper classes myself and never did i even
> imagine that having done so is not only for making life easier for me,
> at the cost of adding overhead.

I have written many myself. And yes, there is some additional overhead,
but not that much. For example my error trapping tends to be - trap,
translate, throw. Basically, I try to wrap the error with something
meaningful, and then let the client code deal with it.

> If said wrapper or DLL was to be written for multi-use, the amount of
> code would increase as various traps and other filters are added to
> make sure it's not the DLL that will crash, but rather, if possible,
> catch and delegate the error back to the caller in a safe fashion.
> This is the duty of a good DLL.

True, that's what I said above.

> At this stage it doesn't matter, whether the caller will only use one
> function out of the DLL, the whole DLL still loads into memory.

Exactly what I said above in regards to FileSystemWatcher. It's in
System.Dll. System.Dll is loaded for all .NET apps.

>>the job of solving the problem at hand, without worrying about writting
>>an XML parser. Look, I wrote a predictive dialer application in C# (it
>>is used in Collections, not telemarketing by the way) - the framework
>>didn't do anything to help me come up with algorithms to give the dialer
>>the ability to allocate line resources dynamically. I had to come up
>>with that.
>>
> Algos are simply thought processes. It is just thinking up how a
> process should take place. Without that there would be no life as we
> know it, since getting through a closed door would be impossible..
> That is not what i've meant by being dumbed down.
> I agree with one of your previous statements, that you can do a lot
> more with .Net a lot quicker, but this needs little programming
> proess, it simply requires that you understand and know all the
> myriads of library functions. Not unlike some helpdesks, where the so
> called "experts" are reading off a cue sheet, but if you ask them
> anything that is not on the sheets, they just hum and ahm...
> And IMHO, this is where .Net is leading the industry. Nice and
> "managed" sheep is what MS wants you to be today..

I see the boost in productivity the major benifit. Are there tradeoffs?
Sure. But, I don't agree that in general this going to cause a dumbing
down. I agree that is possible that this will happen in some instances,
but I think having the framework libraries frees you from the drudgery
and lets you focus more on the problems.

Frank, just so you know - I do respect your oppinion.

--
Tom Shelton
.

Relevant Pages

  • Re: .Net packaging/wrapper application?
    ... the simple answer to DLL Hell for Visual Basic apps was simply to place a copy of the needed DLLs in the same directory as your executable. ... The way Windows works is to look in the executable's directory for a needed DLL BEFORE using the registry to find one EVEN IF THE REFERENCED DLL IS REGISTERED ON THE PC RUNNING THE APPLICATION THAT NEED IT. ... Perhaps I'm getting old and but what really bothers me is nobody seems to notice this--maybe the 80s was before they got into programming. ... Looks to me like Jim is looking for the .NET equivalent of compiling with static libraries to produce a single executable. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: newbie question - how to enumerate font
    ... I've started programming vb.net for 1 month.... ... you tell .NET the name and information of the DLL function ... The problem is that EnumFontFamilies ... requires that you give it a "callback" function. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: newbie question - how to enumerate font
    ... I've started programming vb.net for 1 month.... ... you tell .NET the name and information of the DLL function ... EnumFontFamilies function. ... requires that you give it a "callback" function. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: H.D. content visible on web
    ... I am pretty sure that they are others who have programming experience out ... n-tier VB application on the Citrix Server Terminal farm and the Com+ ... So a dll that is instantiated on the server by said VB application ... Well, I went to that website too and came from behind the router, disabled ...
    (comp.security.firewalls)
  • Re: Runtime overflow error
    ... if I put error trapping into my VB code (ie. ... >> I think the problem lies deeper down: I am in fact not defining all my ... > I'm wondering if you have a mismatch between the DLL routine and the VB ... > I working sample that illustrates the probelm might help. ...
    (microsoft.public.vb.syntax)