I'm confused !!!

[cgts]

There was a time when I was a gun programmer in upto VB6 and C++ 6. I am
wanting to get back into it after a long stay and was looking at beginning
again in .NET (C++, VB Etc.) I had a bt of a play today at making a DLL
in VB and one in C++ and they worked fine in a .NET test app. But when I
tried to use the DLL from Excel or Access 2000 they won't reference the DLL.
Error is incomaptible resource or similar.

Does this mean that there is no backward compatibilty between .NET and previous
apps. Or am I missing a page.

I hope there is something wrong with what I am doing cos I just ordered .NET
programme

Someone please explain in very simple terms the pro's and con's of .NET

Kind Regards

Colin

[Kent]

Colin,

Welcome to the new world. You cannot yet use .Net components from office.

The story does not get any better I'm afraid, because you'll see that you
cannot just drop in your old VB6 code and compile it under VB.Net. Backward
compatibility is lost. This may or may not be an issue for you. For your
own sake I hope it is not.

Microsoft has apparently decided that the old COM based way of doing things
is evil and has decided to pull the rug out from under us with this Java
like platform called .Net. It is more like Java and less like VB. You get
a Virtual Machine which is called the .Net runtime, which is capable of using
any .Net langauge. If you take the time to do some research, you will find
that even though the .Net runtime allows you to use different languages,
all of the languages are very similar and there is no clear advantage to
using one over the other. They all have pretty much the same strengths and
weaknesses. Since the new language C# has been submitted to the ECMA as
a standard and all of the .Net libraries are written in C#, it seems to be
the clear choice to use for .Net development rather than VB which has a track
record of being broken by Microsoft.

One could also argue that since parts of .Net are derived from Microsoft's
old Java (Visual J++) technology, that Java would be a good choice to use
rather than .Net. By creating .Net Microsoft validated Java as a platform.
.Net is however not WORA like Java is. The entire .Net strategy is questionable
in my own opinion, since it is restricted to the Windows OS.

Kent

"cgts" <vb.@127.0.0.1> wrote:
>
>There was a time when I was a gun programmer in upto VB6 and C++ 6. I am
>wanting to get back into it after a long stay and was looking at beginning
>again in .NET (C++, VB Etc.) I had a bt of a play today at making a DLL
>in VB and one in C++ and they worked fine in a .NET test app. But when
I
>tried to use the DLL from Excel or Access 2000 they won't reference the
DLL.
> Error is incomaptible resource or similar.
>
>Does this mean that there is no backward compatibilty between .NET and previous
>apps. Or am I missing a page.
>
>I hope there is something wrong with what I am doing cos I just ordered
.NET
>programme
>
>Someone please explain in very simple terms the pro's and con's of .NET
>
>Kind Regards
>
>Colin

[Chris]

Kent...not trying to pick a fight...just provide info...

1. you can call .NET components from COM based applications and objects...see
MS on 'Calling a .NET Component from a COM Component'...same applies for
Office VBA and VB6.

2. all .NET languages are not (or will not) be the same...C# and VB.NET
might (in the final analysis) be similar and provide similar results...but
the other non-MS languages that are being made .NET compliant are very different
and while they compile to the same thing (theoretically) they will offer
something that Java can't...and that's speed to delivery for developers coming
from other backgrounds...bottom-line will continue to be important to many
companies...Java doesn't deliver in that area...if a manager can leverage
his COBOL developers' skillset into the web/n-tier arena w/o having to make
them Java gurus, it offers some serious money saving potential.

3. There was/is a VM in VB6, the VB runtimes have always existed...so the
idea/concept of a virtual machine is not new to .NET.

4. .NET is currently restricted to Windows, but there are a number of third-party
projects going on to port to Linux (the CLR). Time will tell whether or
not that is going to work...probably won't fly...but still, it will be an
option if someone is 'off' enough to think it's of benefit.

5. Yes, there are some similarities between the direction MS has headed
w/ .NET and the tried and true Java world, but some fundamental differences
in the 'textbook implementation and architecture', i.e. the whole tired petshop
example...yea, Java guys are tired of hearing it, but the facts are facts,
regardless of how you implement/architect the Java solution here...on comparible
hardware, the .NET solution is more scalable and performs much better...it's
up to developers and managament to decide if they want something more forgiving
(and only slightly more forgiving that the .NET solution) on the code end,
or something that performs.

Just some thoughts...

Chris

"Kent" <kp@kp.org> wrote:
>
>Colin,
>
>Welcome to the new world. You cannot yet use .Net components from office.
>
>The story does not get any better I'm afraid, because you'll see that you
>cannot just drop in your old VB6 code and compile it under VB.Net. Backward
>compatibility is lost. This may or may not be an issue for you. For your
>own sake I hope it is not.
>
>Microsoft has apparently decided that the old COM based way of doing things
>is evil and has decided to pull the rug out from under us with this Java
>like platform called .Net. It is more like Java and less like VB. You
get
>a Virtual Machine which is called the .Net runtime, which is capable of
using
>any .Net langauge. If you take the time to do some research, you will find
>that even though the .Net runtime allows you to use different languages,
>all of the languages are very similar and there is no clear advantage to
>using one over the other. They all have pretty much the same strengths
and
>weaknesses. Since the new language C# has been submitted to the ECMA as
>a standard and all of the .Net libraries are written in C#, it seems to
be
>the clear choice to use for .Net development rather than VB which has a
track
>record of being broken by Microsoft.
>
>One could also argue that since parts of .Net are derived from Microsoft's
>old Java (Visual J++) technology, that Java would be a good choice to use
>rather than .Net. By creating .Net Microsoft validated Java as a platform.
> .Net is however not WORA like Java is. The entire .Net strategy is questionable
>in my own opinion, since it is restricted to the Windows OS.
>
>Kent
>
>"cgts" <vb.@127.0.0.1> wrote:
>>
>>There was a time when I was a gun programmer in upto VB6 and C++ 6. I
am
>>wanting to get back into it after a long stay and was looking at beginning
>>again in .NET (C++, VB Etc.) I had a bt of a play today at making a DLL
>>in VB and one in C++ and they worked fine in a .NET test app. But when
>I
>>tried to use the DLL from Excel or Access 2000 they won't reference the
>DLL.
>> Error is incomaptible resource or similar.
>>
>>Does this mean that there is no backward compatibilty between .NET and
previous
>>apps. Or am I missing a page.
>>
>>I hope there is something wrong with what I am doing cos I just ordered
>.NET
>>programme
>>
>>Someone please explain in very simple terms the pro's and con's of .NET
>>
>>Kind Regards
>>
>>Colin

[Kent]

"Chris" <vb.@127.0.0.1> wrote:
>
>Kent...not trying to pick a fight...just provide info...
Gotcha

>
>1. you can call .NET components from COM based applications and objects...see
>MS on 'Calling a .NET Component from a COM Component'...same applies for
>Office VBA and VB6.

I was not aware of this, Thanks for correcting me.

>2. all .NET languages are not (or will not) be the same...C# and VB.NET
>might (in the final analysis) be similar and provide similar results...but
>the other non-MS languages that are being made .NET compliant are very different
>and while they compile to the same thing (theoretically) they will offer
>something that Java can't...and that's speed to delivery for developers
coming
>from other backgrounds...bottom-line will continue to be important to many
>companies...Java doesn't deliver in that area...if a manager can leverage
>his COBOL developers' skillset into the web/n-tier arena w/o having to make
>them Java gurus, it offers some serious money saving potential.

You cannot cleanly implement a language in it's pure form on top of .Net.
The best you can hope for is to capture the essence of that language. The
platform has restrictions that are imposed which makes every .Net language
feel the same. So every "language" that is implemented on top of .Net feels
oddly different from it's native counter part. Since these languages all
share pretty much the same capabilities from the platfrom, it is pointless
to have more than one.

As for money saving potential, there is a learning curve required to learn
.Net no matter what language you use. There may be syntactical similarities
in the .Net languages but that is all they are is similarities one cannot
expect to be productive on .Net just because he is using Cobol that compiles
on .Net.

Also, there are points of compensation that come into play as well. Should
a C# developer make more than say a VB.Net developer, when both can achieve
the same result in the same amount of time? No, but one will get paid more
than the other. Check monster.com for proof of this.

The last point is maintenance, most shops will standardize on one language
and use it exclusivley. It is Ironic that .Net makes this easier than ever
to do because all of the languages have the same capabilities. Why would
you use more than one when their is no benefit? There used to be real advantages
to mixing C++ and VB. There is no real advantage to mixing VB and C#.

>
>3. There was/is a VM in VB6, the VB runtimes have always existed...so the
>idea/concept of a virtual machine is not new to .NET.

There were runtimes in QuickBasic as well. The .Net runtime models Java
more closely than it does or any previous version of Microsoft BASIC.

>4. .NET is currently restricted to Windows, but there are a number of third-party
>projects going on to port to Linux (the CLR). Time will tell whether or
>not that is going to work...probably won't fly...but still, it will be an
>option if someone is 'off' enough to think it's of benefit.

The ".Net" ports being done are not supported by Microsoft and there is no
clear standard for implementing the libraries. WORA cannot be ensured because
of this. Only a fool would bet on .Net being supported on any platform other
than Windows. There are also patents that get in the way of a true open
source implementation. If Microsoft were to license out the technology to
other companies then I would agree with you.

>5. Yes, there are some similarities between the direction MS has headed
>w/ .NET and the tried and true Java world, but some fundamental differences
>in the 'textbook implementation and architecture', i.e. the whole tired
petshop
>example...yea, Java guys are tired of hearing it, but the facts are facts,
>regardless of how you implement/architect the Java solution here...on comparible
>hardware, the .NET solution is more scalable and performs much better...it's
>up to developers and managament to decide if they want something more forgiving
>(and only slightly more forgiving that the .NET solution) on the code end,
>or something that performs.

What are the "facts" you take from the petshop example? I've seen this used
more and more lately by Microsoft enthusiasts to try and wedge their way
in to J2EE space. The argument falls apart too quickly though when one looks
into the true facts and not the "facts" being pitched by Microsoft at their
developer (marketing) events.

All I need say is that their is nothing like an Entity Bean in .Net. If
their had been, the benchmark may hold some clout.

[Kent]

Collin,

I was mistaken about my first point. It is at least possible to call .Net
components from Office. Chris points to an article in his post. The other
points in the post are the facts as I see them.

Kent

"cgts" <vb.@127.0.0.1> wrote:
>
>There was a time when I was a gun programmer in upto VB6 and C++ 6. I am
>wanting to get back into it after a long stay and was looking at beginning
>again in .NET (C++, VB Etc.) I had a bt of a play today at making a DLL
>in VB and one in C++ and they worked fine in a .NET test app. But when
I
>tried to use the DLL from Excel or Access 2000 they won't reference the
DLL.
> Error is incomaptible resource or similar.
>
>Does this mean that there is no backward compatibilty between .NET and previous
>apps. Or am I missing a page.
>
>I hope there is something wrong with what I am doing cos I just ordered
.NET
>programme
>
>Someone please explain in very simple terms the pro's and con's of .NET
>
>Kind Regards
>
>Colin

[Kunle Odutola]

cgts wrote:
> There was a time when I was a gun programmer in upto VB6 and C++ 6.
> I am wanting to get back into it after a long stay and was looking at
> beginning again in .NET (C++, VB Etc.) I had a bt of a play today
> at making a DLL in VB and one in C++ and they worked fine in a .NET
> test app. But when I tried to use the DLL from Excel or Access 2000
> they won't reference the DLL. Error is incomaptible resource or
> similar.

http://www.dotnet247.com/247reference/guide/53.aspx
http://msdn.microsoft.com/officedev/
http://www.c-sharpcorner.com/Code/20...elSheetGAG.asp

> Does this mean that there is no backward compatibilty between .NET
> and previous apps. Or am I missing a page.
>
> I hope there is something wrong with what I am doing cos I just
> ordered .NET programme
>
> Someone please explain in very simple terms the pro's and con's of
> .NET

http://hotwired.lycos.com/webmonkey/01/02/index3a.html (talks about the
beta)
http://www.fawcette.com/vsm/2002_04/...tments/ednote/
http://www.yale.edu/tp/framework.htm (Most direct descendant of .NET IMHO is
OmniVM not Talingent)

Enjoy,

Kunle

[Chris]

Yea, I agree that all these other languages are not going to be 'cleanly implemented',
not my point...only that from a syntax standpoint, it's going to be easier
to take a Cobol developer and stick them into the .NET environment if mgmt
so chooses to go this direction (yes, i agree, scary)...than to put them
into the Java realm cold...they are going to have a high level of familiarity
w/ the language and learn only the IDE and nuances of .NET initially...they
can transition to the new languages (C#, VB, whatever) as time permits...that
was my only point, that the curve is shorter...and the fact that (IMHO) the
MS IDE is way beyond everything else in providing an easy environment to
ramp up on in a new technology...

I agree that most places will standardize on a single language...you'd have
to be pretty out there not to...I would hope most companies would prefer
to be 'deep' rather than diverse...in the end, it's company bottom line,
not developer happiness...I'd love to know 10 languages...but nobody is going
to pay me to take the time to do it while they need work to be done...so
yea, hopefully, no company is going to have 10 different .NET languages going
on at one time (or worse, 10 on the same project)...I hope that wasn't the
MS goal in this :-)


<<<The .Net runtime models Java more closely than it does or any previous
version of Microsoft BASIC.>>>

I'll defer to you on this one, not a Java VM 'under the hood' guy, my only
point was that the VM or runtimes or whatever are there everywhere...just
didn't see much of a difference in it myself...implementation aside, it's
the same concept.

<<<The ".Net" ports being done are not supported by Microsoft and there is
no clear standard for implementing the libraries. WORA cannot be ensured
because of this. Only a fool would bet on .Net being supported on any platform
other than Windows. There are also patents that get in the way of a true
open source implementation. If Microsoft were to license out the technology
to other companies then I would agree with you.>>>

Agreed...I wouldn't hang my hat on anything surrounding Linux and .NET...nor
would I want to...really makes no sense...my personal opinion is that a bunch
of people just want to play around and make it work...no real benefit in
my book...again, just pointed out that it was 'in the works' and may at some
point be possible.

<<<What are the "facts" you take from the petshop example? I've seen this
used more and more lately by Microsoft enthusiasts to try and wedge their
way in to J2EE space. The argument falls apart too quickly though when one
looks into the true facts and not the "facts" being pitched by Microsoft
at their developer (marketing) events. All I need say is that their is nothing
like an Entity Bean in .Net. If their had been, the benchmark may hold some
clout.>>>

The only facts I'm referring to are the scalability and performance advantages
that were proven in that exercise...the Java implementation was a textbook
(so to speak) implementation of that application...and if that is what MOST
Java people are implementing, then the difference in how the .NET solution
was implemented was far better if you are going for performance...that was
all I'm arguing...not that Java sucks...there are clear advantages to the
architecture chosen by the Java side in that example...but, in my opinion,
those advantages do not outweigh performance...if you have a block of specs
and you adhere to them (and they are well thought out and the database modeled
w/ some fore-thought) then you should not have to mess w/ the database after
the fact...so there is no reason to abstract out the data into classes that
slow down the system...I've seen the same thing by so called 'OO' trained
people who take VB, abstract out the data into classes, then the client screams
that the system is slow...if you have a database app and there are existing
interfaces to deal with that, the performance vs flexibility should (IMO)
lean toward performance...and I think that is where the MS thought process
is today...I think it's just a different mentality...not good or bad...just
different.

Chris

[Kunle Odutola]

Kent wrote:
> Colin,
>
> Welcome to the new world. You cannot yet use .Net components from
> office.

Inaccurate: COM interop supports bi-directional interoperation between .NET
and COM.

> The story does not get any better I'm afraid, because you'll see that
> you cannot just drop in your old VB6 code and compile it under
> VB.Net. Backward compatibility is lost. This may or may not be an
> issue for you. For your own sake I hope it is not.

It depends on the code. Currently most non-trivial apps require manual
intervention after the upgrade wizard has done it's job. This has already
improved with VB.NET 2003.

> Microsoft has apparently decided that the old COM based way of doing
> things is evil and has decided to pull the rug out from under us with
> this Java like platform called .Net. It is more like Java and less
> like VB.

Inaccurate: VB has always had a VM, garbage collection and bytecode
execution. What .NET adds is a standardized "platform API" and a
language-neutral bytecode core.

> You get a Virtual Machine which is called the .Net runtime,
> which is capable of using any .Net langauge.

Inaccurate: The CLR only understands MSIL. Compilers for languages that
target the .NET platform emit MSIL.

> If you take the time to
> do some research, you will find that even though the .Net runtime
> allows you to use different languages, all of the languages are very
> similar and there is no clear advantage to using one over the other.

Inaccurate: Contrast and compare the following
F# - http://www.yale.edu/tp/framework.htm
NetCOBOL - http://www.adtools.com/
Fortran - http://www.salfordsoftware.co.uk/com...5/dotnet.shtml
MC++ - http://msdn.microsoft.com/visualc/

> They all have pretty much the same strengths and weaknesses.

Inaccurate: See above.

> Since
> the new language C# has been submitted to the ECMA as a standard and
> all of the .Net libraries are written in C#,

Inaccurate: All of the .NET libraries aren't written in C#. Search this
newsgroup archive for links.

> it seems to be the clear
> choice to use for .Net development rather than VB which has a track
> record of being broken by Microsoft.

Yet VB remained the no. 1 dev tool for years.

> One could also argue that since parts of .Net are derived from
> Microsoft's old Java (Visual J++) technology, that Java would be a
> good choice to use rather than .Net.

Why stop there, since Java itself borrowed heavily from Smalltalk and UCSD
Pascal and Secure Tcl.....

> By creating .Net Microsoft
> validated Java as a platform. .Net is however not WORA like Java is.

Java isn't fully WORA either, more like WOTA ;-)

> The entire .Net strategy is questionable in my own opinion, since it
> is restricted to the Windows OS.

You are right. Windows was equally questionable - limited as it was to the
Intel platform. Boy did MS make a goof of that!!

Kunle

[Kunle Odutola]

Kent wrote:

>> 2. all .NET languages are not (or will not) be the same...C# and
>> VB.NET might (in the final analysis) be similar and provide similar
>> results...but the other non-MS languages that are being made .NET
>> compliant are very different and while they compile to the same
>> thing (theoretically) they will offer something that Java
>> can't...and that's speed to delivery for developers
> coming
>> from other backgrounds...bottom-line will continue to be important
>> to many companies...Java doesn't deliver in that area...if a manager
>> can leverage his COBOL developers' skillset into the web/n-tier
>> arena w/o having to make them Java gurus, it offers some serious
>> money saving potential.
>
> You cannot cleanly implement a language in it's pure form on top of
> .Net.

Actually you can. Many implementations choose not to because of the wish to
interop with other .NET languages. Best of both worlds would be to allow the
feature in the .NET implementation of the language but be able to
flag/disable it for cross-language projects (just like C# supports unsigned
types and unsafe code which the CLS forbids on public interfaces).

> The platform has restrictions that are imposed which makes
> every .Net language feel the same.

Care to expand on this statement?. What "platform restrictions" are you
referring to?

> As for money saving potential, there is a learning curve required to
> learn Net no matter what language you use. There may be syntactical
> similarities in the .Net languages but that is all they are is
> similarities one cannot expect to be productive on .Net just because
> he is using Cobol that compiles on .Net.

Funny. The productivity angle (and forward code portability) is precisely
why multi-language support is important.

> The last point is maintenance, most shops will standardize on one
> language and use it exclusivley. It is Ironic that .Net makes this
> easier than ever to do because all of the languages have the same
> capabilities.

You premise - all .NET languages have the same capabilities - is wrong. So
is the conclussion you attempt to draw from it.

> Why would you use more than one when their is no
> benefit? There used to be real advantages to mixing C++ and VB.
> There is no real advantage to mixing VB and C#.

C# is NOT C++. There is real advantage to mixing C#, VB.NET and MC++. Even
J# and JScript.NET have their own unique abilities.

>> 3. There was/is a VM in VB6, the VB runtimes have always
>> existed...so the idea/concept of a virtual machine is not new to
>> .NET.
>
> There were runtimes in QuickBasic as well. The .Net runtime models
> Java more closely than it does or any previous version of Microsoft
> BASIC.

The .NET model adds a standard "platform API" and a documented and
accessible language-neutral bytecode format to VB's established
architecture.

>> 4. .NET is currently restricted to Windows, but there are a number
>> of third-party projects going on to port to Linux (the CLR). Time
>> will tell whether or not that is going to work...probably won't
>> fly...but still, it will be an option if someone is 'off' enough to
>> think it's of benefit.
>
> The ".Net" ports being done are not supported by Microsoft and there
> is no clear standard for implementing the libraries. WORA cannot be
> ensured because of this.

Microsoft itself has shared the source code to a CLR for three different
platforms.

> Only a fool would bet on .Net being
> supported on any platform other than Windows. There are also patents
> that get in the way of a true open source implementation.

Ask JBoss about Java/J2EE, WORA and "getting in the way of open source
implementations".

> All I need say is that their is nothing like an Entity Bean in .Net.

And there is a reason for that.... ;-)

Kunle

[Kent]

Chris,

In terms of .Net languages, I don't think it's good for the industry to have
Smalltalk and then a Smalltalk.Net (S# or whatever) that is familiar, yet
different. Every .Net language feels like C# once you become familiar with
it. It just seems backwards... My own opinion nothing more nothing less.

The clear advantage of J2EE is that there are many many implementations of
the technology from open source to commercial app servers. The burden of
performance lies on the vendor providing the implementation. It is the responsibility
of the architect to ensure that performance and stability requirements can
met when implementing a particualar app server.

I wouldn't go as far as to say that everyone is going about creating J2EE
applications using the Petstore as a reference. I wouldn't even go so far
as to say they are using EJBs. Petstore was intended to show how to use
Servlets/JSP and EJBs but not necessarily how to use them to create a performance
focused application.

Check out ibatis.com for a Java implementation of Petstore that is better
far closer to the .Net implementation than the Sun version.

I'm not a die hard Java advocate by any means. Being an old VB programmer,
I feel the Java camp has done a better job of maintaining compatibility of
the platform and stability of the Java language than Microsoft has done with
it's offering (dumping com and classic VB). To me this is reason alone to
select Java over .Net when making a move from VB6. Again, my own opinion
nothing more nothing less.

Kent

[Patrick Troughton]

Hi Kent,

>In terms of .Net languages, I don't think it's good for the industry to
have
>Smalltalk and then a Smalltalk.Net (S# or whatever) that is familiar, yet
>different.

A common problem with .NOTters like you is that you never clearly think through
your own opinions...On the one hand, you say that it's not good for the industry
to have variants of the same language (Smalltalk and Smalltalk.NET), yet
at the same time you praise Java, which is a variant of C++, which is a variant
of C. You also claim to be a former VB programmer which was based on QuickBasic
which was based on BasicA which was based on...you get the point. Can you
at least be consistent? If you really think Smalltalk .NET, VB.NET or C#
are bad ideas, you would never have even touched Java or VB in the first
place. It's still not too late for you, Kent. If you really want to convince
us of your opinions, prove it by renouncing Java immediately and insist on
coding only in C or the original version of BASIC. Only by doing this can
you truly prove to everyone you really mean what you say!

/Pat
--------------------------
It's the platform, stupid.
--------------------------

[Kunle Odutola]

Kent wrote:
> Chris,
>
> In terms of .Net languages, I don't think it's good for the industry
> to have Smalltalk and then a Smalltalk.Net (S# or whatever) that is
> familiar, yet different.

Have you tried using the "familiar yet different" VisualWorks, ENVY, Visual
Smalltalk, VisualAge, Squeak......
Your premise is unsound. I for one welcome J# alongside C# despite the
similarities. I just wish J# could be upped to JDK1.4 level.

> Every .Net language feels like C# once you
> become familiar with it. It just seems backwards... My own opinion
> nothing more nothing less.

Based on wrong premises (or limited exposure to .NET languages). What .NET
languages have you "become familiar" with?

> I'm not a die hard Java advocate by any means. Being an old VB
> programmer, I feel the Java camp has done a better job of maintaining
> compatibility of the platform and stability of the Java language than
> Microsoft has done with it's offering (dumping com and classic VB).

MS BASIC is over two decades old. Java is little over half a decade old. Go
figure.

> To me this is reason alone to select Java over .Net when making a
> move from VB6. Again, my own opinion nothing more nothing less.

Why select Java at all?. C and C++ have a better record at backwards
compatibility, vendor diversity, open source availability and performance -
the reasons you've mentioned in your message. And WORA as well, since Java
itself depends on C/C++ to exist at all.

The reason is that the whole package - platform and language - offers some
benefit above and beyond typical C/C++ environments. The Java platform and
language doesn't have any kind of similar advantage over the .NET platform
and any of the languages that target MSIL. Currently WORA is Java's only
advantage and Rotor, Mono and dotGNU have already proven .NET's WORA-ness.

It's just that most folks care more about WORQ than WORA.

Kunle

[james]

"Kent" <kp@kp.org> wrote in message news:3e50f11f$1@tnews.web.devx.com...
>
> Chris,
>
> In terms of .Net languages, I don't think it's good for the industry to
have
> Smalltalk and then a Smalltalk.Net (S# or whatever) that is familiar, yet
> different. Every .Net language feels like C# once you become familiar
with
> it. It just seems backwards... My own opinion nothing more nothing less.
<BIG SNIP>
> Kent

Kent, I have been following this thread and I was wondering about the
statement you made above. That , Every .NET language feels like C# once you
become familiar with it.

I have used both C# and VB.NET and personally, I find them both different.
I find that I like VB.NET much better. (might be because I have been using
VB for years)
I like the syntax and other features , again being more familiar with VB.
What is it about the other .NET languages( C++, J#, VB.NET, etc.) that feels
similar to C# ?
If your talking about using the classes in theFramework, then I would agree
, to a point.
But, to me, as a VB developer and now a VB.NET developer, I really do
appreciate the power added to VB with the use of the Framework . It just
makes doing a ton of once hard to do things, much easier. I have been
working on an Image Editing program (look out Photoshop 8-) ) in VB.NET,
and I'm able to do things that were all but impossible in VB6, without going
into the API's . I don't miss that at all.
Just, interested in your statement.
james

[Mark Jerde]

<nitpick>
> ... which is a variant of C++, which is a variant of C.

I don't think that's true any more than the Boeing 767 is a variant of "The
Spirit of St. Louis."

When I wrote in C, I could always "see" the assembler. When I write OOP C++
I don't have that feeling of being one layer up from assembly language.
</nitpick>

-- Mark

[Kent]

Hi James,

I am speaking of the basic constructs of the .Net languages. The requirements
of the CLI and CLR make the languages feel very similar.

If you create a C# application that displays a window, which contains a table
control that is populated with some data from a database and then write the
same application in VB.Net, it takes almost the same number of lines of code.
The contructs also look very similar.

I feel there is very little value in the .Net platform supporting more than
one language. That being said, it would make very little difference to me
if the supported language were VB and not C# or even some .Net language I
invent called !C.

Having a bunch of languages added to .Net that resemble classic languages
(Pascal, Fortan, etc...) but are not portable becuase of .Net extensions
also does not make sense to me.

Also, as I've said many times, it is a waste for .Net compilers to produce
MISL when the end result is a program that is restricted to the Windows OS.
Please do not go on about MONO. MONO does not make .Net cross platform.

While I see your point about VB.Net easing some of the pains of understanding
the .Net libraries, The language still "feels" like C# to me in it's support
of conditional and iterative statements, data types and other areas.

These are my own opinions, many people agree others do not.

Kent



"james" <jjames700@earthlink.net> wrote:
>
>Kent, I have been following this thread and I was wondering about the
>statement you made above. That , Every .NET language feels like C# once
you
>become familiar with it.
>
>I have used both C# and VB.NET and personally, I find them both different.
>I find that I like VB.NET much better. (might be because I have been using
>VB for years)
>I like the syntax and other features , again being more familiar with VB.
>What is it about the other .NET languages( C++, J#, VB.NET, etc.) that feels
>similar to C# ?
>If your talking about using the classes in theFramework, then I would agree
>, to a point.
>But, to me, as a VB developer and now a VB.NET developer, I really do
>appreciate the power added to VB with the use of the Framework . It just
>makes doing a ton of once hard to do things, much easier. I have been
>working on an Image Editing program (look out Photoshop 8-) ) in VB.NET,
>and I'm able to do things that were all but impossible in VB6, without going
>into the API's . I don't miss that at all.
>Just, interested in your statement.
>james
>
>
>
>
>