D
doug00
Chad said:
It was clearly a misinterpretation and a misreading on your part.
It was clearly a misinterpretation and a misreading on your part.
D
doug00
Jon said:
That begs the question, how is it obvious (to a beginner especially)
that something refers to a type name? In fact, the concept of "type"
itself is very difficult to explain:
http://lambda-the-ultimate.org/node/view/412
I'll just say that VB.NET for its part did find one solution to make
type declarations easy to recognize.
For others who somehow take what I say as some insult to their favorite
language, note I wasn't referring to C# or any other language, so I
hope you won't somehow interpret what I say as a sting against C#. I
like C# a great deal. Especially for people with familiarity with
java/C/C++, I'd recommend that over VB.NET in a heart beat. Does that
mean it is bad for beginners without that experience, too? No.
J
Jon Skeet [C# MVP]
If someone isn't interested in learning the fundamentals of a language
(like what a type is) before diving into the language, I think they're
making a big mistake. Maybe VB.NET makes it easier to dive into the
language, giving it an advantage for a couple of days - but as I don't
think that's a terribly appropriate way to learn a language/platform
anyway, I don't think it's a very important advantage.
A lot of people are far too impatient to get straight into GUI
programming, without taking the trouble to learn either the language
they're using or the basics of the platform it's running on. I always
urge people to start with very simple console apps that don't need to
use any library calls other than printing out values and possibly a bit
of string manipulation. Move onto collections, then IO, then you may be
ready for some GUI work - although it would frankly be better to learn
a bit about threading before starting on GUI work, as it's so important
there.
But you still need to use the redundant keywords all the time, even
after you've got over the slight learning curve in terms of recognising
what constitutes a declaration.
I wouldn't say that it's bad for beginners, but I *would* say that some
of the verbosity and non-standard terminology which supposedly makes it
better for beginners becomes a pain when you actually know what you're
doing.
Of course, you've got to add to that the fact that it's a much bigger
language in itself than C# - far more in the way of keywords, built-in
functions etc.
S
Steve Walker
In message <[email protected]>, Jon Skeet
I used to work for a company which was a VB6 shop. I got the job of
evaluating .NET. My recommendation was that we abandon VB and go the C#
route, which we did. None of the developers (who ranged in experience
from very little to lots) had any trouble learning C#.
One of my former colleagues came with me on a fishing trip last night,
and mentioned that he was glad I went for C#; he's recently left that
company to become a contractor, and he says the rates of pay for C# are
much better.
That might be because C# is (wrongly, IMO) perceived as being harder,
but I suspect it's actually because the kind of talentless,
cut-and-paste, whole-program-in-an-event-procedure spaghetti-code
merchants who gave good VB6 developers an undeserved bad name are
unlikely to have bothered learning C#. I'm sure that those people don't
post to advocacy threads on *.languages.* newsgroups, so I don't mean to
insult anyone by saying that, and I dare say there are some crusty
former C programmers writing entire C# programs in Main(), but I fear
that perception may still be out there.
For what it's worth, I side with another friend of mine who has been
paid to program in more languages than I can name; if you're any good,
you'll be able to teach yourself whatever language the job requires. I
really don't see that anyone competent in VB.NET should take more than a
couple of days to become proficient in C#, and vice-versa. The learning
curve is all in the framework and the understanding of OO.
I used to work for a company which was a VB6 shop. I got the job of
evaluating .NET. My recommendation was that we abandon VB and go the C#
route, which we did. None of the developers (who ranged in experience
from very little to lots) had any trouble learning C#.
One of my former colleagues came with me on a fishing trip last night,
and mentioned that he was glad I went for C#; he's recently left that
company to become a contractor, and he says the rates of pay for C# are
much better.
That might be because C# is (wrongly, IMO) perceived as being harder,
but I suspect it's actually because the kind of talentless,
cut-and-paste, whole-program-in-an-event-procedure spaghetti-code
merchants who gave good VB6 developers an undeserved bad name are
unlikely to have bothered learning C#. I'm sure that those people don't
post to advocacy threads on *.languages.* newsgroups, so I don't mean to
insult anyone by saying that, and I dare say there are some crusty
former C programmers writing entire C# programs in Main(), but I fear
that perception may still be out there.
For what it's worth, I side with another friend of mine who has been
paid to program in more languages than I can name; if you're any good,
you'll be able to teach yourself whatever language the job requires. I
really don't see that anyone competent in VB.NET should take more than a
couple of days to become proficient in C#, and vice-versa. The learning
curve is all in the framework and the understanding of OO.
C
ChrisN
I always fancied doing a contract in Italy, on the basis that it may be
the only place where I am not told "Don't bother spending time making
the interface look nice".
Even a drain cover in Italy is beautifully designed.
Chris
the only place where I am not told "Don't bother spending time making
the interface look nice".
Even a drain cover in Italy is beautifully designed.
Chris
C
Chad Z. Hower aka Kudzu
[email protected] said:
While it certainly was a misreading - a lot of it was how you worded it. I think that most users will
read it the way that I did in the manner you worded it.
H
Herfried K. Wagner [MVP]
Jon Skeet said:
It doesn't take long, but the code is still not as self-documenting and
self-explanatory as the VB.NET code is.
Yes, I actually think that VB.NET's casting syntax is better because it
doesn't suffer from the "lots of brackets" problem:
\\\
((SampleForm)foo.MdiParent).Bla();
///
versus
\\\
DirectCast(foo.MdiParent, SampleForm).Bla()
///
However, I don't think that VB.NET's solution is the best possible solution.
I'd like to see something like shown below as casting syntax:
\\\
(e-mail address removed)()
Dim x As IFooBar = goo.Bar.@IFooBar
///
There are many specialized keywords a beginner doesn't need to be aware of
('Declare', 'Auto', 'Unicode', 'Ansi', 'Alias', etc.). Some other keywords
increase readability of the code and are thus worth learning ('Overloads',
'AddressOf', 'RaiseEvent', 'Implements', 'Inherits', 'MyBase', ...). Other
keywords listed for VB.NET are not keywords at all ('Variant', 'Wend',
'GoSub', 'Let', 'EndIf', ...). Keywords like 'REM' and 'Stop' are rarely
used. The list of C# keywords doesn't include operators, but VB operators
are listed as keywords ('Or', 'And', 'OrElse', 'AndAlso', 'Xor', 'Not',
'Mod', ...). Another class of keywords are keywords for features only
supported by one of the programming languages ('Like', 'With', 'My',
'WithEvents', 'Handles', 'Where', 'On', 'Error', 'Resume', ...).
Use of these functions is optional, it's not crucial to know how these
functions work.
I think that both languages, C# and VB.NET, carry over a lot of legacy
syntax. I believe that the ability to reuse knowledge is very important for
the success of a new programming language. Additionally I prefer
code-compatibility to a language's predecessor over revolutionary change.
I have seen it several times when working together with C++ beginners who
come from various backgrounds, and the bug made them ask "Why doesn't the
code work as expected?"...
It's a matter of semantics. The 'Shared' keyword in VB.NET means that the
member is shared between all instances of a class, which is different from
the semantic of 'static' in C#.
VB.NET automatically initializes variables, which is IMO a good thing in
addition to the warning.
I don't see a big problem here...
Yeah, you could still scan the code for the blocks' heads with your eyes,
but this is a costly process.
B
Bill Butler
William (Bill) Vaughn said:
But, are they doing by choice???
Anytime I had to work with VB, it was out of my hands.
The language for the project had been chosen before my time.
Bill
C
Chad Z. Hower aka Kudzu
Herfried K. Wagner said:
This is one thing that I really really dont like about C#. I much prefer Delphi's casting which I thikn
is similar to VB.NET.
SampleForm(foo.MdiParent).Bla();
Ack, Im not to fond of that either.
I'll stick to preferring Delphi's semantics on this one.
C
Chad Z. Hower aka Kudzu
Jon Skeet said:
They are significantly different. C# is much closer to C++, and even then quite different.
H
Herfried K. Wagner [MVP]
Chad,
I don't think that the approaches taken in C#, Delphi, and VB.NET are
optimal. However, I prefer the way Delphi and VB.NET handle casts.
Chad Z. Hower aka Kudzu said:This is one thing that I really really dont like about C#. I much prefer
Delphi's casting which I thikn
is similar to VB.NET.
SampleForm(foo.MdiParent).Bla();
Ack, Im not to fond of that either.
semantics on this one.
I don't think that the approaches taken in C#, Delphi, and VB.NET are
optimal. However, I prefer the way Delphi and VB.NET handle casts.
J
Jon Skeet [C# MVP]
Herfried K. Wagner said:
I think we'll have to agree to disagree.
And again, we'll have to disagree.
Eek - I find that as bad as anything else I've seen, personally.
But you need to know those keywords if you're going to read code which
uses them, and presumably you're prevented from declaring identifiers
with those names (which is where it's not a problem with C# in terms of
the operators being symbols rather than names).
But it's a cause of confusion to someone who's familiar with .NET, but
not as familiar with VB functions.
Whereas I prefer the *language* to be small, and the *library* to be
where functionality lies.
Ah, but in C/C++ it's different - in C/C++ you can get the error with
types other than a boolean. How often have you seen it *with booleans*?
I don't believe it's different at all - and I don't believe it means
it's shared between all instances. Just as in C#, it really means that
the member belongs to the type rather than any particular member. Even
the VB.NET documentation says that:
<quote>
Shared elements are not associated with a specific instance of a class
or structure.
</quote>
The implication from your statement is that the member effectively
doesn't exist if there are no instances (because the set of instances
it is shared between would be empty) whereas that's not true.
Could you give an example where something being static in C# and Shared
in VB.NET would produce semantically different code?
I *do* understand the difference between VB.NET's Static and C#'s
static though.
You still haven't addressed the actual issue though - if someone writes
thread.Sleep(1000)
in VB.NET, it compiles (in VS.NET 2003) without error, but doesn't do
what is expected.
Put it this way - if it's not a bad thing to do, why is there a warning
for it in VS 2005?
It's good to initialize *member* variables, but why would you *want* to
use a local variable which hadn't been definitely assigned? It seems
like a bad idea to me.
Not if the method is well written and indented. I certainly don't spend
a lot of time doing it.
C
Chad Z. Hower aka Kudzu
Herfried K. Wagner said:
The syntax? Or other? I dont like the way C# handles it simply because you often have to add more
() to tell it what to cast, and if you dont it can cast something other than you might expect.
H
Herfried K. Wagner [MVP]
Chad Z. Hower aka Kudzu said:
I don't like the syntax for type casts in C#, I consider it a bad design and
legacy syntax because of the "lots of braces" issue that could have been
solved easily.
On the other hand, I like the syntax for casts in VB.NET and Delphi more.
However, I think that the VB casting syntax is too verbose and thus
increasing the line length of the code without adding much value to the
code. The Delphi casting syntax IMO suffers from the problem that it is
similar to a constructor call, especially when being incorporated into
VB.NET or C#, and thus maybe misleading.
ACK.
J
Jon Skeet [C# MVP]
Chad Z. Hower aka Kudzu said:
I agree it can be a pain sometimes, but I find that usually it's a good
indication that things can be made more readable by using a local
variable - the cast in one statement and the use in another.
It's one of those situations where I think there's no really good
solution - in some cases you *do* want to cast the result of a method
(eg (Foo) x.Something()) and sometimes you want to cast the "starting"
value. I dare say C#'s way isn't the best possible, but I still
personally prefer it to the VB.NET way.
T
Tom Shelton
I so totally agree... VB.NET's way is very cumbersome, especially when
dealing with mutliple casts in the same expression. Besides, for a lot
of simple casts, C# does provide as.
The most confusing cases, IMHO, is when you do something like:
int y = ((Foo) x).CallSomeMethod ();
J
Jon Skeet [C# MVP]
Tom Shelton said:
Exactly - and those are the cases where I'd suggest breaking it up:
Foo whatever = (Foo)x;
int y = whatever.CallSomeMethod();
W
Willy Denoyette [MVP]
Tom Shelton said:
If this is confusing you might try the "clean" way:
...
Foo x = someFooRef as Foo;
int y = x.Dummy();
Willy.
J
Jon Skeet [C# MVP]
Willy Denoyette said:
Or if you'd prefer to get a ClassCastException rather than a
NullReferenceException (as I certainly would - it gives a much better
idea of what's actually happened):
Foo x = (Foo) someFooRef;
int y = x.Dummy();
C
Chad Z. Hower aka Kudzu
Jon Skeet said:
In some cases, but its just another roach point. It allows bugs to creep in, and fairly frequently.
I absolutely do not like the VB.NET way either.