C# developers going back to vb.net
Kevin
I'm an ex vb6 developer, now developing in C#.
The reason why I started developing in C# is because the company that I
worked for at the time standarised on C#.
Many of my friends working in previous companies that I worked for are
starting to move back to VB.Net. When I asked them why, it seems that
the next release of VB.Net seems very promising and they kinda see
themselves in the same position I'm in. It seems that at the time when
.Net was first released many companies basically forced developers to
work in C# because as in my case the company they worked for
standarised on C#, why these companies did this is beyond me because
most of their developers were vb developers, I think it's because it
was marketed that C# was the main language to use on the .Net
Framework.
Now many companies as well as management in these companies are
starting to realise that vb.net is not that different from c# and are
starting to give their developers a choice and thus obviously the move
back to vb.
The reason why I'm posting this topic here is because I'm wondering how
many developers using c# are ex vb developers and would actually like
to develop in vb.net. I have actually convinced my superiors to use
vb.net as another language choice and they have agreed.
We have just started a new project in vb.net about 3 mths ago and I
must say that it's still a damn fun language to work in, I'm actually
enjoying my work again. Productivity couldn't be higher as other c# (ex
vb6) developers in my department have also wanted to go back.
Wondering how many of you out there would like to move back to the
lighter side of life?
Mythran
"Kevin" <ke...@inatrice.co.za> wrote in message
news:1128369969....@f14g2000cwb.googlegroups.com...
Well, I enjoy C# more than I do VB.Net. I originally started development in
QBasic then moved to C/C++ on *nix. From there I learned Visual Basic and
moved on to the .Net platform and learned VB.Net and C#. I just like C#,
the syntax is less wordy (no Then's or End If's), which means less typing...
and I really like the way it looks (looks and feels like C/C++).
Mythran
Kevin
> QBasic then moved to C/C++ on *nix. From there I learned Visual Basic and
> moved on to the .Net platform and learned VB.Net and C#. I just like C#,
> the syntax is less wordy (no Then's or End If's), which means less typing...
> and I really like the way it looks (looks and feels like C/C++).
>
> Mythran
Wow you've been back and forth, QBasic -> C/C++ -> Visual Basic -> C#.
I disagree with your 'less typing' statement in some respect as Then's,
End If's and even End Sub End Function are implemented for you as you
enter to the next line. Even Catch and Finally is automatically coded
for you as you hit enter after a Try statement.
I do agree with your statement about look and feel, this is exactly the
point I'm trying to make. I think look and feel is important as it, in
my mind, makes you a more productive developer because you feel
comfortable with the syntax.
But I can't help wondering if ex vb6 developers now working in C# would
be more productive going back to vb.net for this exact same reason. I
know I am.
Roger
> the syntax is less wordy (no Then's or End If's), which >means less
typing...
does a real good job of aligning it too.
So this is not really an issue.
> and I really like the way it looks (looks and feels like C/C++).
>
May look like C/C++, but it's really quite different.
Type safety in C#, is one very much appreciated
difference.
Roger
Kevin
Roger
> Couldn't type safety be implemented by turning Option Strict On.
>
I was comparing type safety in C/C++, to C#
Good day,
Roger
nikki
Kevin wrote:
>
> The reason why I'm posting this topic here is because I'm wondering how
> many developers using c# are ex vb developers and would actually like
> to develop in vb.net.
I've developed in VB, VB.net, C, C shell, and various other languages,
but my main base is C and C-like languages (php, perl, etc).
Learning .net, I get to play with both VB.net and C#.net, and I have to
say, I sure hope it remains a viable option, because I never much liked
VB and it hasn't changed much. LOL
IMO, people who learned VB before C prefer VB.net and people who
learned C before VB prefer C#.
I don't think it really comes down to any more than that, regardless of
what they attempt to justify it with. But feel free to correct me. :)
(whoever came up with "on error resume next" needs to die a slow and
painful death caused by ingrown toenails...)
William Stacey [MVP]
Cobol, VB6, Perl, KSH, C, C++ and C#, etc. I just prefer c# over them all,
and its not just one or two things you can point to. But that is me.
Others will find VB.Net more to their taste and that is great. Pick the one
you like and use that.
--
William Stacey [MVP]
"Kevin" <ke...@inatrice.co.za> wrote in message
news:1128369969....@f14g2000cwb.googlegroups.com...
Kevin Spencer
> Now many companies as well as management in these companies are
> starting to realise that vb.net is not that different from c# and are
> starting to give their developers a choice and thus obviously the move
> back to vb.
You put your finger on it right there - "not that different." In fact, C#
and VB.Net ARE different, in terms of what you can do with them. You can't
do unmanaged code in VB.Net, and certain types of control are difficult to
manage with VB.Net. But if you want to develop at a high level, and don't
like or need to get down to the nitty-gritty, and you don't have much
ambition, VB.Net is probably a good language for you.
There are all kinds of programmers in the world. Some of us work at a low
level, and some of us work at a high level. And everywhere in-between. At a
high level, it doesn't matter much. But my job, for example, requires some
fairly low-level stuff, and I like it that way. I'm something of a power
freak when it comes to programming. So, I would not think about going to
VB.Net. But for many people, programming is just a job. They do it for the
money. And for them, the easiest way is the best way.
There was a serious move to C# among VB.Net programmers, and it ended up
muddying the water a bit in terms of hiring. I think anyone wanting to move
back to VB.Net is probably thinking along some very helpful lines for
everyone involved.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Kevin" <ke...@inatrice.co.za> wrote in message
news:1128369969....@f14g2000cwb.googlegroups.com...
Bob Powell [MVP]
those that can. Command line copiles with notepad as the editor of choice is
surprisingly popular.
C# is a more type-efficient language.
--
Bob Powell [MVP]
Visual C#, System.Drawing
Ramuseco Limited .NET consulting
http://www.ramuseco.com
Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm
Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm
All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
"Kevin" <ke...@inatrice.co.za> wrote in message
news:1128372519.4...@g44g2000cwa.googlegroups.com...
Reginald Blue
> The reason why I'm posting this topic here is because I'm wondering
> how many developers using c# are ex vb developers and would actually
> like to develop in vb.net. I have actually convinced my superiors to
> use vb.net as another language choice and they have agreed.
I'm somewhat surprised that no one has brought this up...
In the 1.0 and 1.1 world, the differences between the 3 primary .Net
languages were slight. And this was because they (the language developers)
were all focused on making the languages work in .Net.
Now, with 2.0 coming out, the languages are starting to go the path of
specialization within .Net. Each language is intended to provide
specialized capabilities to it's niche.
If I remember correctly, they are:
VB: Rapid Application Development, with constructs like My and Edit and
Continue to allow the developer to be efficient in doing a quick job of
putting together a prototype. (This is also intended to be the easiest to
do UI work, but, I doubt you'll see a difference.)
C#: Back end business coding. Perfect for day-to-day business objects and
the like. With the addition of generics, (even though this is a general
.Net feature) the ability to generate specialized business objects from
generic patterns will be greatly enhanced.
C++ (I forget what the moniker for this is now... used to be Managed C++,
but I think it's something else now): This is supposed to be the FAST
language. Doing something that's called a million times per second and it's
core to your code? You should do it in C++. The optimizers here are
intended to be the best of breed. Additionally, with the abilities to go
from native C++ to Managed C++, you can incorporate legacy capabilities into
.Net easily.
That's as best as I can remember from some article I read ages ago.
Presumably someone will correct me where I've misremembered.
So, as for your question, if you see yourself as a RAD kind of guy, then VB
sounds like your tool.
--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]
![Jon Skeet [C# MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUcZ7cLpd5PD7juf-mIIANWDJjBlFAMnXgv2fuTUtqywc6Q3AUmOvVJgg=s40-c)
Jon Skeet [C# MVP]
> > Now many companies as well as management in these companies are
> > starting to realise that vb.net is not that different from c# and are
> > starting to give their developers a choice and thus obviously the move
> > back to vb.
>
> You put your finger on it right there - "not that different." In fact, C#
> and VB.Net ARE different, in terms of what you can do with them. You can't
> do unmanaged code in VB.Net
You can't do unmanaged code in C# either. You can write *unsafe* code,
but it's still managed.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Larry Lard
Kevin Spencer wrote:
> It's all a matter of what you want to do with your life.
>
> > Now many companies as well as management in these companies are
> > starting to realise that vb.net is not that different from c# and are
> > starting to give their developers a choice and thus obviously the move
> > back to vb.
>
> You put your finger on it right there - "not that different." In fact, C#
> and VB.Net ARE different, in terms of what you can do with them. You can't
> do unmanaged code in VB.Net, and certain types of control are difficult to
> manage with VB.Net. But if you want to develop at a high level, and don't
> like or need to get down to the nitty-gritty, and you don't have much
> ambition, VB.Net is probably a good language for you.
Nice to see the elitist attitude of some C++ developers is alive and
kicking in the .NET world. "Don't have much ambition", hoho.
>
> There are all kinds of programmers in the world. Some of us work at a low
> level, and some of us work at a high level. And everywhere in-between. At a
> high level, it doesn't matter much. But my job, for example, requires some
> fairly low-level stuff, and I like it that way. I'm something of a power
> freak when it comes to programming. So, I would not think about going to
> VB.Net. But for many people, programming is just a job. They do it for the
> money. And for them, the easiest way is the best way.
Whereas 'power freaks' like to make things hard, deliberately...
--
Larry Lard
Replies to group please
Leon Lambert
Following is a pretty good article about the differences between the VB
culture and the C# culture. I agree with most points made.
http://www.cmswire.com/cms/featured-articles/not-another-c-versus-vb-article-000591.php
Leon Lambert
Kevin Spencer
which I consider to be one of the most powerful aspects of C. Once you get
access to a pointer, you're talking about programming at light speed.
Pointers are dangerous, yes, but indispensible when used for certain types
of operations, such as working with graphics. For example, I have created
several custom filters for bitmaps, and classes which create bitmaps from
Digital Elevation Model data, for quick storage and delivery. In addition,
pointers are indispensible for working with binary file formats, both
formats that are not supported by the CLR, and formats which are supported
by the CLR, but in a limited way.
The VB capabilities for working with pointers are extremely limited. So much
so, in fact, as to be nearly useless, unless you want to grab a handle to a
window or something of that sort.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message
news:MPG.1dac31fd2...@msnews.microsoft.com...
Kevin Spencer
> kicking in the .NET world. "Don't have much ambition", hoho.
It' not "elitist" at all. VB has limitations which C# does not have. If you
are satisfied with those limitations, you are less ambitious (as a
programmer, not as a person), by definition.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Larry Lard" <larr...@hotmail.com> wrote in message
news:1128415923.4...@g43g2000cwa.googlegroups.com...
Kevin Spencer
> VB sounds like your tool.
Well, Reginald, that USED to be true. But not with C# and Visual Studio.Net.
You can drag and drop all day long, and the same classes are available to C#
as to VB.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Reginald Blue" <Regina...@hotmail.com> wrote in message
news:dhsf1t$h4t$1...@trsvr.tr.unisys.com...
Danny Tuppeny
news:ed%23xwuFy...@TK2MSFTNGP14.phx.gbl...
> >. I just like C#,
>> the syntax is less wordy (no Then's or End If's), which >means less
> typing...
> Actually, the IDE 'types' all this anyhow, and
> does a real good job of aligning it too.
> So this is not really an issue.
Yeah, but it looks like "english", so any half-wit can read and understand
the code. The harder it is to understand, the less likely you can become
unemployed ;)
Kevin Spencer
distinction between "unmanaged" and "unsafe" is unimportant. Terms mean
things, and I will take your correction to heart. However, the distinction
between C# and VB.net is not insignificant either, in terms of what you can
do with either language, at least for someone in my position. That was the
point I was making.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message
news:MPG.1dac31fd2...@msnews.microsoft.com...
Mythran
>> the syntax is less wordy (no Then's or End If's), which >means less
> typing...
> Actually, the IDE 'types' all this anyhow, and
> does a real good job of aligning it too.
> So this is not really an issue.
>
Hrm, not in my IDE :) I use the VS.Net IDE and turned off all
autocompletion...for one reason, in VB.Net, I do not use the keyword "Then".
So my if's are like the following:
If True
DoSomething()
End If
Why the extra typing? Why the extra "Then"? Don't need it...compiler
doesn't need it...why have it automatically insert it for ya when it's just
"extra" wording?
Aligning? I like things aligned to my specifications, not .Net's. So I
turned that off too. My tabbing is 4 spaces (not tabs) and even my region
blocks are spaced differently. In .Net 1.0 and 1.1 (framework versions), I
couldn't really change things to how I wanted them and keep auto-completion
and auto-formatting on. But now in the 2.0 world, it looks much better. I
can specify a LOOOOOT more options...and this makes both languages even
better to work with (using the .Net IDE).
>> and I really like the way it looks (looks and feels like C/C++).
>>
> May look like C/C++, but it's really quite different.
> Type safety in C#, is one very much appreciated
> difference.
>
Type safety ... hmmm...
:)
Mythran
Mythran
>> Well, I enjoy C# more than I do VB.Net. I originally started development
>> in
>> QBasic then moved to C/C++ on *nix. From there I learned Visual Basic
>> and
>> moved on to the .Net platform and learned VB.Net and C#. I just like C#,
>> the syntax is less wordy (no Then's or End If's), which means less
>> typing...
>> and I really like the way it looks (looks and feels like C/C++).
>>
>> Mythran
>
>
> Wow you've been back and forth, QBasic -> C/C++ -> Visual Basic -> C#.
>
lol the real, almost-full as much as I can recall, list is:
* QuickBasic (first language, loved it...until I learned it wasn't the only
programming language)...
* Baby C (what I call baby C is GNU C/C++ we used during the BBS age to
create doors, such as MUD's :p, miss those)...
* Perl (Another language I used for non-BBS MUDS for external management
utilities such as converting the player files to online-web files)
* Java ("" "" "" "")
* JavaScript (who doesn't know this one?)
* VBScript (who uses this nowadays? The newsgroups are not quite, but
seemingly dead)...
* Small (Smaller version of the C/C++ engine, more like javascript is to
java, Small is to C/C++..used as a gaming component [Half-Life 2])
* VB/VC++ (yeah, we've all been there)
* VB.Net/C# (yay, getting there)
and now, the most current language with all the greatest coding elements and
"oohs" and "ahhs".....
COBOL :)
Heh, yeah, backtracked on that last one. I'm just recently learned COBOL
for my current job (been trying to learn it for 4 years now, just now they
put me on projects that have me converting programs away from COBOL to
ASP.Net using VB.Net backend....why not Cobol.Net? It does exist...)
> I disagree with your 'less typing' statement in some respect as Then's,
> End If's and even End Sub End Function are implemented for you as you
> enter to the next line. Even Catch and Finally is automatically coded
> for you as you hit enter after a Try statement.
>
Only if you 1.) don't use notepad/generic text-editor or 2.) don't turn the
option off.
> I do agree with your statement about look and feel, this is exactly the
> point I'm trying to make. I think look and feel is important as it, in
> my mind, makes you a more productive developer because you feel
> comfortable with the syntax.
>
Yup :)
Mythran
Kevin
question is asked it turns into a language comparison.
It has been proven that every great man in history has stood up in the
middle of the crowd so to speak and has gone against the grain and has
followed his heart.
The question was basically 'Have you followed like sheep' or 'Have done
what you want to do'
How many of you out there are man enough to stand up and forget about
the money, forget about the 'I work in C# because I'm regarded as a
real developer' or 'I work in C# because I'm embarrased to say I work
in vb' and work in the language that you love to work in.
Mythran, Roger, Nikki, William have posted good comments, something
along the line as 'I work in C# because I like the C style syntax
because I worked in C/C++ before'.
Kevin - You like to do the comparison thing, and this is good, but lets
forget about the comparison for a moment, why do you really work in C#,
is it the money or the syntax or were you forced to work in it.
Reginald - If you want to be a more rad type of guy then work in vb.
Are you indicating that c# isn't a rad tool. I think c# is just as rad
as vb.net.
Leon - Hit the nail on the head. It's very much a culture thing. Why is
it then that ex vb developers work in C#.
For myself I've worked in C# for 4 years now. I'm an ex vb developer.
Since I've started this project on VB.Net I actually wake up earlier in
the morning to get to work earlier as to write the next piece of code.
I started developing not because of the money nor the fact that I
thought I would become the best developer in the world but because I
liked software development and the language I wrote it in. I love to
change peoples lives.
I'm afraid to say that most ex vb developers use C# because they are
C++ wannabies not because they can change the world.
And what about the crap statement about vb.net developers not being
ambitious.
We all know that the languages are different and you can do this in one
and that in the other. If I'm missing something I need in vb I'll pop
over to c# and write it, or visa versa.
How many men are out there. (Includes the girls as well, just a figure
of speech)????
How many of you will go against the grain, because of what you love not
because of what you were told to love???
I for one will not be dicatated to any longer by someone who has no
idea about software development or why we started coding in the first
place.
Mythran
> idea about software development or why we started coding in the first
> place.
>
Hmm...I wish I could say the same. On my off-time, I develop in the
languages I choose to, and learn those I don't know. At work, I am forced
to develop in only the languages they dictate. It is a secure job, and pays
well with great benefits, and so I do the work, regardless of how happy I
am. But, unlike most "developers", when I am at home...I get on my
computers and laptop and hack away some more but in C# and now (learning
PascalScript more and Pascal), Pascal.
I have read 2 articles today, one from
http://www.cmswire.com/cms/featured-articles/not-another-c-versus-vb-article-000591.php
and another from JDJ magazine. One says VB.Net is better, the other is more
clear on why one is better than the other depending on the developer,
application, and situation.
Anywho, have fun :)
Mythran
Cor Ligthert [MVP]
>.why not Cobol.Net? It does exist...)
Two reasons (there are more)
Cobol is based on non human interaction with the system (it is still done
however not in the majority of the programs).
Cobol is created with memory saving in mind (not really needed now anymore)
However it is still the best structured self documenting program language
that I ever saw
The last is my personal idea.
Cor
Kevin Spencer
> forget about the comparison for a moment, why do you really work in C#,
> is it the money or the syntax or were you forced to work in it.
I thought I pretty well explained why I work in C#. It does what I need it
to do. VB does not. I sometimes need pointers, and unsafe code in the apps I
work on. There are other reasons as well. It is concise. It looks more like
what is actually going on in the computer (math). And I love programming
power. I love to know what's going on deep in the bowels of my app, and I
love to make it more efficient, fast, and well-architected. I will program
until the day I die. I don't do it for a living. I do it for the love of
programming. I happen to make a very good living out of it, but when I no
longer need the money, I will continue to do it. I often program just for
"fun." I love to learn. So, I want the biggest programming "bang" for my
buck, the language which gives me the most options, the greatest programming
power. With C#, you can go about as low as you need or want to. With VB you
cannot. Note that I am not saying this is what everyone "should" do, nor do
I claim that it is somehow a "better" language; it is merely what I prefer
because I am what I am. Different strokes for different folks. Again, I
thought I made that clear. But people hear what they want to hear, and that
is their choice. As for me, I want to hear what is true, and not try to fill
in the blanks with my own skewed perspective of things. And that is one of
the things I love about computers. They are incapable of interpreting, and
therefore incapable of misinterpreting. They are, therefore, reliable, and
"brutally" honest.
> And what about the crap statement about vb.net developers not being
> ambitious.
Again, I thought I made that point clear. There are different kinds of
ambitions. Some of us aspire to be rich. Some aspire to be loved. Some
aspire to be feared. I simply aspire to be the best programmer I can be, and
that is my ambition. In the context of programming, settling for less than
the most possible capabilities in a programming language is not ambitious,
any more than in the context of wanting to be loved, one can be said to be
ambitious if one settles for merely being well-liked. I tried to put the
statement into context. Perhaps I was ambiguous. I hope I have sufficiently
clarified my remark.
> Leon - Hit the nail on the head. It's very much a culture thing. Why is
> it then that ex vb developers work in C#.
Culture is important to some. But I seem to recall you saying the following:
> The question was basically 'Have you followed like sheep' or 'Have done
> what you want to do'
Personally, I hope I have made it clear that I feel the way I do, not
because of any cultural or peer pressure, but simply because I am what I am,
and C# is the logical choice for someone like myself. My Uncle Chutney has a
saying: "Neither a follower nor a lender be." I have aspired to live up to
that concept. You, on the other hand, it seems, came here asking for the
opinions of others. Doesn't that indicate a certain interest in those
opinions? And why would one be interested in the opinions of others if one
cared not what others thought?
> How many of you will go against the grain, because of what you love not
> because of what you were told to love???
>
> I for one will not be dicatated to any longer by someone who has no
> idea about software development or why we started coding in the first
> place.
Good for you. Perhaps a good start would be to stop caring about and
soliciting the opinions of others in the culture you seem to want to defy.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Kevin" <ke...@inatrice.co.za> wrote in message
news:1128446159.5...@g14g2000cwa.googlegroups.com...
Cor Ligthert [MVP]
Some people say that the president of the US is the best and others say it
is the one from France and probably even more people have a very other
opinion about that.
(Which proofs by the way nothing about which one is the best)
:-)
Cor
"Kevin Spencer" <ke...@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:On3WKUSy...@TK2MSFTNGP10.phx.gbl...
William Stacey [MVP]
> along the line as 'I work in C# because I like the C style syntax
> because I worked in C/C++ before'.
I worked in non "{}" too (VB, ksh, cobol, etc). I like c# better - simple.
You like VB better. Great - use it.
This is about the same as asking if people like apples or oranges. Then
after they say apples, you don't believe them.
If you like oranges, eat em. Time to move on.
--
William Stacey [MVP]
Chuck Wagner
> The reason why I'm posting this topic here is because I'm wondering how
> many developers using c# are ex vb developers and would actually like
> to develop in vb.net.
Interestingly enough, I have to develop simultaneously in both c# and
vb.net, and I'd like to eliminate the vb.net stuff. I don't find that
there's anything significant that vb.net has that c# lacks in terms of
usability - it's mostly just syntax.
But vb.net has lots of extra words - which I just find distracting - not
helpful.
Kevin
Someone has finally stood up.
I can see you really look for real programming power.
You have obviously looked at C++\CLI by now, my guess is
you would probably be moving over to that very soon.
Congrats.
Cor Ligthert [MVP]
>nd I'd like to eliminate the vb.net stuff.
Are you serious, you have cut off the boxer his arms and legs to make him
equal to the cripple and now you found that the boxer is not a better
fighter than the cripple.
(Not telling with this, that C# is a cripple)
Really strange how some people react on these C# / VBNet questions in this
newsgroup, it is for me in a way if they are not sure and want to proof
themselves that there choose was right.
Cor
Kevin Spencer
about either language.
The fact that anyone PERCEIVED a qualitative statement says more about them
than it does about me.
John is 5 foot 9 inches tall.
Sally is 6 foot 1 inch tall.
I am 5 foot 10 inches tall.
I prefer to hang out with John. I don't feel comfortable around women who
are taller than I am.
Which one did I say was "best?"
We are all supposed to be programmers here. That means that we make our
living by logic. When we employ logic badly, we write bad code. The above is
a simple allegory for the statements I made. A logical analysis of those
statements leads to no conclusion regarding the quality of John, or the
quality of Sally. My qualitative impression of the 2 people was not
discussed. Only a single property of both people, which both people have, in
different amounts, was discussed. Their height was discussed because it is
based on their height, and my personal preferences, that I prefer to hang
out with John. In other words, if asked who I would rather hang out with, I
would say "John," and if asked to explain why, I would say "because I don't
feel comfortable around women who are taller than I am."
Now, someone with a particular axe to grind, could (illogically) come to the
conclusion that I am a sexist, or that I prefer the company of men, or that
I have a phobia of women who are larger than I am, or that I am a
homosexual. Would any of these assertions be true? Logically, it is
impossible to say, based on a logical analysis of the statements made.
Therefore, those assertions would be unreliable, and if held by someone who
makes their living by logic, would indicate a certain weakness in their
skill set. It would imply a greater probability that the person making the
assertion was likely to write bad code. In other words, it would provide
more information about the person who made the assertion; it would provide
no information about me.
Or, as my Uncle Chutney sez, "Ambiguity has a certain quality to it."
--
;-),
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Cor Ligthert [MVP]" <notmyfi...@planet.nl> wrote in message
news:ugpexkSy...@TK2MSFTNGP14.phx.gbl...
Cor Ligthert [MVP]
Most is agreed by me, however you wrote this.
> That means that we make our living by logic.
Logic can be subjective (as you showed), in the way we are handling it here
it has to be in my opinion objective.
Which means that when a choose is because of subject reasons, those reasons
have to be added and be in relation to the object.
(When you are in Holland you will probably be comfortable with woman as
Sally, a lot of nice looking woman here are that tall and you will not
recognize it, so even that subjective part can be important)
:-)
Just my opinion.
Cor
Kevin Spencer
Actually, I prefer C# over C++. I find the syntax more elegant. It enhances
my productivity. And if I need any unsafe code, I can easily switch to C,
which was my first language, long ago.
C++ is an older implementation/derivation of C. It was designed for very
low-level access, BIOS/processor-level access, in fact. It was developed
prior to the advent of multi-tasking networked operating systems, and before
it was possible to get yourself into too much trouble with
BIOS/processor-level access. And, as computers advanced in capability and
complexity, as multi-tasking operating systems became standard, and the
Internet made almost everything require some sort of TCP network component,
OS's and programs became even more complex, and problems began to emerge.
Among these were memory leaks, due to allocated memory being overlooked and
never de-allocated, and problems with using memory that the operating system
didn't want to be used. And others as well, including file system conflicts,
etc. In other words, another level, or platform, above the operating system,
was a good idea. Whereas BIOS-level programming was fine when operating
systems did little but manage files, OS-level programming makes sense today.
The .Net platform is the best OS-level programming platform to be created to
date. Period. It is natively multi-threaded, and fully object-oriented, all
the way down to primitive data types, via boxing and unboxing. It uses
Garbage Collection to prevent memory leaks, and tends to discourage access
below the OS level. And the C# language was created along the same lines,
with the same syntax principles employed in the development of the C
language, and the C++ language after it. In other words, it is designed for,
and best-suited for the .Net platform, an environment which uses pointers
(under the hood) for everything, and direct member access is largely a thing
of the past.
Therefore, IMHO, the C# language is the best implementation/derivation of C
to come along. It is current, whereas C++ is not. C++ was designed for a
certain programming environment which simply doesn't exist in the .Net
platform, an environment which will eventually be for the most part
forgotten, just as punch cards are only occasionally and wistfully
remembered over a glass of beer these days.
The .Net implementation of C++ is NOT the original C++, although it
certainly looks a lot like it. I believe it was created to accomodate
programmers who have gotten used to the C++ syntax over many years, just as
VB.Net was created to accomodate programmers who have gotten used to VB over
many years. But C# was created as a new implementation of C, and designed
specifically with the .Net platform in mind, and according to the same
syntactical logic that was used to create C and C++. In other words, I feel
that C# is the "native" .Net language.
So, that's my story and I'm stickin' to it!
--
;-),
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Kevin" <ke...@inatrice.co.za> wrote in message
news:1128496959.2...@g47g2000cwa.googlegroups.com...
Cor Ligthert [MVP]
>In other words, I feel that C# is the "native" .Net language.
About religions you can not discuss, you believe or you don't.
:-)
Cor
Larry Lard
Kevin Spencer wrote:
[snip]
> C++ is an older implementation/derivation of C. It was designed for very
> low-level access, BIOS/processor-level access, in fact. It was developed
> prior to the advent of multi-tasking networked operating systems, and before
> it was possible to get yourself into too much trouble with
> BIOS/processor-level access.
Thanks for reassuring me that I don't have to set too much store by
things you say.
Chuck Wagner
> Are you serious, you have cut off the boxer his arms and legs to make him
> equal to the cripple and now you found that the boxer is not a better
> fighter than the cripple.
>
> (Not telling with this, that C# is a cripple)
>
> Really strange how some people react on these C# / VBNet questions in this
> newsgroup, it is for me in a way if they are not sure and want to proof
> themselves that there choose was right.
I'm not sure what you mean by the boxer & cripple analogy. I don't find that
vb.net is a cripple compared to vb6 if that's what you're suggesting. Having
full featured object orientation in vb.net seems to me that it's a huge
improvement.
The feature that I find makes VB.net development a better experience than C#
is the background compilation and detection of errors while coding. But
that's an artifact of the IDE, not the language, and I think that many people
inappropriately argue over this issue as a language issue.
I've developed VB apps since version 3. During that time I also mastered
C++ with MFC and hated it compared to the simplicity of VB. But now that I
have two languages that're identical in features, for me the decision is
entirely based on the elegance and conciseness of the language. And C# wins
at being more concise.
Cor Ligthert [MVP]
> I'm not sure what you mean by the boxer & cripple analogy. I don't find
> that
> vb.net is a cripple compared to vb6 if that's what you're suggesting.
This is from your message, I quoted it only partially.
> Interestingly enough, I have to develop simultaneously in both c# and
> vb.net, and I'd like to eliminate the vb.net stuff.
I understood from that, that you use in VBNet only parts that are as well in
C#, because the second sentence was direct behind "vb.net".
(Not using the microsoft.visualbasic namespace by instance).
Don't think that I have anything against C# by the way. I don't like not
honest comparing.
Cor
Kevin
One more question, have you ever worked in Visual Basic?
I realised by your reply that you are a very 'c' orientated developer,
you must have been very excited when c# hit the market, this is why I
asked the question whether or not you will be using C++\CLI in the
future. This will give you even more power like deterministic
finalization for instance.
Kevin
if people like apples why do they pretend to like oranges because the
majority like oranges and actually they are dying for a nice juicy
apple.
I was actually complimenting you on your response because you were one
of the people who said I like c# because of this and that, not because
it has better features than another language. Also it's difficult to
believe people sometimes because it's in our nature to follow the
majority. I find the psycology behind it very interesting, this is why
I posted this question in the first place. You can see immediately that
some people jumped on the I like c# because it's better than vb
bandwagon, when there are many languages that are just as feature rich
on the .Net framework.
Chuck Wagner
> I understood from that, that you use in VBNet only parts that are as well in
> C#, because the second sentence was direct behind "vb.net".
>
> (Not using the microsoft.visualbasic namespace by instance).
>
> Don't think that I have anything against C# by the way. I don't like not
> honest comparing.
I happen to believe that my comparisons are quite honest - and there's
virtually nothing in the visualbasic namespace that isn't elsewhere in the
framework. So I really don't think of that namespace making vb.net into a
boxer. Yes, there are a few features that are very handy when the need
arises, but those situations are rare, and often I could implement a bit of
code to do it myself just as easily. Even so, when comparing what vb.net has
vs C# when considering the whole framework, they're 99.95% equivalent.
For example, vb.net has the With keyword, which is a handy shorthand when
setting multiple properties on an object. C# has the Using statement which
automatically calls dispose on an object for you. I find that C#'s using
saves me a lot more typing and code than With, but your mileage may vary.
I'm curious about what you think it is that makes vb.net a boxer?
Kevin Spencer
I'm not sure what you're referring to, but you should bone up on your
history. Some of us lived through it.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Larry Lard" <larr...@hotmail.com> wrote in message
news:1128520902.9...@g44g2000cwa.googlegroups.com...
Kevin Spencer
VBScript and VB. I had my own consulting business, and the web database
market was just emerging. In fact, prior to working with ASP, I spent a year
or so working with IDC.
I got very familiar with VBScript and VB, and had no problems with it. I
actually got very comfortable with it, and of course, it was the only RAD
language around. That was its greatest strength. But the advent of the .Net
platform opened up a world of greater possibilities, and I embraced it with
great enthusiasm. In the beginning I worked mainly with VB.Net, as I was in
a primarily ASP/VB shop. But that was about 3 years ago, and I eventually
(after changing jobs) was able to get to the point where I use C# almost
exclusively now. About 99% of the time, that is, except when I have to tweak
some legacy app that is still around here.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Kevin" <ke...@inatrice.co.za> wrote in message
news:1128527085....@o13g2000cwo.googlegroups.com...
Kevin Spencer
I have no problems with women of any kind. However, I am married now, so
it's really very moot!
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Cor Ligthert [MVP]" <notmyfi...@planet.nl> wrote in message
news:eZAg2fZy...@tk2msftngp13.phx.gbl...
William Stacey [MVP]
> if people like apples why do they pretend to like oranges because the
> majority like oranges and actually they are dying for a nice juicy
> apple.
If in fact that was the case. But I see no evidence that people who use c#
are actually dying to use VB instead, nor the reverse. I am sure one can
quote someone here or there on both sides. But my quess would be that most
people are using the language they prefer. That said, if I owned a big
project I would pick one and stick with one. Yes you can use both and let
people choose which one they like, but now you have two different languages
to deal with and people always have to juggle mental conversion even if they
know both. Imagine doing code reviews with two or three different languages
on the table. Have two or more sets of standards, etc, etc. So overall
productivity would suffer I would think. So fact is, some companies need to
make a choice and stick with it.
--
William Stacey [MVP]
kwkahler
quite often. Originally coming from Turbo Pascal I never really found a "true
love" since the DOS days. My opinion is that C# is a cleaner more typesafe
language that in almost all of my projects beats VB.NET in shorter
development cycles and far less bugs. In my opinion C# will be THE language
in the future.
--
William Kahler
.NET Developer, MCSD
"Kevin" wrote:
> I don't know if I should even start this topic but here goes.
> I'm an ex vb6 developer, now developing in C#.
> The reason why I started developing in C# is because the company that I
> worked for at the time standarised on C#.
>
> Many of my friends working in previous companies that I worked for are
> starting to move back to VB.Net. When I asked them why, it seems that
> the next release of VB.Net seems very promising and they kinda see
> themselves in the same position I'm in. It seems that at the time when
> ..Net was first released many companies basically forced developers to
> work in C# because as in my case the company they worked for
> standarised on C#, why these companies did this is beyond me because
> most of their developers were vb developers, I think it's because it
> was marketed that C# was the main language to use on the .Net
> Framework.
>
> Now many companies as well as management in these companies are
> starting to realise that vb.net is not that different from c# and are
> starting to give their developers a choice and thus obviously the move
> back to vb.
>
> The reason why I'm posting this topic here is because I'm wondering how
> many developers using c# are ex vb developers and would actually like
> to develop in vb.net. I have actually convinced my superiors to use
> vb.net as another language choice and they have agreed.
>
> We have just started a new project in vb.net about 3 mths ago and I
> must say that it's still a damn fun language to work in, I'm actually
> enjoying my work again. Productivity couldn't be higher as other c# (ex
> vb6) developers in my department have also wanted to go back.
>
> Wondering how many of you out there would like to move back to the
> lighter side of life?
>
>
Paul
dude.
Tibi@discussions.microsoft.com Adam Tibi
switch to C#, I was waiting the chance!!!
* C# syntex is derived from the mother of all languages C++ and that makes
it universal and not a language that only Microsoft developers know! If you
are an ASP.NET developer then you can write JavaScript in a similar way
without adding a "Then" to the "if" (not to mention PHP).
* if you are a common Java and .NET developer, maybe working on both
languages in the same time or migrating from a language to another, you woukd
enjoy C# versus VB.NET.
* C# is "Option Stric On" by default and there is no way to set it off (I'm
addressing lazy developers)
* You type less with C#!
* It is case-sensitive and senior developers might like to have same names
with different case!
* VB.NET bears some bad practices from VB6 like a string variable is empty
string by default, when creating an array you specify the top index versus
the count, etc...
* VB.NET developers that are from VB6 background tends to write code in the
same way they did with VB6 knowing that VB6 is OO based and VB.NET is OOP
language, so they give BAD reputation for the other non-OOB developers!!!
And the list goes on, do I need to say more? I hope I won't be forced to go
back to VB.NET, it sucks!!!
Cor Ligthert [MVP]
C is almost equal to Unix an OS made especially to let a lot of students use
one computer (multi tasking) at the same time whithout having the change
that happens what students in that situation like to do the most.
http://en.wikipedia.org/wiki/C_%28programming_language%29
:-)
Cor
Cor Ligthert [MVP]
Do you know Wikipedia, there is a lot stated wrong in your message
http://en.wikipedia.org/wiki/Main_Page
Cor
"Adam Tibi" <Adam Ti...@discussions.microsoft.com> schreef in bericht
news:872E7D68-A914-4DC7...@microsoft.com...
Kevin Spencer
"multi-tasking" in a technical sense, and this amounts to nit-picking, which
may make one subjectively feel superior, but contributes nothing to the
topic.
The point I was making was that C++ was developed at a time when low-level
programming was much safer, and programming in general was much simpler. I
wrote programs in C for DOS that performed interrupt calls back in the day,
did direct disk writes, etc. This would be catastrophic today, for the vast
majority of programming tasks. That is inarguable, and topical.
Forgive me, but I am much too old for geek swagger. At this point in my
life, I prefer to be creating powerful software, rather than comparing the
length of my "hardware."
--
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Cor Ligthert [MVP]" <notmyfi...@planet.nl> wrote in message
news:Or7sbily...@TK2MSFTNGP10.phx.gbl...
Kevin Spencer
Well, Cor, by your own nit-picking standards, your English *sucks*.
http://www.ucl.ac.uk/internet-grammar/home.htm
Get over it, dude. There are more important (and helpful) things to do in
life than nit-pick. If you have a self-image problem, don't compensate. You
will only end up hating yourself even more. If you want to feel good about
yourself, try to make others feel good about themselves. What goes around
comes around.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Big things are made up of
lots of little things.
"Cor Ligthert [MVP]" <notmyfi...@planet.nl> wrote in message
news:uYvPfkly...@TK2MSFTNGP10.phx.gbl...
Cor Ligthert [MVP]
May I ask you if you did understand the message from Adam and did you think
he was right in that.
I did not want to pick on every row as you forever do.
I showed him a place to investigate what he wrote in advance, something that
your message as shown in this thread lack as well very often.
Cor
Larry Lard
Kevin Spencer wrote:
> > Do you know Wikipedia, there is a lot stated wrong in your message
>
> Well, Cor, by your own nit-picking standards, your English *sucks*.
I rather think Cor was referring to content rather than form. And I
daresay his English is better than your whatever-his-native-tongue is.
>
> http://www.ucl.ac.uk/internet-grammar/home.htm
>
> Get over it, dude. There are more important (and helpful) things to do in
> life than nit-pick. If you have a self-image problem, don't compensate. You
> will only end up hating yourself even more. If you want to feel good about
> yourself, try to make others feel good about themselves. What goes around
> comes around.
Physician heal thyself!
Kevin Spencer
Afraid not sense make of you what I know. Headache is shown, dizzy forever
make me.
--
Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.
"Cor Ligthert [MVP]" <notmyfi...@planet.nl> wrote in message
news:uLDCr9my...@TK2MSFTNGP12.phx.gbl...
Kevin Spencer
--
Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.
"Larry Lard" <larr...@hotmail.com> wrote in message
news:1128601796.8...@o13g2000cwo.googlegroups.com...
Boyer@discussions.microsoft.com Roger Boyer
As a conciencious manager getting ready to embark on a GUI development
project I would like to launch my developers on the best path and platform.
This is "blank sheet of paper" development and primarily new grads. They
will accept whatever language I place in front of them, and, unfortunately, I
haven't been able to gleen much from this conversation on which of the two
would be best. (I won't go too deaply into my programming background other
than to say that I still prefer assembly language - protected, unprotected,
object oriented, ... it's all op-codes).
Anyway, I want to get my newbies started on the right path. Is there REALLY
a difference between the two? Will I hit a dead end with one or the other?
When I read the code snippets, they look *structurally* identical - is this
not the case? Is VB.NET more like C# than it is like VB6?
Help me do right by me coders!
Cor Ligthert [MVP]
I have seen in the newsgroup dotNet.General the in my opinon best answer on
this over and over again asked question.
http://groups.google.com/group/microsoft.public.dotnet.general/msg/804482b9cce63bb7?hl=en
I hope this gives an idea
Cor
Jon Skeet [C# MVP]
> Well, a lively discussion, that's for sure.
>
> As a conciencious manager getting ready to embark on a GUI development
> project I would like to launch my developers on the best path and platform.
> This is "blank sheet of paper" development and primarily new grads. They
> will accept whatever language I place in front of them, and, unfortunately, I
> haven't been able to gleen much from this conversation on which of the two
> would be best. (I won't go too deaply into my programming background other
> than to say that I still prefer assembly language - protected, unprotected,
> object oriented, ... it's all op-codes).
>
> Anyway, I want to get my newbies started on the right path. Is there REALLY
> a difference between the two? Will I hit a dead end with one or the other?
> When I read the code snippets, they look *structurally* identical - is this
> not the case? Is VB.NET more like C# than it is like VB6?
>
> Help me do right by me coders!
There are a few reasons why it's worth using VB.NET in some situations:
1) If your coders really prefer VB syntax (eg if they've been using VB
for years, don't like C#'s "symbol" approach, and are happy to learn
the differences between VB6 and VB.NET)
2) If you need to use a lot of late binding - it's a pain to do it from
C#, but with VB.NET you can just turn option strict off, and so long as
you get everything right, you'll be fine. Just don't complain when it
doesn't give compile-time errors :)
3) If you're doing the kind of COM interop where optional parameters
would be useful
Aside from those, I would suggest using C#, for the following reasons:
1) As it was designed specifically for the .NET framework, it's more
closely aligned to it. It doesn't have a load of legacy quirks - about
the quirkiest it gets is in the switch statement. Compare this with the
various oddities of VB.NET which are basically there for backwards
compatibility, for instance the String "Nothing" handling.
2) It encourages you to do the right thing, by and large. None of this
"Option Strict Off" stuff (by default, no less!). No passing properties
by reference. More explicit event handling which makes it crystal clear
when you're subscribing to an event and when you're unsubscribing. The
"using" statement (coming to VB.NET in VS 2005, I believe).
3) It uses more standard terminology than VB.NET - null, internal etc.
4) XML doc comments (coming to VB.NET in VS 2005).
5) The language is smaller, and thus easier to learn. You need to learn
the .NET framework, of course, just as you do in VB.NET - but without
all the extras which are basically there for backwards compatibility.
There are specific things you can do in C# that you can't do in VB.NET
(just as there are some the other way round, as shown above) but these
aren't generally very important - unsafe code is very rarely useful to
most people. Operator overloading can occasionally be nice, but it's
more that it's great on some of the system types (TimeSpan, DateTime)
than that it's important to be able to overload yourself.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Steve Walker
<?@pobox.com.invalid> writes
>Aside from those, I would suggest using C#, for the following reasons:
<-- Snip -->
Another consideration; my former employer migrated from VB6 to C#. I was
involved in the process of reviewing CVs and interviewing candidates for
developer positions, both before and after the migration. We had great
difficulty finding VB6 developers of the calibre we wanted. Lots of
applicants, very, very few of them any good. Conversely, when we
advertised C# jobs we had fewer applicants but ended up choosing between
a number of superb candidates. We weren't offering any more money for
the C# guys.
Now, I realise that at the time C# was very new and that the people who
had acquired those skills were a self-selecting group. They were mostly
ex-C++ people or else people who were sick of banging their heads on
VB6's limitations and wanted a change. Things may have changed since
then, but I suspect that a lot of the people we rejected for those VB6
jobs now have VB.NET on their CV, and not C#.
So, not a comment on the relative merits of the languages, but a comment
on the ease of finding good developers amongst the two camps. I'm not
saying that there aren't good VB.NET developers, far from it, rather
that they may be harder to find.
--
Steve Walker
Roger Boyer
#2 wins the day!!! New engineers need external discipline until they are
experienced enough to know when they can bend the rules. Syntax, RAD, and
features aside, I'm investing in the new folks and want them to develop good
habits.
Many thanks,
Roger
"Jon Skeet [C# MVP]" wrote:
<snip>
Cor Ligthert [MVP]
>
> 5) The language is smaller, and thus easier to learn. You need to learn
> the .NET framework, of course, just as you do in VB.NET - but without
> all the extras which are basically there for backwards compatibility.
>
The first part of this sentence is something I don't dare to write because
of the reactions that will be, when I write it. (I had written it in a
message and than decided to take the message from Tom Dacon to overcome
needles discussions)
Except that the extra's are not only for compatibility. However, the impact
of those extra's are almost the same as you write about the extra's from C#.
:-)
Cor
Jon Skeet [C# MVP]
If the extras aren't just there for compatibility, could you explain
why they *are* there? There are plenty of VB.NET functions which have
identical functionality to "normal" .NET framework methods. Why have
redundant functions other than for the sake of compatibility?
C# has a very *few* "extras" which are syntactic sugar (lock and using
are the primary ones which come to mind). It has a couple of operators
such as typeof(...) which give compile time safety and efficiency. It
*doesn't* have reams of functions built into the language like VB.NET
does.
Cor Ligthert [MVP]
>
> If the extras aren't just there for compatibility, could you explain
> why they *are* there? There are plenty of VB.NET functions which have
> identical functionality to "normal" .NET framework methods. Why have
> redundant functions other than for the sake of compatibility?
>
Exactly as you wrote, "plenty of" not all and it is even a minority,
however I don't think that this C# newsgroup is the right place for that,
maybe we can discuss this sometime when this question comes up again in the
"General" newsgroup.
(I try to use consequent 'methods' by the way, using 'functions' is for me a
kind of backward compatibility with Excel.)
Cor
Frans Bouma [C# MVP]
> Well, a lively discussion, that's for sure.
>
> As a conciencious manager getting ready to embark on a GUI
> development project I would like to launch my developers on the best
> path and platform. This is "blank sheet of paper" development and
> primarily new grads. They will accept whatever language I place in
> front of them, and, unfortunately, I haven't been able to gleen much
> from this conversation on which of the two would be best. (I won't
> go too deaply into my programming background other than to say that I
> still prefer assembly language - protected, unprotected, object
> oriented, ... it's all op-codes).
>
> Anyway, I want to get my newbies started on the right path. Is there
> REALLY a difference between the two? Will I hit a dead end with one
> or the other? When I read the code snippets, they look structurally
> identical - is this not the case? Is VB.NET more like C# than it is
> like VB6?
You're in the C# newsgroup, so I wouldn't expect an answer like "Use
VB.NET!" ;).
VB.NET 1.x (on .NET 1.x) has some shortcomings compared to C#, they
corrected that in the upcoming .NET 2.0 / VB.NET 2005. You don't always
run into these either, but they're there (no operator overloading, no
ability to use implicit conversion methods etc.).
That said, for the productivity of the team, I'd use the language
which appeals the most to the majority of the developers. Even if they
never used VB.NET nor C#, it still can be important, because it might
be they think in the mindset of a C# programmer or a VB.NET programmer.
FB
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Frans Bouma [C# MVP]
VB, but here it goes ;) ->
Jon Skeet [C# MVP] wrote:
> Aside from those, I would suggest using C#, for the following reasons:
>
> 1) As it was designed specifically for the .NET framework, it's more
> closely aligned to it. It doesn't have a load of legacy quirks -
> about the quirkiest it gets is in the switch statement. Compare this
> with the various oddities of VB.NET which are basically there for
> backwards compatibility, for instance the String "Nothing" handling.
still, the VB.NET select case statement is IMHO more powerful. I find
the C# switch statement the most lamest version of a switch statement
you could possibly design, for the sole reason that it has:
- lame 'break' statement which is completely redundant (no fall through
supported)
- because of no fall through, you have to use 'goto'. So, using
spagetti with goto is preferred over having fallthrough.. I don't get
it.
- VB.NET's select case has range filters for the case clauses, which
are very powerful.
> 3) It uses more standard terminology than VB.NET - null, internal etc.
Isn't this subjective?
> There are specific things you can do in C# that you can't do in
> VB.NET (just as there are some the other way round, as shown above)
> but these aren't generally very important - unsafe code is very
> rarely useful to most people. Operator overloading can occasionally
> be nice, but it's more that it's great on some of the system types
> (TimeSpan, DateTime) than that it's important to be able to overload
> yourself.
I disagree. For starters, implicit conversion operators are VERY
important and you're probably using them every day without noticing
them, but you can't use them in VB.NET (or you have to use the dreaded
op_Implicit...)
Also, operator overloading is underestimated a lot as well. For
example, I've managed to create a 'linq-ish' language with operator
overloading alone to create typed, compiletime checked filters for my
O/R mapper, a few other O/R mappers like genome and I believe also db4o
use similar constructs.
I find it a pity that C# doesn't allow you to define your own
operators as well, because there are just a few operators to overload.
So while I can do:
IPredicate f = (CustomerFields.CompanyName=="Microsoft");
It's harder to create a simple construct to write a subquery filter as
the operator(s) required aren't definable like 'IN'. (with C# 3.0, this
ofcourse changes).
Frans
Frans Bouma [C# MVP]
> Jon,
>
> >
> > If the extras aren't just there for compatibility, could you explain
> > why they are there? There are plenty of VB.NET functions which have
> > identical functionality to "normal" .NET framework methods. Why have
> > redundant functions other than for the sake of compatibility?
> >
> Exactly as you wrote, "plenty of" not all and it is even a minority,
> however I don't think that this C# newsgroup is the right place for
> that, maybe we can discuss this sometime when this question comes up
> again in the "General" newsgroup.
Dont backtrack now, show the list of stuff which ISN'T there for
backwards compatibility and stuff added deliberately to the language to
make it 'better'
FB
Cor Ligthert [MVP]
>Don't backtrack now, show the list of stuff which ISN'T there for
>backwards compatibility and stuff added deliberately to the language to
>make it 'better'
If you challenge me, I don't like to show it here, there as I wrote there
are better places for that.
See almost all converting methods, they do more than only function as a
wrapper around the parse or convert.
See especially some date methods, which surely extend the Net functions.
There are as well inbuilt financial methods and mathematical methods which
are not as that in the Net.
Be aware that I was agreeing with Jon that some are redundant, in that case
I use the Net methods, while I absolute do not use methods which use the one
as indexer because that confuses me, by instance the vb collection. Most of
the ones active in languages.vb newsgroup have the idea that the
vb.collection should have been placed in the visualbasic compatible
namespace. Not unlikely that you are confused by it, that the compatible
namespace is a separated namespace.
Of course can you can make all those methods yourself. However, I started
with only very few instructions and could do everything. I tell often that
I only need an If, a branch conditional, an add and the possibility to shift
to negative to be able to do everything. However, don't ask me how much time
that takes.
Cor
"Frans Bouma [C# MVP]" <perseus.us...@xs4all.nl> schreef in bericht
news:xn0e87h6...@news.microsoft.com...
Kevin Spencer
> the C# switch statement the most lamest version of a switch statement
> you could possibly design, for the sole reason that it has:
As much as I love C#, this is also one of my pet peeves, and I certainly
don't see the logic in it. It doesn't make C# any "safer." It reminds me of
the sort of thing that VB does to prevent developers from accidentally
creating logical errors. The "break" statement should stay, but the "no
fall-through" rule is monumentally stupid.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.
"Frans Bouma [C# MVP]" <perseus.us...@xs4all.nl> wrote in message
news:xn0e87h0...@news.microsoft.com...
Mythran
> The "break" statement should stay, but the "no
> fall-through" rule is monumentally stupid.
>
I agree whole-heartedly! :)
Mythran
Jon Skeet [C# MVP]
> I never thought the day would come I would say anything in favor of ...
> VB, but here it goes ;) ->
>
> Jon Skeet [C# MVP] wrote:
> > Aside from those, I would suggest using C#, for the following reasons:
> >
> > 1) As it was designed specifically for the .NET framework, it's more
> > closely aligned to it. It doesn't have a load of legacy quirks -
> > about the quirkiest it gets is in the switch statement. Compare this
> > with the various oddities of VB.NET which are basically there for
> > backwards compatibility, for instance the String "Nothing" handling.
>
> still, the VB.NET select case statement is IMHO more powerful. I find
> the C# switch statement the most lamest version of a switch statement
> you could possibly design, for the sole reason that it has:
> - lame 'break' statement which is completely redundant (no fall through
> supported)
> - because of no fall through, you have to use 'goto'. So, using
> spagetti with goto is preferred over having fallthrough.. I don't get
> it.
> - VB.NET's select case has range filters for the case clauses, which
> are very powerful.
Yes, VB.NET's select is indeed more powerful - although it's really
only the equivalent of
if (...)
{
}
else if (...)
{
}
as far as I know. Does it use the same switch/case IL construct
(whatever that is - I haven't looked into it) that C# does where it's
able to?
> > 3) It uses more standard terminology than VB.NET - null, internal etc.
>
> Isn't this subjective?
No, I don't think so. Look at the terminology the CLI specification -
it talks in largely C#-friendly terms such as "this" and "null" rather
than "Me" and "Nothing".
Plenty of other languages use the concepts of "this" and "null" too -
how many others use "Me" and "Nothing"?
> > There are specific things you can do in C# that you can't do in
> > VB.NET (just as there are some the other way round, as shown above)
> > but these aren't generally very important - unsafe code is very
> > rarely useful to most people. Operator overloading can occasionally
> > be nice, but it's more that it's great on some of the system types
> > (TimeSpan, DateTime) than that it's important to be able to overload
> > yourself.
>
> I disagree. For starters, implicit conversion operators are VERY
> important and you're probably using them every day without noticing
> them, but you can't use them in VB.NET (or you have to use the dreaded
> op_Implicit...)
That's why I said that it's great on system types, but that you rarely
need to write your own operator overloads.
> Also, operator overloading is underestimated a lot as well. For
> example, I've managed to create a 'linq-ish' language with operator
> overloading alone to create typed, compiletime checked filters for my
> O/R mapper, a few other O/R mappers like genome and I believe also db4o
> use similar constructs.
>
> I find it a pity that C# doesn't allow you to define your own
> operators as well, because there are just a few operators to overload.
> So while I can do:
> IPredicate f = (CustomerFields.CompanyName=="Microsoft");
>
> It's harder to create a simple construct to write a subquery filter as
> the operator(s) required aren't definable like 'IN'. (with C# 3.0, this
> ofcourse changes).
Personally, I think that when you get into too many operators and
implicit conversions, the code becomes very hard to read. Just my
experience of C++ though...
Jon Skeet [C# MVP]
> > I find
> > the C# switch statement the most lamest version of a switch statement
> > you could possibly design, for the sole reason that it has:
>
> As much as I love C#, this is also one of my pet peeves, and I certainly
> don't see the logic in it. It doesn't make C# any "safer." It reminds me of
> the sort of thing that VB does to prevent developers from accidentally
> creating logical errors. The "break" statement should stay, but the "no
> fall-through" rule is monumentally stupid.
I'd go the other way. Falling through has proved buggy in many, many
C/C++ programs. I'd go for implicit breaks and still avoiding falling
through - or possibly have an explicit "continue" if you want to fall
through, to make it obvious that it's not just an omission.
Cor Ligthert [MVP]
This is not cricket.
>> Plenty of other languages use the concepts of "this" and "null" too -
>> how many others use "Me" and "Nothing"?
>
All those language derive from C. You probably know more which use "this"
and "null". VBNet derives from standard Basic, I doubt if the amount of
users in these two environments are very much apart from each other.
I don't agree with your 'if', however don't find it worthfull to argue with
you about that in the context of this thread. (Has nothing to do with you
personally)
Cor
Kevin Spencer
> C/C++ programs. I'd go for implicit breaks and still avoiding falling
> through - or possibly have an explicit "continue" if you want to fall
> through, to make it obvious that it's not just an omission.
I guess it's just the Libertarian in me. I prefer to take responsibility for
myself. And the falling through is so convenient.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.
"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message
news:MPG.1db0c66e7...@msnews.microsoft.com...
Jon Skeet [C# MVP]
> > I'd go the other way. Falling through has proved buggy in many, many
> > C/C++ programs. I'd go for implicit breaks and still avoiding falling
> > through - or possibly have an explicit "continue" if you want to fall
> > through, to make it obvious that it's not just an omission.
>
> I guess it's just the Libertarian in me. I prefer to take responsibility for
> myself. And the falling through is so convenient.
It's very occasionally convenient in my experience, but I *have* had
bugs where I've fallen through accidentally.
I like the language to try to stop me from shooting myself in the foot.
Jon Skeet [C# MVP]
>
> >> Plenty of other languages use the concepts of "this" and "null" too -
> >> how many others use "Me" and "Nothing"?
> All those language derive from C.
Really? Here's a small sample of the languages which have a "null"
concept:
Delphi
CIL
Perl
C
C++
Java
JavaScript
SQL
COBOL
Do you really want to claim that *all* of those derive from C? Even
VBScript has Null!
> You probably know more which use "this"
> and "null". VBNet derives from standard Basic, I doubt if the amount of
> users in these two environments are very much apart from each other.
Which Basic do you mean by "standard Basic"? I've used at least 5
different versions of Basic, and VB is the only one I've come across
with "Me" and "Nothing".
For me, however, the most important thing is that the .NET framework's
standard terminology is to use "null" and "this". Look at the libraries
- do you see DbNothing, or the IsNothingable or IsNothing property? Do
you see it talked about in the spec? Where is
"NothingReferenceException"?
VB.NET is the language which sticks out here, IMO.
> I don't agree with your 'if', however don't find it worthfull to argue with
> you about that in the context of this thread. (Has nothing to do with you
> personally)
<shrug> Any time you feel like discussing it, I'm open to it.
Bruce Wood
I find I need to write my own operator overloads just about as often as
I need to create my own value types.
Which, I admit, isn't very often, but I found it odd that VB.NET
allowed me to create my own value types but not overload operators. At
least they fixed that in Whidbey.
(In passing, I can't help but point out that this article on operator
overloading in VB.NET;
has an example of creating a complex number _class_. Now why on earth
would anyone want a complex number reference type...?)
Steve Walker
Bruce Wood <bruc...@canada.com> writes
>http://msdn.microsoft.com/vbasic/whidbey/default.aspx?pull=/library/en-u
>s/dnvs05/html/vboperatoroverloading.asp
>
>has an example of creating a complex number _class_. Now why on earth
>would anyone want a complex number reference type...?)
A good question; surely it should have value type semantics. However, I
found the same kind of thing in my own code today; a Money class, rather
than a Money struct. It's got a reference to an instance of Currency and
a quantity:double.
I've got a Thing which has a property of Amount:Money. Thing has a
static Empty:Thing property which returns a new instance of
EmptyThing:Thing. EmptyThing is a private inner class. Thing overrides
Equals to say that two Things with the same ID are equal. EmptyThing
initialise its ID immutably to -1 so that always Thing.EmptyThing ==
Thing.EmptyThing. I specifically didn't want a shared static instance of
EmptyThing because some of its properties *are* mutable. This convention
works well, the pattern is repeated throughout the system and there is
code within the DB access layer which treats an ID of -1 as dbnull. I
think a single magic number per system isn't too bad :o)
There's a custom webcontrol which takes a collection of Thing and
generates a table displaying a row for the details of each Thing, with
Save and Delete buttons. It also inserts a row at the end which displays
an instance of EmptyThing with an add button.
[Off topic, any comments on this architecture?]
The issue I dealt with today was a request that the empty row be
initialised to the values of the row before it, because usually all of
the Things in a collection had most of the values the same. So I added a
Mimic(Thing thingToCopy) method to Thing which copies the properties of
thingToCopy to the instance which it is called upon (I wanted
specifically to modify the instance of EmptyThing, which creates a whole
new worry for me about the id==id equality test, but ignore that for
now). At which point I noticed [getting back on topic] that Money was a
reference type, and that setting this.amount = thingToCopy.amount would
potentially cause problems if I changed the quantity or currency of
amount.
So, back to Bruce's complex number, why did I originally code something
with obviously value-type semantics as a reference type? I like to think
that I'm reasonably conscientious and careful about this kind of thing,
and I've understood the difference for as long as I've been using C#. I
can only imagine that when I wrote the code, at the back of my mind, I
had the concept that value types were for optimisation of performance
rather than for representing things which really do have value
semantics. If I'd thought about it the choice would have been obvious; I
obviously didn't. Java developers must have to put up with not being
able to do this properly all time, .NET developers should be able to
make the right choice.
I'm slightly ashamed to say that I didn't change Money to a struct, I
created a new instance of money with the quantity and currency from the
instance I copied. I did this because I didn't want to track down any
other references to the class which relied on reference-type semantics.
I suppose the question this whole thing poses is whether the emphasis on
the function of value types has been skewed away from their role in
modelling a system and towards their use for performance purposes; have
we spent too much time arguing over whether or not scenarios induce
boxing when we should really have been thinking about whether an entity
was correctly modelled by a reference or value type? Also, I don't
recall any way of differentiating the two in UML; surely this is an
analysis decision, not a coding technicality?
What do you think?
Worth a new thread to discuss?
--
Steve Walker
Adam Tibi
writing or language versus the actual content. That might make you an MUP,
and as you already figured out, UP stands for unprofessional.
Second, if you don't understand the content while others did then your
problem is not with me, it is in you, maybe you need more training sessions,
check it out.
Finally, learn to reply to the content or don't reply, unless you want your
name to be published every were and that would keep you holding your MVP!
This is my first unproductive post on any forum, but I couldn't help myself
because you've invited me to start hating you and I accepted it!
Cor Ligthert [MVP]
> Actually, I think that it would unprofessional to comment on my style of
> writing or language versus the actual content.
Can you tell me where I wrote that in my reply to Kevin? I will be probably
the last one who not completely agrees about that with you. In fact it was
Kevin who did that.
My reply had nothing to do with your style of writing it had to do with the
fact that Kevin gave me the idea that he had not even read your message and
therefore was only trolling my reply to you.
In my opinion are there some things in the content of your original answer
that makes that probably not much people will read it after they have seen
this starting sentence.
>>C# syntex is derived from the mother of all languages C++
AFAIK is C# the only language derived from C++.
I had read your message completely and had the idea that I understood
everything you wrote. I had the idea that most maybe came from your hart but
is not based on much investigation
Therefore I gave you the link to Wikepedi, I assume that you would not be
glad when I was only copying the content of that in a message.
Cor
Adam Tibi
maybe your first reply should have included the "mother of all languages"
thing so I would have understood what is going on.
What I meant by saying that C++ is the mother of all languages is that C#,
PHP, Java, JavaScript and others that I don't know tried to follow the syntax
of C/C++! Well, how far they went varies between one language and another and
undoubtly C# was the pioneer.
My comments comparing C# versus VB.NET is emotional, I agree on that, and
such topic requires emotional rather than logical answers.
Sorry for being unpolite, this is a lesson for me to listen more than I
speak and believe me I am working on it :)
Frans Bouma [C# MVP]
> Kevin Spencer <ke...@DIESPAMMERSDIEtakempis.com> wrote:
> > > I find
> > > the C# switch statement the most lamest version of a switch
> > > statement you could possibly design, for the sole reason that it
> > > has:
> >
> > As much as I love C#, this is also one of my pet peeves, and I
> > certainly don't see the logic in it. It doesn't make C# any
> > "safer." It reminds me of the sort of thing that VB does to prevent
> > developers from accidentally creating logical errors. The "break"
> > statement should stay, but the "no fall-through" rule is
> > monumentally stupid.
>
> I'd go the other way. Falling through has proved buggy in many, many
> C/C++ programs. I'd go for implicit breaks and still avoiding falling
> through - or possibly have an explicit "continue" if you want to fall
> through, to make it obvious that it's not just an omission.
I see your point, and I also understand that implicit fall-through
implies an order in which the case statements are written which also is
a source for problems.
I would love to have a keyword, continue or what ever, which suggests
proper fallthrough or some other flow, so I can avoid replicating small
code snippets, like:
switch(foo)
{
case 1:
DoA();
break;
case 2:
DoA();
DoB();
break;
}
etc.
FB
Frans Bouma [C# MVP]
I didn't check when I posted, but I did a small check and you're right!
VB code:
Sub Main()
Dim i As Int32
i = 42
Select Case i
Case 0 To 10
Console.WriteLine("10s")
Case 11 To 42
Console.WriteLine("rest")
End Select
End Sub
C# decompiled code:
[STAThread]
public static void Main()
{
int num2 = 0x2a;
if ((num2 >= 0) && (num2 <= 10))
{
Console.WriteLine("10s");
}
else if ((num2 >= 11) && (num2 <= 0x2a))
{
Console.WriteLine("rest");
}
}
I think, with strings it's also not able to use the optimization the C#
compiler uses with a static hashtable, because of the if's. (if you're
using case string1 to string2
> > > 3) It uses more standard terminology than VB.NET - null, internal
> > > etc.
> >
> > Isn't this subjective?
>
> No, I don't think so. Look at the terminology the CLI specification -
> it talks in largely C#-friendly terms such as "this" and "null"
> rather than "Me" and "Nothing".
>
> Plenty of other languages use the concepts of "this" and "null" too -
> how many others use "Me" and "Nothing"?
Not much, but how many languages NOT related to C-derived languages
use 'this' and 'null' ?
I agree, 'Me' is pretty silly, but 'Nothing' makes sense in a way.
What I find way more irritating is the type declaration AFTER the
variable (Dim foo As SomeType), because that makes porting code to
VB.NET pretty cumbersome
> > Also, operator overloading is underestimated a lot as well. For
> > example, I've managed to create a 'linq-ish' language with operator
> > overloading alone to create typed, compiletime checked filters for
> > my O/R mapper, a few other O/R mappers like genome and I believe
> > also db4o use similar constructs.
> >
> > I find it a pity that C# doesn't allow you to define your own
> > operators as well, because there are just a few operators to
> > overload. So while I can do:
> > IPredicate f = (CustomerFields.CompanyName=="Microsoft");
> >
> > It's harder to create a simple construct to write a subquery filter
> > as the operator(s) required aren't definable like 'IN'. (with C#
> > 3.0, this ofcourse changes).
>
> Personally, I think that when you get into too many operators and
> implicit conversions, the code becomes very hard to read. Just my
> experience of C++ though...
Agreed, but IMHO that's also up to the developer of course. In any
language you can write unreadable code. With the proper operators you
can make code MORE readable than it is now and definitely make it more
usable for developers. KEY part of that of course is that the operators
you overload are logical to the constructs they're used with. In C# we
have 1 bad example of that, the '+' sign for string concatenation
(IMHO): '+' stands for an addition, i.e. a mathematical action, but you
can't apply that kind of action on a string (in theory).
FB
Frans Bouma [C# MVP]
> > That's why I said that it's great on system types, but that you
> > rarely need to write your own operator overloads.
>
> I find I need to write my own operator overloads just about as often
> as I need to create my own value types.
>
> Which, I admit, isn't very often, but I found it odd that VB.NET
> allowed me to create my own value types but not overload operators. At
> least they fixed that in Whidbey.
>
> (In passing, I can't help but point out that this article on operator
> overloading in VB.NET;
>
> http://msdn.microsoft.com/vbasic/whidbey/default.aspx?pull=/library/en
> -us/dnvs05/html/vboperatoroverloading.asp
>
> has an example of creating a complex number class. Now why on earth
> would anyone want a complex number reference type...?)
I'd reverse that: why on earth do we need value types? I mean, I
understand they speed things up internally, but why should I be
bothered with that? Because there are value-types, we still have stupid
hacks for nullable ints in C#, even in .NET 2.0. C++ doesn't have
slowdowns when it comes to using pointers to ints, managed code does,
which is kind of odd, when you consider the machine the managed code is
used in is virtual, e.g.: you can make it act like you want it to act.
However a corner-cutting action bleeded through into the languages:
value types.
FB
Jon Skeet [C# MVP]
<snip>
> > Plenty of other languages use the concepts of "this" and "null" too -
> > how many others use "Me" and "Nothing"?
>
> Not much, but how many languages NOT related to C-derived languages
> use 'this' and 'null' ?
See my reply to Cor - SQL, Perl and VBScript, for starters.
> I agree, 'Me' is pretty silly, but 'Nothing' makes sense in a way.
But it's not the same as the terminology elsewhere - and as VB.NET
developers are likely to have to read things other than VB.NET (such as
the CLI spec) it's an extra set of terminology to learn.
> What I find way more irritating is the type declaration AFTER the
> variable (Dim foo As SomeType), because that makes porting code to
> VB.NET pretty cumbersome
Right.
> > > It's harder to create a simple construct to write a subquery filter
> > > as the operator(s) required aren't definable like 'IN'. (with C#
> > > 3.0, this ofcourse changes).
> >
> > Personally, I think that when you get into too many operators and
> > implicit conversions, the code becomes very hard to read. Just my
> > experience of C++ though...
>
> Agreed, but IMHO that's also up to the developer of course. In any
> language you can write unreadable code. With the proper operators you
> can make code MORE readable than it is now and definitely make it more
> usable for developers. KEY part of that of course is that the operators
> you overload are logical to the constructs they're used with. In C# we
> have 1 bad example of that, the '+' sign for string concatenation
> (IMHO): '+' stands for an addition, i.e. a mathematical action, but you
> can't apply that kind of action on a string (in theory).
I think adding two strings together is pretty intuitive myself, but
there are plenty of people who've suggested operators they want to
overload but haven't been able to (thankfully). To be able to introduce
your own extra operators would make things even worse, IMO.
Cor Ligthert [MVP]
It is in my opinion not relevant if it is with your sample technical right.
The documentive power from the "select case" start where we get code like
beneath.
VB code:
Sub Main()
Dim i As Integer = 42
Select Case i
Case 1,5, 7, 19, 39
Console.WriteLine("first form")
Case 11, 9, 10, 24, 28
Console.WriteLine("second form")
Case Else
Console.WriteLine("not on a form")
End Select
End Sub
(Any relation with a Lotto form is pure coincidence)
In the way you showed the code I will forever prefer an "if else".
Cor
Cor Ligthert [MVP]
>
> But it's not the same as the terminology elsewhere - and as VB.NET
> developers are likely to have to read things other than VB.NET (such as
> the CLI spec) it's an extra set of terminology to learn.
>
First I thought, Jon has here a point.
However, than I thought is "null" not very much a representation to a very
old historic binary null situation in physical memory addresses (in by
instance the code part of the machine code), which represent *nothing*
assigned.
Does Nothing than not more reflect the way as a symbolic language has to
deal with it?
Just a thought,
Cor
Cor Ligthert [MVP]
Rereading the message from Frans, do I think that he has a *kind* of same
opinion.
Frans, I can be wrong of course in that.
Cor
Frans Bouma [C# MVP]
> Jon,
>
> Rereading the message from Frans, do I think that he has a kind of
> same opinion.
>
> Frans, I can be wrong of course in that.
The philosophy of VB(.NET) is that the language should represent
english speak as much as possible.
so if you want to test if a variable points to void, you could say:
If foo Is Nothing Then
'...
End If
Which IMHO makes sense, in the scope of that philosophy, although you
could also argue:
If foo Is Void Then
or
If foo References Nothing Then
(which I would find even more readable)
defining 'null' as 'undefined' is IMHO the result indeed of having a
pointer set to 0x0000.0000 as a unified 'undefined' value.
Jon Skeet [C# MVP]
I don't think it's particularly relevant - the point is that VB.NET
developers still need to know what null is, because so much of the
documentation, specifications etc refer to it. Why learn two ways of
saying the same thing, if you can instead learn a language which uses
the more common way of talking about things?
Kevin Spencer
Peronally, I understood your remark about "the mother of all languages." It
was beside the point to point out the minor technical issue. In fact, C was
written to look more or less like Pascal, so one might argue, with
Lillipution intent, that Pascal was the "mother of all languages." Still, it
would indeed be pointless to do so.
I appreciated your enthusiasm, and, regardless of the occasional
technicality, I found your arguments for the most part quite understandable.
In fact, as it was an expression of opinion, and not a factual answer to a
question, I considered it less important that it should be "absolutely
factually correct" (if that is possible, considering the vagaries of
language).
It irritates me to see people publicly correct others without some
valid/helpful reason for doing so. If, for example a person asks a question,
and a person responding speaks without knowledge, and therefore leads the OP
down the wrong path to a solution, I feel it necessary to correct the person
responding, and provide the correct information. This helps the OP to find
the solution they seek. On the other hand, when a person is asked for an
opinion and gives it, and is incorrect on some minor technical point, who is
harmed by it? Why should the person venturing the opinion be publicly
corrected for their perceived and minor error? Who is helped by it? The only
conclusion I can draw from such behavior is that ther person doing the
correcting is attempting to elevate public perception of their knowledge at
another person's expense. And that is both unnecessary and uncalled-for.
It took 4 years for Microsoft to develop the first version of the .Net
platform. I will be the first person to admit that I don't know everything
about it. I do, however, know how to research, and am quite good at that.
When I first began to program, I relied heavily on help from others who were
farther along the path than I. Now I feel a sense of responsibility to do
the same. That is my motivation. I help when I can, and keep silent when I
can not.
I did feel a certain need to step in to your defense. I don't like to see
people bullied. And I can hold my own in a scuffle. I don't mind a knock or
two here and there. I can give as good as I get. I am confident in my
professional life, and not afraid of the opinions of others. They cannot
harm me professionally, and I have a thick skin. So, from time to time I
will step in to defend someone else. Call me a glutton for punishment.
But don't feel bad that you may have somehow embarassed yourself with your
contribution. I found it quite refreshing! :)
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.
"Adam Tibi" <Adam...@discussions.microsoft.com> wrote in message
news:DDFB43F5-1DF7-4F6E...@microsoft.com...
Adam Tibi
Thank you for this nice reply and thank you for defending me.
Have a nice weekend
"Kevin Spencer" wrote:
> ..Net Developer
Michael A. Covington
>> It
>> was beside the point to point out the minor technical issue. In fact, C
>> was
>> written to look more or less like Pascal, so one might argue, with
>> Lillipution intent, that Pascal was the "mother of all languages." Still,
>> it
>> would indeed be pointless to do so.
And ALGOL 60 is the mother of Pascal. Does that mean ALGOL is C#'s
great-grandmother?
Or that Delphi is C#'s great-aunt? :)
Doug H
http://boo.codehaus.org/
i = 42
given i:
when 1,5,7,19,39:
print "first form"
when 11,9,10,24,28:
print "second form"
otherwise:
print "not on a form"
or your other example:
i = 42
given i:
when 0 <= i <= 10
print "10s"
when 11 <= i <= 42
print "rest"
http://jira.codehaus.org/browse/BOO-136
I'm not saying it's better or worse or anything.
To the guy who's deciding about what language to use for new hires, I'd
probably recommend C# if they are already familiar with java or C++
(which is likely if they are CS grads).
Cor Ligthert [MVP]
> And ALGOL 60 is the mother of Pascal. Does that mean ALGOL is C#'s
> great-grandmother?
>
> Or that Delphi is C#'s great-aunt? :)
>
I think that you are right, however in my opinion is Algol not completely
the mother of all languages.
I think that it can be called that for all by mainly Beta's used languages.
The sister Cobol can in my opinion be seen as a mother of all languages for
the "Alpha's".
Strange enough are that much less while they have AFAIK a very broad public
that uses them.
Cor
ig...@yahoo.com
Cor Ligthert [MVP]
Bruce Wood
it didn't have much effect. :-)
Yes, in a few situations, structs offer performance benefits. You can
see typical uses in this regard in System.Drawing.Point and
System.Drawing.Rectangle, among others. They're things that by rights
ought to have reference semantics that were made into structs for
performance reasons, I think. At least, I can't think of any other
reason to create _mutable_ value types and suffer the resulting
confusion among programmers using your class library.
That said, value types are incredibly... um, valuable... when it comes
to modeling things that are _values_. I'm going to try very, very hard
not to believe that you're honestly suggesting that ints should have
been reference types. Do you really believe that this code:
int a = 5;
int b = a;
a = 16;
Console.Writeline("{0}", b);
should write 16? Can you imagine how difficult it would be wrap your
mind around programming in a language with only reference semantics?
Just imagining the mayhem makes my head hurt. :) If memory serves,
even venerable LISP, the everything-is-a-reference-type language, took
pains to avoid this.
Complex numbers, money (quantity plus currency), measures (quantity
plus unit of measure) and other such things are natural value types.
For the complex numbers example,
int a = new Complex(5, 1);
int b = a;
a *= a;
should leave b containing [5, 1] as before, not [-25, 0], which is what
a would contain (pardon if I made an error there... I haven't worked
with complex numbers in 20 years). In other words, the thing should act
like a value, not like an object with reference semantics. As Steve
Walker pointed out, when I add $5.00 and $0.25 and put the result back
in the original variable, I really don't want every $5.00 quantity in
my system to change to $5.25. That would be nasty.
Sorry for the rant, but it drives me nuts when people start building
Customer structs, saying that it's "more efficient", and then wonder
why their code does all these weird things. It drives me even crazier
to know that Microsoft has a (VB) example of how to use structs in
their knowledge base that shows a Customer struct with a half-dozen
fields. Aaaargh!
Bjorn Abelli
> That said, value types are incredibly... um, valuable... when it comes
> to modeling things that are _values_. I'm going to try very, very hard
> not to believe that you're honestly suggesting that ints should have
> been reference types. Do you really believe that this code:
>
> int a = 5;
> int b = a;
> a = 16;
> Console.Writeline("{0}", b);
>
> should write 16? Can you imagine how difficult it would be wrap your
> mind around programming in a language with only reference semantics?
> Just imagining the mayhem makes my head hurt. :)
I don't see this as a good example on what you mean. Why should it write 16?
When you're assigning a literal to a variable, you could say you're
assigning another object, not changing the objects contents.
int a = 5;
int b = a; // Is now referencing 5
a = 16; // Is now referencing 16
Console.Writeline("{0}", b);
b is still referencing 5
Try this for comparison:
string a = "Hello";
string b = a; // Is now referencing "Hello"
a = "World"; // Is now referencing "World"
Console.Writeline("{0}", b);
b is still referencing "Hello".
This is really no different than:
Customer a = new Customer("Bill");
Customer b = a; // Is now referencing Bill
a = new Customer("Bob"); // Is now referencing Bob
Console.WriteLine("{0}", b);
b is still referencing "Bill"
So the traditional logic when using primitives or value types shouldn't
necessarily need to change just because they became reference types instead.
At least no changes that I can see at the moment. I think much lies in how
to define the behaviour of the operators.
But there still might be other issues with using only reference types rather
than having both value and reference types... ;-)
// Bjorn A
Bruce Wood
order to get into trouble with integers-as-reference-types, there would
have to be some quality of the integer itself that was mutable, so that
you could get into trouble by changing that mutable quality in one
place and having it change everywhere.
Anyway, the point was that I like value types. They're powerful when
used in the correct contexts, but a terrible pain when used in the
wrong contexts. Most complaints I've seen in this discussion group
about what a bad idea value types are arise from people using them for
the wrong reasons.