Talk of VB.Net vs C# is basically irrelevent??

[Richardb]

Isn't all the hoo haa regarding whether to use VB.Net or C# basically irrelevent?.
I will have the choice of which dotnet language to use dictated to me by
management.

[John Butler]

"Richardb" <rbuckingham@loyalty-magic.com> wrote in message
news:3b858e72$1@news.devx.com...
>
> Isn't all the hoo haa regarding whether to use VB.Net or C# basically
irrelevent?.
> I will have the choice of which dotnet language to use dictated to me by
> management.

Well, some of use are:

a) management
b) not bound by any management

therefore, the discussion of C# vs Visual Ronnie/Fred/Albert vs Delphi vs
Java vs blah blah, remains a topic of high interest.

Since many of our careers are highly dependent on programming in general and
MS specifically, this issue is not going away anytime soon...

...at least until it becomes obvious to all that C# is the "Chosen One", that
is....


And, as for you, wait in your cubicle until Pointy Haired Boss tells you
what to do! <grin>

rgds
John Butler

[Arthur Wood]

And some of us are in a situation where the management will allow the use
of a mix of tools, as long as the tools are essetnially compatible - and
VB.Net/C# are EXTREMELY compatible - it is very realistic to build SOME pieces
with VB.NET and other pieces with C# and still other pieces with C++.NET

So the discussion is very relevant.

Arthur Wood


"John Butler" <jrbutler@nospambtclick.com> wrote:
>
>"Richardb" <rbuckingham@loyalty-magic.com> wrote in message
>news:3b858e72$1@news.devx.com...
>>
>> Isn't all the hoo haa regarding whether to use VB.Net or C# basically
>irrelevent?.
>> I will have the choice of which dotnet language to use dictated to me
by
>> management.
>
>Well, some of use are:
>
>a) management
>b) not bound by any management
>
>therefore, the discussion of C# vs Visual Ronnie/Fred/Albert vs Delphi
vs
>Java vs blah blah, remains a topic of high interest.
>
>Since many of our careers are highly dependent on programming in general
and
>
>...at least until it becomes obvious to all that C# is the "Chosen One",
that
>is....
>
>
>And, as for you, wait in your cubicle until Pointy Haired Boss tells you
>what to do! <grin>
>
>rgds
>John Butler
>
>
>
>

[Aaron Sevivas]

i think platform is a more relavant business decision than choosing a language.
if u choose the .NET platform and build a components based system, i can
see why choosing a syntax would be irrelevant. Many companies like to standardize
though.

If I had to make a decision on syntax, I would choose c# or java. For all
those java coders out there, isn't the syntax beautifully elegant. I worked
with vb/c++ for 5 years, switched to Java(J2EE) a year ago, got my certifications
and so forth. Just last week I found a VB project on my harddrive(One of
those old "home" projects that you start/stop/rewrite every couple months).
I said, "yeah, I'm gonna clean this up and finish it!" I noticed straight
away how abnormal the vb syntax is. The dim keyword, the lack of support
for proper class display in the ide (Have all gui code under one heading,utils
here,etc,etc) No contructors so on/so forth..(we've all talked about this
before).. Anyways, I still think Java is sorely lagging behind MS .NET stuff
when it comes to depth of integration in the operating system (java is a
lowest common denominator language because of its cross-platform ability).
For example, I think Java gui's _feel_ nasty.. Any of you who have used
them can sort of feel its non-nativeness when using them. Java programmers,
raise your hand if your tired of 300 lines of GUI code just to make a simple
gui with a few labels and text boxes (thisObject.addActionListener(new ActionListener(){do
something..}).. ugh.. In other words, give me java syntax and structures,
with direct Windows Integration (but it won't run on Linux! Boo frigging
hoo!).. In other words, C#.

my couple o' coins

~aaron
"Arthur Wood" <wooda@saic-trsc.com> wrote:
>
>And some of us are in a situation where the management will allow the use
>of a mix of tools, as long as the tools are essetnially compatible - and
>VB.Net/C# are EXTREMELY compatible - it is very realistic to build SOME
pieces
>with VB.NET and other pieces with C# and still other pieces with C++.NET
>
>So the discussion is very relevant.
>
>Arthur Wood
>
>
>"John Butler" <jrbutler@nospambtclick.com> wrote:
>>
>>"Richardb" <rbuckingham@loyalty-magic.com> wrote in message
>>news:3b858e72$1@news.devx.com...
>>>
>>> Isn't all the hoo haa regarding whether to use VB.Net or C# basically
>>irrelevent?.
>>> I will have the choice of which dotnet language to use dictated to me
>by
>>> management.
>>
>>Well, some of use are:
>>
>>a) management
>>b) not bound by any management
>>
>>therefore, the discussion of C# vs Visual Ronnie/Fred/Albert vs Delphi
>vs
>>Java vs blah blah, remains a topic of high interest.
>>
>>Since many of our careers are highly dependent on programming in general
>and
>>
>>...at least until it becomes obvious to all that C# is the "Chosen One",
>that
>>is....
>>
>>
>>And, as for you, wait in your cubicle until Pointy Haired Boss tells you
>>what to do! <grin>
>>
>>rgds
>>John Butler
>>
>>
>>
>>
>

[Kevin]

That's it in our case. Corporate has decided on C#, probably because all the
C bigots are there. The outlying business units like us are full of VB programmers.
It will be good for us personally to learn C#, but I think it's a dumb business
decision. All of us are immediately turned into junior programmers who are
developing the applications of the future for our company. We'll see.

"Richardb" <rbuckingham@loyalty-magic.com> wrote:
>
>Isn't all the hoo haa regarding whether to use VB.Net or C# basically irrelevent?.
>I will have the choice of which dotnet language to use dictated to me by
>management.

[Willy Van den Driessche]

Arthur, have a look in the VB.announcements room (and not for my post).
Seems VB8 and C#2 will be diverging again.

--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html
"Arthur Wood" <wooda@saic-trsc.com> wrote in message
news:3b85acd2$1@news.devx.com...
>
> And some of us are in a situation where the management will allow the use
> of a mix of tools, as long as the tools are essetnially compatible - and
> VB.Net/C# are EXTREMELY compatible - it is very realistic to build SOME
pieces
> with VB.NET and other pieces with C# and still other pieces with C++.NET
>
> So the discussion is very relevant.
>
> Arthur Wood
>
>
> "John Butler" <jrbutler@nospambtclick.com> wrote:
> >
> >"Richardb" <rbuckingham@loyalty-magic.com> wrote in message
> >news:3b858e72$1@news.devx.com...
> >>
> >> Isn't all the hoo haa regarding whether to use VB.Net or C# basically
> >irrelevent?.
> >> I will have the choice of which dotnet language to use dictated to me
> by
> >> management.
> >
> >Well, some of use are:
> >
> >a) management
> >b) not bound by any management
> >
> >therefore, the discussion of C# vs Visual Ronnie/Fred/Albert vs Delphi
> vs
> >Java vs blah blah, remains a topic of high interest.
> >
> >Since many of our careers are highly dependent on programming in general
> and
> >
> >...at least until it becomes obvious to all that C# is the "Chosen One",
> that
> >is....
> >
> >
> >And, as for you, wait in your cubicle until Pointy Haired Boss tells you
> >what to do! <grin>
> >
> >rgds
> >John Butler
> >
> >
> >
> >
>

[Richard Curzon]

That reference is interesting... and a bit scary....

http://news.zdnet.co.uk/story/0,,t356-s2093679,00.html

---8<--- snip ---8<---
Microsoft will diverge its programming languages C# (pronounced C sharp) and
Visual Basic in a tightrope act designed to retain its massive legacy
developer community during the move to Web services. Microsoft told
ComputerWire that the changes will be made after the company delivers the
first implementation of its Visual Studio.NET development suite later this
year.

C# will become more complex through the addition of features designed to
simplify development of Web services, and take it even closer to future
versions of Sun Microsystems' Java. Visual Basic will eschew high-end
features, and be targeted at Rapid Application Development (RAD)
environments.

Brian Harry, Microsoft common language runtime (CLR) product unit manager,
said: "Visual Basic will become RADish and C# more complex ... more
divergence will happen. Visual Basic and C# will be the mainstream
languages." He did not say how Visual Basic, which is already a simple
programming language, will be tailored to RAD environments.
---8<--- snip ---8<---


Too much media mumbo jumbo to dig deep... "C# will become more complex ...
to simplify development "

Cut to developer saying: "Thanks for making it more complex, it's simpler
now... " <g>.

I really doubt that VB.net v 2 will abandon any VB.net version 1 working
code. It's more likely the generics/template support that C# will be
getting will not be in VB.net. Pretty much as expected. And probably not
much else, you certainly can't tell from the article.

Other than that, would they really cut VB of from taking advantage of
changes as the CLR evolves? Somehow I doubt it... what do you think?

regards
Richard.

--
-----
Live without dead time - Raoul Vaneigem
May I borrow your towel, my car just hit a water buffalo - Chevy Chase
Hate spam? Do what you can: www.spamcop.net customer

[Kathleen Dollard]

Richard,

> Other than that, would they really cut VB of from taking advantage of
> changes as the CLR evolves? Somehow I doubt it... what do you think?

I think strategy is good. Still trying to understand this strategy. Do you
understand generics? They sound like a RAD tool on the surface, so it is not
clear to me why they would be in the less RAD tool. Potentially the
divergence is positive, because it would give a RAD and a deep tool that
worked and played well together. It will be interesting to see what they
mean by more RAD, since I think RAD is ready for some radical reworking
(like VB was in its infancy). But as always, the devil's in the details.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Who Cares]

"Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote in
message news:3b86d218@news.devx.com...
> Arthur, have a look in the VB.announcements room (and not for my post).
> Seems VB8 and C#2 will be diverging again.


Duh. See Microsoft in panic mode.

Somebody made some stupendous decisions lately...

Product Activation - $500 dollars
Fake letter campaign - $100K dollars
Java lawsuit - $20 million dollars
Discontinuing plug-in support and screwing
millions of customers and companies
without warning?!

PRICELESS!

Attendance at JavaOne 2001 was down. Down
around 30%. Attendance at most of the IT
conferences was down. A few of them
were closed, even.

But attendance is up 50% at one conference -
http://linuxworldexpo.com/user-image...highlights.pdf

Intel hedging their bets -
http://www.linuxworld.com/ic_671140_6995_1-3133.html

HP making new bet -
http://www.linuxworld.com/ic_670988_6995_1-3134.html


Go, you nutty Ballmer guys, go!

[Willy Van den Driessche]

"Kathleen Dollard" <kathleen@nomailplease.org> wrote in message
news:3b870ac8$1@news.devx.com...
> Richard,
>
> > Other than that, would they really cut VB of from taking advantage of
> > changes as the CLR evolves? Somehow I doubt it... what do you think?
>
> I think strategy is good. Still trying to understand this strategy. Do you
> understand generics?

For an excellent article on generics (In Java but that's more or less the
same) read the latest JavaPro magazine.
Generics are the same as templates. However, the devil is in the details.
C++ templates 'generate' classes and functions while the Java proposition
uses generics as syntactic sugar to avoid the many typecasts required by
Java (and soon C#).


>They sound like a RAD tool on the surface, so it is not
> clear to me why they would be in the less RAD tool. Potentially the
> divergence is positive, because it would give a RAD and a deep tool that
> worked and played well together. It will be interesting to see what they
> mean by more RAD, since I think RAD is ready for some radical reworking
> (like VB was in its infancy). But as always, the devil's in the details.
>
> --
> Kathleen
> (MS-MVP)
> Reply in the newsgroup so everyone can benefit
> --
>
>
--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html

[Hussein Dharsi]

"Kevin" <Kevin.Verble@GreatPlains.com> wrote:
>
>That's it in our case. Corporate has decided on C#, probably because all
the
>C bigots are there. The outlying business units like us are full of VB programmers.
>It will be good for us personally to learn C#, but I think it's a dumb business
>decision. All of us are immediately turned into junior programmers who are
>developing the applications of the future for our company. We'll see.
>
>"Richardb" <rbuckingham@loyalty-magic.com> wrote:
>>
>>Isn't all the hoo haa regarding whether to use VB.Net or C# basically irrelevent?.
>>I will have the choice of which dotnet language to use dictated to me by
>>management.
>


Whether you go with VB.NET or C# you will still be a junior. It is not the
underlying language that is different but it is the Architecture. When I
moved to Delphi a few years ago, It was a steep learning curve, but now I
see myself looking at C# and saying aha! exactly like Delphi - After all
the designer of the .NET framework and C# is Anders who is the inventor of
Delphi & the VCL Architecture!.

[Richard Curzon]

If you're still checking here's another belated reply <g>.

.... it's easy enough to say in a nutshell.

In VB6, you sometimes use VARIANTS (for args and return values) just to
avoid building a routine for integer, another for currency, another for
strings, etc.

The template/generic idea is to get the best of both worlds, with "just a
trick or two". The "template" looks like your routine but there's a
placeholder for the "types" that might change. In essence, the type of the
routine becomes a variable.

The template code wouldn't compile... it's not written for the compiler.
It's handled by that marvelous C trick meister, the "precompiler". By the
time the compiler sees it, a real type has been substituted.

The benefit: you have only one version to maintain for all types. The
catch: you have only one version to maintain for all types... and efficiency
issues. Often, it looks cleaner at the 1000 foot level than in the code.

So many times generics are compromises in efficiency anyway by the time they
are complete. Or else they require writing an operator overload or two just
to support the generic. Or they get more complex with nested #ifdefs
anyway.

Bottom line, is the code really easier to maintain with all the tricks?....
rather than just writing the code that's needed? Another seductive C
complication of just the sort VB should resist IMO.

VB being able to use templates in "readonly" mode suggests they are becoming
part of CLS standard though, and that'd be the first major CLS feature that
would be outside VB capability I think? VB can't use pointers, but they are
not part of the CLS specification.

regards
Richard





--
-----
Live without dead time - Raoul Vaneigem
May I borrow your towel, my car just hit a water buffalo - Chevy Chase
Hate spam? Do what you can: http://spamcop.net customer
"Kathleen Dollard" <kathleen@nomailplease.org> wrote in message
news:3b870ac8$1@news.devx.com...
> Richard,
>
> > Other than that, would they really cut VB of from taking advantage of
> > changes as the CLR evolves? Somehow I doubt it... what do you think?
>
> I think strategy is good. Still trying to understand this strategy. Do you
> understand generics? They sound like a RAD tool on the surface, so it is
not
> clear to me why they would be in the less RAD tool. Potentially the
> divergence is positive, because it would give a RAD and a deep tool that
> worked and played well together. It will be interesting to see what they
> mean by more RAD, since I think RAD is ready for some radical reworking
> (like VB was in its infancy). But as always, the devil's in the details.
>
> --
> Kathleen
> (MS-MVP)
> Reply in the newsgroup so everyone can benefit
> --
>
>

[Mike Mitchell]

On Sat, 15 Sep 2001 15:10:25 -0400, "Richard Curzon"
<rcurzon@spamcop.net> wrote:

>The template code wouldn't compile... it's not written for the compiler.
>It's handled by that marvelous C trick meister, the "precompiler". By the
>time the compiler sees it, a real type has been substituted.

I think far too many tricks are being used nowadays at the behest of
the software reuse claimants. The simple, boilerplate software which
forms many of today's business applications is being made overly
complex by coding gurus who think "complexity" means "good". I don't
agree. Often the simplest of solutions turns out to be the best one in
the long run. Even if it isn't perfect in every sense, being simple it
*is* easy to fix if it does go wrong. A very complex system, however,
will still go wrong no matter what, because you can never guarantee
that the same guru who originally worked on the project is going to be
around forever or that you will be able to find a replacement guru
with similar credentials.

My watchword with program design always has been to keep it as simple
as possible so that a newbie can follow the code, or a contractor can
be brought in if I happen to fall under a bus. And because my software
works very well (because I take great pains to make it so), even
though it is conceptually and practically simple, I eschew all forms
of complexity wherever possible.

..NET = complexity.

MM

[Ronald Laeremans [MSFT]]

Hi Richard,

What is a "pre-compiler"? If you mean pre-processor, then that is definitely
not how templates are implemented in any C++ compiler.

Ronald Laeremans
Visual C++ compiler team

"Richard Curzon" <rcurzon@spamcop.net> wrote in message
news:3ba3a741@news.devx.com...
> It's handled by that marvelous C trick meister, the "precompiler". By
the
> time the compiler sees it, a real type has been substituted.
>
> The benefit: you have only one version to maintain for all types. The
> catch: you have only one version to maintain for all types... and
efficiency
> issues. Often, it looks cleaner at the 1000 foot level than in the code.
>
> So many times generics are compromises in efficiency anyway by the time
they
> are complete. Or else they require writing an operator overload or two
just
> to support the generic. Or they get more complex with nested #ifdefs
> anyway.
>
> Bottom line, is the code really easier to maintain with all the
tricks?....
> rather than just writing the code that's needed? Another seductive C
> complication of just the sort VB should resist IMO.
>
> VB being able to use templates in "readonly" mode suggests they are
becoming
> part of CLS standard though, and that'd be the first major CLS feature
that
> would be outside VB capability I think? VB can't use pointers, but they
are
> not part of the CLS specification.
>
> regards
> Richard

[Willy Van den Driessche]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3ba4d01a.5237228@news.devx.com...
> On Sat, 15 Sep 2001 15:10:25 -0400, "Richard Curzon"
> <rcurzon@spamcop.net> wrote:
>
> >The template code wouldn't compile... it's not written for the compiler.
> >It's handled by that marvelous C trick meister, the "precompiler". By
the
> >time the compiler sees it, a real type has been substituted.
>
> I think far too many tricks are being used nowadays at the behest of
> the software reuse claimants. The simple, boilerplate software which
> forms many of today's business applications is being made overly
> complex by coding gurus who think "complexity" means "good". I don't
> agree. Often the simplest of solutions turns out to be the best one in
> the long run. Even if it isn't perfect in every sense, being simple it
> *is* easy to fix if it does go wrong. A very complex system, however,
> will still go wrong no matter what, because you can never guarantee
> that the same guru who originally worked on the project is going to be
> around forever or that you will be able to find a replacement guru
> with similar credentials.

I you have a guru who makes things complex then he's the wrong type of guru.
One the most important design goals is to make the simplest thing that can
work.
Not more than two years ago I always wanted to make things that would be
expandable in all directions. I've always had this urge in me, but in this
case our deployment mechanism was to blame. When one of the base components
was 'wrong' we had to deploy the entire application again, instead of one
DLL which had be envisioned by our managers. Therefore I did my best to
foresee as much as I could beforehand. It worked for a couple of months.
Needless to say, I as much a visionary as anybody else, so more often than I
would like, we had to change the base components.
Lucky for me, that was about the time I read Becks book about eXtreme
Programming. I took a long deep breath and convinced my management to change
the deployment politics. Then I started to feel free again. We refactored
the application throwing out everything we had never used before ( but which
was 'expected' to be used once ). Our application is much cleaner now
(we've managed to pull some lava out). The design is simpler now but still
not as simple as could be.
My own moral of the story is that simplicity is a surprisingly difficult
thing to accomplish. Furthermore, and that's really troubling me,
simplicity seems to be partly in the eye of the beholder. I find some of my
designs extremely simple, while not all of my colleagues feel the same way.
It's difficult to admit, but some times I must say to my colleagues 'trust
me, I know what I'm doing'. Sounds very megalomanic but really it isn't.
Now, after some principles have been applied (some for more than a year),
some colleagues suddenly experience an aha! moment. All of a sudden they
seem to 'see' ' the big why' of some designs. Now I am very aware that
this is an extremely long time and that I am to blame for not explaining it
until they do see it. Unfortunately, I have many problems explaining
'simple' things. (That's something everybody can experience in my little
website).
The thing is, I'm the 'local guru' at my place. The most important reason
is not that I am a super VB programmer (which, taken from the typical
answers in this newsgroups, I'm not) , but that I have more experience. I
am never too proud to listen to the advice of my colleagues and they've
already managed to convince me quite a lot. The thing is, if they don't
know something they always come to me. We think about it together and we
find a solution. Sometimes they blindfoldedly accept a proposition of mine.
I probably should remind them more often that something which takes 15
minutes to come up with is only as a good as that : a 15 minute design.
They rarely question a design, although I really urge them to do so. The
bottom line is that you are not made a guru. It's something your colleagues
make you, whether you want it or not.

>
> My watchword with program design always has been to keep it as simple
> as possible so that a newbie can follow the code, or a contractor can
> be brought in if I happen to fall under a bus. And because my software
> works very well (because I take great pains to make it so), even
> though it is conceptually and practically simple, I eschew all forms
> of complexity wherever possible.
>

I have yet to see the first project that can be taken over painlessly when
the entire existing staff leaves. I also have to see the first project that
painlessly survives an architect leaving.
I have a strong feeling that the simplicity you're talking about is not the
simplicity I'm talking about. Simplicity means for me : being easy to
understand and surviving (not foreseeing) obvious changes. Again,
complexity is not something you design for. We have had numerous
refactorings in the product life-cycle. If you don't constantly refactor a
growing project, complexity emerges just like that. Simplicity for me is
more like 'as simple as possible'. This doesn't imply that it is simple.
It only means that the complexities that are in there, are in for very good
reasons.



> .NET = complexity.
>
> MM
--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html