|
| Which Language Should I Choose? |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on microsoft.public.dotnet.languages.vc.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
| Peter McMahon |
Hi all
I've posted an article at
http://www.dotnet.za.net/viewarticle.asp?articleid=12" target="_blank">http://www.dotnet.za.net/viewarticle.asp?articleid=12 that deals with the
issue of what language developers should choose when deciding to learn .NET.
It goes through all the major options (Java/C++/VB/Perl/Python/Delphi
programmer) and gives the pros and cons of each of the major choices
(VB.NET/C#/C++.NET/J#/JScript.NET etc). Hopefully this'll be of use to all
of you who're bewildered by the huge array of options currently available.
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:#bTOFzcgBHA.2344@tkmsftngp07...
[Original message clipped]
Hi,
This is a good article, and it's nice to see some concise summaries of the
languages, but I would have to disagree with your final assessment; I think
that newcomers to the platform who aren't already experienced developers
would be best off choosing VB (if they use Visual Studio) or JScript (if
they don't). These two languages have a bunch of features that make them
friendlier than C#, such as optional variable declaration and latebound /
typeless programming.
Some more specific comments:
1) JScript .NET is indeed part of the .NET "core", and will be installed
everywhere that .NET is installed (including Windows 9x). J# is not part of
the first release, but should be included in the future
2) Visual Studio doesn't support every .NET language -- only those languages
that have explicitly added support for it via VSIP.
3) Transact-SQL should still be in Yukon -- .NET is augmenting it, not
replacing it
4) Amazingly enough, I disagree with your assessment of JScript .NET.
Imagine that! :-). J# will indeed be provided as a migration tool from J++,
but that has nothing to do with JScript -- they are completely different
languages.
You are correct in that JScript .NET's major role is in providing support
for ASP .NET, both for migrating existing code and for new development. For
a web developer who must deal with both client and server code, JScript is
the language of choice since it runs in both environments. It is also
considerably easier to write JScript code than it is to write C# code for
most intents and purposes, as the language supports such features as late
binding, typeless programming, generous implicit conversions,
just-make-it-work defaults, and so on.
The second major focus for JScript .NET is Script for the .NET Framework,
which (like Active Script in the past) allows you to embed either VB or
JScript code inside an application to provide macros, customisations, and so
on. Of course, you can also write console or Windows Forms applications with
JScript .NET, but that's not really a target market for us; our customers
are much more likely to be at home with HTML and XML/XSL than they are with
Windows Forms. And looking towards the future, we are currently
investigating support for JScript .NET inside the browser to enable rich
interactions between the browser, the .NET platform, Web Services, and
Windows Forms. You can check out
http://www.gotdotnet.com/userfiles/torrboy/PDC2001.zip for a demo.
Finally, the developer community for JScript .NET may be small at the
moment, but keep in mind that the total ECMAScript community is arguably
larger than that of any other language. Of course, the majority of our
customers aren't professional developers, and so they won't spend the time
or money to download a 120 MB Beta, but in time I am confident that the
number of JScript .NET users will rival that of any other language.
5) C++ has a lot of benefits for programmers who want ultimate power,
performance, and control in their applications. It's also a great way to
bridge the .NET <--> COM divide.
6) I'm not sure why you think Perl and Python are the only non-Microsoft
languages that can really be considered contenders. Programmers coming to
..NET from other platforms would probably love to try COBOL, FORTRAN, Eiffel,
SmallTalk, and so on -- remember that "new to .NET" doesn't necessarily mean
"new to programming". Some of the other languages are listed at
http://msdn.microsoft.com/vstudio/partners/language/default.asp.
7) Delphi developers may want to check out Component Pascal
(http://msdn.microsoft.com/vstudio/partners/language/universityqueensland.as
p), although I have never used either of the two products so it may not be
ideal.
8) It's hard to say what a good "beginning" language should be. If you want
to spend the money on Visual Studio .NET then VB is probably the way to go.
On the other hand, a beginner may not wish to spend the money on Visual
Studio .NET, and will start playing with framework and Notepad (or another
cheap editor), and in the absence of the Windows Forms / Web Forms
designers, JScript is often much easier to use than the other languages.
Consider the fact that hello world is only:
print("Hello, world")
versus all the other goo you have to write in the other languages. Beginning
programmers are also quite likely to come from a web background, or have at
least taken a simple web design class in high school / college, so they
probably already have some exposure to JScript.
I only wish it was this easy to choose a digital camera!
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| mule |
"Peter Torr \(MS\)" <Click here to reveal e-mail address> wrote in message
<OLgqK9egBHA.1816@tkmsftngp02>...
[Original message clipped]
Optional variable declaration === unmaintainable code.
This is not a good thing. Teaching beginners that this is the way to
code is not good.
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
|
| |
| |
| Ed Stegman |
I couldn't agree more.
Furthermore, I think that his assumption that VB.NET is the logical language for VB6 developers to go is wrong too.
Any competent (Read: Doesn't use data controls. Has used Win32 API. Declares variables. Only uses Variants when absolutely
necessary. Never leaves the runtime a chance for evil type coercion. <Add to list here>) VB developer has only been dating it until
something better showed up, and will be a much happier camper using C#.
And all that marketing crap about having to learn another language along with the BCL and the new programming paradigm of .NET is
malarkey. Moving to VB.NET they have to both learn something new and unlearn the old. Move to C# and it's just learn something new.
Most of which they already know and just haven't found out that they know it yet. :-))
I've already taken 1/2 dozen VB6 programmers (good ones) and had them writing productive code in less than 2 days using C#. Every
one of them says it physically hurts to go back to VB6, and hurts even worse just to look at VB.NET.
And they like the fact they have function overloading, operator overloading, pointers when needed (take a bit more to get them up to
speed here, no doubt), shift operators, unsigned integer data types, signed bytes, and all the other stuff missing from VB. Where
was that in the article?
C# doesn't have any baggage, and one of the primary concerns in the design was to keep things consistent and at the same time
prevent common mistakes that lead to bugs. It's much simpler to learn C# than VB.Net, even for new programmers.
What is there in VB.NET that makes it simpler to learn to write a stable program that is maintainable than C#? C# is not C++, nor
is the learning curve on the same scale.
Another thing that makes C# worth the move for everybody, and a big con against moving to VB, is that C# has been submitted as a
spec to ECMA. This will significantly reduce the chance that the language is changed willy-nilly between version releases of VS, as
VB has with every version. Or, will your VB6 apps just port straight over?
These truths just keep getting swept under the rug by the marketing machine and clones repeating their drivel because of the massive
market share VB has that nobody in their right mind would want to lose. Especially current authors in the VB space. It's in their
best interest not to have current VB devs jump ship to C#. It diminishes their income potential. Hardly possible to write a
non-biased view given that fact now, isn't it?
For you script kiddies, home hobbyists, and power secretaries who will be writing Word.Net Macros, go ahead and stick with VB. You
are the market MSFT is targeting with the tool anyway. Oh yea, I forgot you can more easily perform late binding all day long. As if
late binding is a good thing and there aren't better solutions to use instead, like designing an interface and early binding to
it...
To make my point about how easy it is for a good VB programmer to jump right into C#, how many of you VB6 programmers find it's just
as easy (or easier) to read the C# code snips and examples you find here as it is to read the VB.NET ones?
One more thing. The programmers that used to be VB'ers and are now C#'ers also told me they are happy to be out from under the
stigmata of being a 2nd class citizen because of their chosen tool.
Keep Smilin'
Ed Stegman
"mule" <Click here to reveal e-mail address> wrote in message news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Peter McMahon |
Hi Ed
I totally agree with you about your stance towards advanced VB developers
moving to C# instead of VB.NET. As I said in the article, C# has been
designed from scratch, so it doesn't have to bring anything bad along for
"compatibility reasons". For advanced programmers (people who've worked with
the WinAPI etc), language syntax isn't normally much of a barrier, so there
aren't any compelling reasons not to go to C# except for migrating VB6
applications (although it could be argued that the changes are so great in
VB.NET that you'd be better off rewrite the app, in C# at that).
However, for the not-so-advanced VB programmer, VB.NET is probably a better
move initially (I did say that once you've learned VB.NET, moving to C# is
almost painless because most things are done very similarly). This is
because your not-so-advanced VBer probably isn't comfortable with the
C++-like syntax, so they'd be more at home with VB.NET. Once they've
understood that basics of .NET development with VB.NET, they can easily move
over to C#.
As for readability of C# vs VB.NET samples, I personally don't have a
preference. However, if anything, I think newbies will find VB.NET samples
easier to read because its syntax is closer to written English than that of
C#.
The point you make about VB developers living under the stigma that they're
somehow not as good as other developers is very true though, and one of the
reasons I learnt C# was so that if the same kind of stigma develops (or is
carried across) to VB.NET, I can always label myself as a C# programmer.
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:e4KyakhgBHA.2264@tkmsftngp05...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Ed Stegman |
Well Peter, I wouldn't (and didn't) call working with the Win32 API *advanced* programming, although there are some parts that
you'll need to be not only advanced, but ingenious to get working from VB.
As VB5/6 only runs on the Win32 operating system, its pretty much a given in my eyes that if you can't use it, you aren't quite up
to speed for average competency. How could anybody write a half way decent front end (the target of VB dev) without at least knowing
SendMessage, RtlMoveMemory, and a handful of other easy enough to use API's that they can use to grab some perf or functionality not
available out of the box. I'm not asking them to be able to thunk down to the DirectX API's and code up Max Payne after all. Just
maybe use FindWindow() so they can stop multiple instances of their app when needed and pop the already loaded one to the top using
SetForgroundWindow(). Seems like normal competency to be able to do that, as it's a normal need for an application. Piggy backing a
ride on some other apps main thread before making the call, so your app actually does pop to the front instead of flashing the
toolbar button, I would consider advanced. Not difficult to do actually, but it would take an advanced person to realize it could be
done in the first place.
Is there some other O.S. that you think VB programmers should be programming against in order to consider themselves competent? I
don't consider being able to drag some controls onto a forms designer and hook them to a data control, or 20, being a competent
programmer. And if you want to tell me that you are shipping apps using only the out of the box functionality of VB, then I'm
telling you that you are shipping apps that aren't quite what they could be.
Anyway, all things said and done, you are really going to be better off learning both languages. And MC++ too.
But I still think newbies should learn C# first. That way they won't pick up any bad habits. I think VB drives people towards bad
habits. Somebody posted earlier here stating VB was good because it didn't enforce explicit typing, is a good example of this. Type
safety is paramount to a competent developer. It's also paramount to a newbie, they just don't know it yet. So every time I see
somebody state that weak typing is a good thing, I just move their name over to the "woefully mislead" side of the book, shake my
head, and hope I never have to work with them or on any code they ever wrote.
On migration of legacy VB apps. Why? I certainly wouldn't advocate re-writing in VB.net or C# if the app is already complete, or
even partially complete. If it's a web app and you just have to have the extra perf offered by ASP+, then that's another story.
As far as comfort with syntax, I guess the new guy really will find this line of VB:
If Not myObject Is Nothing OrElse IsNull( myOtherObject ) Then ...
much more comfortable than the C# equivalent:
if (myObject != null || myOtherObject == null) {...
because the VB version reads more like English. hehehe sure it does. The only reason you now understand what the VB line was trying
to say is because you read the C# one ;-)) And the distinction between null/nothing certainly won't confuse them now, will it? ;-))
BTW, how long did it take you to learn the C# operators? An hour? Tough barrier, that. <g>
Anyway, your article isn't all bad, even though I disagree with your reasoning. Some people really will do better learning VB.Net
then C#, just because MSFT told them they would. Strange how confidence in being able to do something often is the only difference
between getting it done or not. :-))
Keep Smilin'
Ed Stegman
"Peter McMahon" <Click here to reveal e-mail address> wrote in message news:##CzhMjgBHA.2144@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Peter McMahon |
Hi Ed
Point taken about the story of advanced and competent VB programmers, but
when I think of the 7 million VB developers who will potentially move to
VB.NET, I think you'd be quite lucky if 500 000 of those actually have a
working knowledge of the more important WinAPI calls. Those 500k might very
well be perfectly comfortable with C# almost straight away because they'll
probably at least be able to 'read' C/C++-style code, because they've had to
read the WinAPI docs, which give definitions & examples in C. Maybe I'm
right, maybe I'm wrong (or maybe there's no right or wrong), but I reackon
that for *most* VB developers, VB.NET is the better move.
I think getting into a huge argument about VB.NET vs C# is pretty silly in
any case, because even if the competent programmers make the VB.NET choice
initially, they'll probably end up learning C# anyway, because often online
resources list examples in either VB.NET or C# code, and not both, so at
least having a good working knowledge of both is essential.
As for the issue of type safety, I'm stand firmly in your camp on that
issue. IMHO, one of the major pitfalls of VB was that it didn't enforce
typed variables. Sure, typing takes a little bit more time than being lazy,
but sheesh it'll save you a lot of time in the long run.
Okay, you win with your example of VB.NET vs C# syntax, and the VB.NET
version there looks incredibly awkward, but I can think of plenty of other
examples where VB.NET looks a lot clearer than C# for the newbie who hasn't
programmed in either before.
As for my learning the C# operators, since I'd already had experience with
JavaScript, and to a limited extent Java and C++, I didn't have to learn
them ;-) I'd agree that for intermediate/experienced programmers, language
syntax isn't a huge issue, but for newbies, the Java/C++-style syntax can
look incredibly confusing. Parens, curly braces, vertical bars and operators
like != scare newbies, although I'd have to agree that they can make the
code a lot more elegant and easier to read than VB.NET code for non-newbies.
Anyway, thanks very much for your opinions, Ed. I'll probably write a
follow-up article, where I round up all the opposing opinions from yourself,
Peter Torr and the inevitable others (I'm surprised - Jonathan Allen hasn't
had a word on this yet ;-) and give the other side of the multi-faceted
coin, so to speak.
Cheers
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:ODtyY1jgBHA.1892@tkmsftngp04...
> Well Peter, I wouldn't (and didn't) call working with the Win32 API
*advanced* programming, although there are some parts that
[Original message clipped]
|
|
|
| |
|
| |
|
| |
| Peter Torr \(MS\) (VIP) |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:ODtyY1jgBHA.1892@tkmsftngp04...
[Original message clipped]
I would say that "getting results" is paramount to a newbie, _even if they
are incorrect_! There's a reason why almost every language tutorial starts
with "Hello, world" -- it's one of the easiest program to write, it gives
immediate feedback, and it can be incrementally extended in many ways.
How many people, when they buy a new computer game, actually spend the 5
minutes or half-hour it takes to read the manual from cover to cover, and
how many people just dive in straight away? Even if you don't know how to
play the game properly -- and maybe you'll read the manual at a later stage
to figure something out -- at least you get to see cool stuff right out of
the box.
There's also a difference between "code that doesn't use *explicit* types"
and "code that isn't type safe". For one thing, you can't write verifiable
code in .NET that is not type safe. For another, you under-estimate the
compiler.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| BobJ |
Peter,
You are absolutely right about the vast majority of programmers being
something less than professional and not caring that they are so.
Unfortunately, I seem to always get the gig to clean up after them! I could
eat for a thousand years if the spaghetti code was really spaghetti. We
can't fix it, but we can cry about it.
BobJ
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:#D35rqngBHA.2144@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
|
| |
|
|
|
|
| |
| Alfred C Thompson II |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:e4KyakhgBHA.2264@tkmsftngp05...
> Any competent (Read: Doesn't use data controls. Has used Win32 API.
Declares variables. Only uses Variants when absolutely
> necessary. Never leaves the runtime a chance for evil type coercion. <Add
to list here>) VB developer has only been dating it until
> something better showed up, and will be a much happier camper using C#.
As a competent (by your definition) VB Developer I disagree. While C# is a
very nice language and I do like it, it's not better then VB .NET. There are
pros and cons to both languages. They are different but I do not think it is
fair to call one absolutely better then the other.
> I've already taken 1/2 dozen VB6 programmers (good ones) and had them
writing productive code in less than 2 days using C#. Every
> one of them says it physically hurts to go back to VB6, and hurts even
worse just to look at VB.NET.
I go back and forth between the two daily. Often using both in the same day
and do not find it at all painful.
> C# doesn't have any baggage, and one of the primary concerns in the design
was to keep things consistent and at the same time
> prevent common mistakes that lead to bugs. It's much simpler to learn C#
than VB.Net, even for new programmers.
Taught many new programmers? (New being defined as no previous programming
experience) I have. It's what I do for a living these days. I believe that
VB .NET will be easier for totally new programmers then C# almost as much so
as VB 6 is over C++. They syntax is the key.
[Original message clipped]
Any author who can write a worthwhile VB .NET book can just as easily write
a good C# book. VB 6 book is of marginal use at best to a VB .NET learner
the VB authors have as much incentive to push C# as VB. Unless they really
think VB is better.
> One more thing. The programmers that used to be VB'ers and are now C#'ers
also told me they are happy to be out from under the
> stigmata of being a 2nd class citizen because of their chosen tool.
Oh, yeah, appeal to ego. Now there is a great reason to pick a programming
language.
|
|
|
| |
|
| |
|
| |
| Robert Chapman |
<snip>
For you script kiddies, home hobbyists, and power secretaries who will be
writing Word.Net Macros, go ahead and stick with VB. You are the market MSFT
is targeting with the tool anyway.
</snip>
I'm disappointed to see that VB bashing is still a popular sport with .NET,
even though all the languages write to IL at the end of the day.
Please don't assume that:
- VB is the only language in which newbie or talentless programmers can
write crappy applications
- all VB programmers are, or should only be, "script kiddies, home
hobbyists, and power secretaries"
Good programmers apply solid programming fundamentals to their work no
matter what language they work in, VB included.
Just my two cents worth.
--
Robert Chapman, MCSD
Manager Applications Development
prairieFyre Software Inc.
http://www.prairiefyre.com
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:e4KyakhgBHA.2264@tkmsftngp05...
[Original message clipped]
|
|
|
| |
|
| |
| |
| james |
We now have a new class of snob programmers, C# Snobs !
VB or VB.Net programmers can be as good or as bad as the programming habits
they learn or aquire. As you know bad programs can
be written in ANY language.
I for one like VB.Net and
the power it adds to VB. And the fact that it can afford even those
Power Secretaries the chance to use it , just points to the fact that
it is a language that can go as far as anyone cares to go with it.
Oh, there are newsgroups for C# users..............
james
(by the way, I like C++ too. I just like VB & VB.NET better )
"Robert Chapman" <Click here to reveal e-mail address> wrote in message
news:uPK11LlgBHA.2204@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Ed Stegman |
James,
inline
"james" <Click here to reveal e-mail address> wrote in message news:umIVJdlgBHA.1520@tkmsftngp02...
> We now have a new class of snob programmers, C# Snobs !
Resorting to name calling is a childish ploy used by those with nothing constructive to present for their side of the debate.
[Original message clipped]
Exactly my point. Especially the "learn or aquire". VB *fosters* bad programming habits, while other mainstream languages strive to
do just the opposite. If you are going to be learning to do anything, wouldn't you want to learn to do it as well as possible in the
first place? I find this more desirable than being led to believe I was, only to find out the hard way later that I ws mislead and
now need to relearn all over again? It's a hell of a lot harder to kick a habit than to obtain one.
[Original message clipped]
At least we agree on something here :-)) VB.NET is a major improvement over previous versions. And I find it nice that it is a tool
designed for a power secretary to use.
My post, however, was not to denigrate power secretaries or people just playing around programming simplistic widgets. It was in
direct response to somebody making a statement that VB was the best language for somebody to learn how program. I took the article
as being positioned towards people who were intent about becoming full-fledged serious developers, or who already are full-fledged
serious developers and wanting to know which .NET language they should move to from the current tool they've been using.
For these people, I disagree with the author.
[Original message clipped]
there. Nor is it intended to be. Get over it.
> Oh, there are newsgroups for C# users..............
And there are newsgroups for VB.Net users. What's your point? That I shouldn't have responded to a post made here in the first
place? Is this newsgroup reserved for VB enthusiasts, and any discenting point of view strongly discouraged?
Perhaps the original author shouldn't have posted his announcement here in the first place. What does language choice have to do
with a discussion forum titled "dotnet.framework"? Throw your barbs at the correct target.
[Original message clipped]
For everyday development of business apps I like VB better than C++ also. But that has no relevance on deciding which is a better
tool for me to use when comparing VB.NET and C#. C# != C++.
Keep Smilin'
Ed Stegman
|
|
|
| |
|
| |
| |
| Cali LaFollett |
[Original message clipped]
Ed,
Out of curiosity, what is the "intrinsic support" that VB.NET is lacking
that doesn't allow it do go as far as C#?
Cal
|
|
|
| |
|
| |
| |
| Ed Stegman |
For 1, A large portion of the native O.S. (Win32 API) uses unsigned types. VB doesn't support these. You can create one, but not use
it. A bit ridiculous considering VB only runs on Win32.
If you think you'll never need to use the Win32 API, take a look at the message count on dotnet.framework.interop.
Others can chime in with more. I'm late for an appt. Sorry.
Keep Smilin'
Ed Stegman
"Cali LaFollett" <Click here to reveal e-mail address> wrote in message news:#qDdUdqgBHA.2092@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Cali LaFollett |
> For 1, A large portion of the native O.S. (Win32 API) uses unsigned types.
VB doesn't support these. You can create one, but not use
[Original message clipped]
I agree that I wish that VB.NET natively supported Unsigned Types but I
haven't found an API yet that I couldn't use because of that fact. One
typically doesn't do a lot of math with the API params. Most are typically
handles and the like. Integer (formally known as Long in VB6) works just
fine. There are many instances of Low and High order functions out there to
mimic the VC++ Macros as well.
Also, many people do not realize that VB.NET can create unsafe code just as
C# can. The only difference is that the C# language syntax has a Pointer "*"
character to make life easier. All of the work is still handled by the
framework. VB.NET just taps the interop framework to do those "Fun things
with Pointers" ;-)
All in all, I still think there is a major stigma about VB, even in the .NET
world. I am not sure I like all of it (VB.NET) but I can honestly say that
there isn't anything C# can accomplish, results wise, that VB.NET can't.
And, without the hacks too! ;-) The down side is that there is an added
verbosity to the VB.NET side because everything is supposed to read like
English (Still scratch the top of my head on the English bit sometimes
though ;-) Just makes one go through a few more keyboards is all!
Don't get me wrong here. I am not trying to tell you that you don't have
legitimate points from what I have read so far, just trying to point out
that VB.NET != VB6. It is a pretty level playing field now. I see pros and
cons to both languages and have stated in other posts how I wish there was
something in the middle. The best of both worlds so to speak.
I personally like Delphi over C# or VB but the gigs are few and far between
and Borland is a bit shaky right now. I just doesn't seem like a solid long
term investment to me.
Anyways, I would be curious to hear of other items that don't quite allow
VB.NET to reach the same heights as C#.
--
Regards,
Cal
|
|
|
| |
|
| |
| |
| Dean Cleaver |
Cali,
I am one of Ed's converts to C# (not one of the 6 he dragged through,
another one who he badgered over ICQ). I would consider myself a good VB
programmer, but I can't say I was overly amused by VB.Net for several
reasons.
One is the lack of the unsigned types as Ed mentioned. Why not? Can't a VBer
handle unsigned data?
Second is the operator overloading. Sure, I don't even know what good it is.
Never used it. But I _CAN_ now. Isn't that cool? ;-) Actually, I can see the
uses. I haven't used it, but it's nice to know I have the option when and
where I need it.
But the real kicker?
It's the fact that I am learning SFA really. I personally consider that in
..Net, the language is about 10% of the issue. The framework makes up the
other 90%. And you have to learn that no matter what.
What I really like about C# is that it doesn't have the "left over baggage"
from VB. Like the added library (sorry - don't use VB.Net so can't think of
the name) which contains lots of functions that they couldn't "place" into
the framework classes. That I don't like.
Sure. I still have to hit F1 when I do a switch statement cause I forget the
syntax. And "for" messes with my head too. But I'll learn. Can't be that
hard.
Now if VB6 just wouldn't error at all those ";"s left at the end of each
line I would be fine...
Dino
"Cali LaFollett" <Click here to reveal e-mail address> wrote in message
news:#vJkpergBHA.1948@tkmsftngp02...
> > For 1, A large portion of the native O.S. (Win32 API) uses unsigned
types.
[Original message clipped]
|
|
|
| |
|
| |
| |
| Mike Maddux |
I'm a C++ programmer by training, so I'm more comfortable, naturally, with C#;
but the truth is I'll be happy to get to work in .NET and won't care one whit
whether I'm using VB.NET or C# syntax. The Developer Days that I attended was
done completely in VB.NET, which I had not even looked at, and I had no trouble
following the code. The lines that invoked the Framework were different from
the equivalent C# line only by the missing semi-colon.
Mike
In article <uU5as8ugBHA.1568@tkmsftngp07>, "Dean says...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Dean Cleaver |
Exactly. Learning those lines is 90% of the battle. Learning "for(int
i=0;i<10;i++)" is just a "chore as it were. Still, what I am finding is that
I don't know the "operation" of these things.
For i = 1 to 10
I know it goes from 1 to 10 then stops. As for the C# (well, C) version...
that I'm not so sure. So now I have to try to remember these facts in
addition to the syntax. Just takes a bit more thinking for now...
Dino
"Mike Maddux" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
> I'm a C++ programmer by training, so I'm more comfortable, naturally, with
C#;
> but the truth is I'll be happy to get to work in .NET and won't care one
whit
> whether I'm using VB.NET or C# syntax. The Developer Days that I attended
was
> done completely in VB.NET, which I had not even looked at, and I had no
trouble
> following the code. The lines that invoked the Framework were different
from
[Original message clipped]
|
|
|
| |
|
| |
| |
| Jash P. |
It is simpler to drive a Yugo than a Fomula 1 automobile. Why won't you
learn to drive differently if the final benefits are greater.
Once you've done it a few times, typing "for (int i = 0; i < 10; i++)"
couldn't take much more time than "for i =1 to 10", just as typing "i = i +
1" doesn't take much more time than "i++".
JP
"Dean Cleaver" <Click here to reveal e-mail address> wrote in message
news:#lPVP1zgBHA.2328@tkmsftngp04...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Dean Cleaver |
JP,
What I guess I was meaning is when I type
for (int i=1;i<10;i++)
Does it loop from 1 to 10? Or 1 to 9? _I_ don't know yet... won't take long
to figure out I guess, but after 8 or so years of VB, I _know_ that For i =
1 to 10 goes from 1 to 10 without thinking...
Dino
"Jash P." <Click here to reveal e-mail address> wrote in message
news:##49NZ2gBHA.1744@tkmsftngp03...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| mule |
"Dean Cleaver" <Click here to reveal e-mail address> wrote in message
<usbTkd3gBHA.2328@tkmsftngp04>...
[Original message clipped]
It exits when i is no longer < 10. That should be obvious.
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
| |
| |
| Dean Cleaver |
Yes... my point entirely.
For I = 1 to 10
Loops from 1 to 10.
for (int I = 1; I < 10; I++)
Loops from 1 to 9. Slightly confusing when coming over from VB.
Dino
"mule" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| mule |
"Dean Cleaver" <Click here to reveal e-mail address> wrote in message
<OdG1q#AhBHA.2100@tkmsftngp07>...
[Original message clipped]
for (int i = 1; i <= 10; i++)
is what you're after then. I don't see why a more flexible system
should be more confusing.
Tell me this, what is the value of i when exiting the for loop in
C#? Ah, this I know because I can see that i is no longer <= 10, and
I'm incrementing by 1, so it is 11.
What is the value of i when exiting in VB? Actually, it's also 11.
But that is a language implementation and not at all clear from the
logic of the code.
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
|
| |
|
| |
| Jash P. |
It is obvious to me that i starts with 1 and must remain less than 10. If
that is confusing to you, I don't know what to say!
Maybe, it'll be clearer to you if it's written:
for (int i = 1; i <= 9; I++)
JP
"Dean Cleaver" <Click here to reveal e-mail address> wrote in message
news:OdG1q#AhBHA.2100@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Dean Cleaver |
Yeah - it's not "confusing" in any way, it's just something I have to
"think" about... double check the < or <= etc...
Dino
"Jash P." <Click here to reveal e-mail address> wrote in message
news:uCueUOChBHA.2384@tkmsftngp03...
[Original message clipped]
|
|
|
| |
|
| |
|
|
|
|
|
|
| |
| Ed Stegman |
[Original message clipped]
O.K. Here's a simple tutorial that will help you understand it. Hopefully you'll never pause again when needing to write a loop.
:-))
Let's start with the VB For loop. Here's the declaration:
For i = 1 to 10
'do something here. With or without i.
Next
It's doing 3 things for you:
1. (Declaration) Declare counter. Happens only once, not every iteration.
For i = 1
2. (Conditional) Perform conditional check.
To 10
Hidden from you is the real code emitted, which is:
If ( i < 11) Then
'Do something interesting
4. (Action) Increment the counter. Also hidden from you, which is:
i++ [or ( i = i + 1) or (i += 1)]
After the first pass through the loop execution jumps back to #2.
Pretty simple. Because you VB guys know what it's doing under the hood, your mind fills in the blanks when you see it.
Now, let's look at the C# version. It's a bit different because C# is designed to be easier to learn. You don't have to guess what
is happening under the hood. It's all laid out nice and explicit for you. :-)) hehehe I couldn't resist!
It also gives you a lot more flexibility, but more on that later. Here's the same exact declaration the C# way:
for (int i = 1; i < 11; i ++)
{ //BEGIN
....
} //NEXT
<sidebar>
Because we are a zero based group of propeller heads, most C# programmers would have written the above like this:
for (int i = 0; i < 10; i ++)
Most of the time you are using a for loop you are looping through something and using the counter variable ( i ) as an indexer, and
because arrays in C# are 0 based, it's only natural to start at 0 with your counter. It also makes it much more readable to see the
10 in the conditional block. Your mind doesn't have to jump through any hoops to realize the loop will execute 10 times. Of course,
you can initialize i to anything you want.
The equivalent in VB would be
For i = 0 to 9. Bit of a stumbling block while you subtract 0 from 9 to realize that you are getting 10 iterations, but you quickly
get used to it.
</sidebar>
As you can see, there are the 3 distinct statement blocks, which are separated by semicolons. The same 3 VB creates for you under
the hood.
You may be looking at these now and saying to yourself, "Self, why is there a line terminator (semicolon) after the first two
statement blocks and not the action block? Don't all C# statements need to be terminated?" That's another lesson, but the simple
answer is no. Conditional statements (if statements) and looping statements don't end in line terminators.
I'll be surprised if all of you haven't already mentally mapped these statement blocks to the hidden code VB is generating that I
explained above. So, I'm not going to repeat the same set of 3 things that are happening. And I don't have to explain why it is more
explicit, you can see that for yourself. Instead I'll explain why this is more flexible, hence more powerful.
Here's the 3 main things to remember:
1. All 3 statements blocks are independent of each other.
2. All 3 statements blocks are optional.
3. These really are statement *blocks*, so you can include more than 1 statement in a block. Except the conditional block. But you
can test multiple conditions.
<warning>
Please don't run off and get all crazy seeing how many different cool things you can do in the loop declaration. Your code will be
hard to read and maintain. Always remember that it's better to write clear and understandable code that doesn't throw the reader
into a loop (pun intended) trying to figure out what the hell the code is doing.
</warning>
Let's start by finishing the mapping from VB. With VB you can specify the amount to increment the counter variable by using the Step
directive.
For i = 0 to 9 Step 2 ' increment i by 2 each iteration.
With C#, you just change the code in the action (the 3rd) block to achieve the same thing.
for (int i = 0; i < 10; i += 2)
An important point to understand is that an execution block really is just that. A block where you can execute code. It is not
restricted to just incrementing your counter variable. To place multiple statements in the action block (and the declaration block
too). Just separate them by commas.
for (int i = 0; i < 10; i++, Console.WriteLine(i), CallBetty())
This will increment i, write to the console, and call Betty *after* the execution of the loop. That is because the action block
executes after each iteration. We are calling Betty 10 times because we know she's just going to hang up the first 9 times when she
finds out who it is. ;-)
A for loop with nothing in any of the blocks: Referred to as an infinite loop.
for ( ; ; )
{
if (someCancelFlag == true)
break;
GetNextChunk( myWhoppingFile );
}
Because we didn't specify anything in the conditional block, it will keep spinning until it encounters a break statement.
This is a perfectly accepted and well used construct. It eliminates the need to have your code sprinkled by GoTo's, making it easier
to read and understand. All key things needed by a language designed to be easy to learn. :-)
Which reminds me, I didn't tell you what a break statement was. As used here, it's equal to VB's Exit For statement. Unlike the
hodgepodge of VB's Exit statements you have to learn, C# only has one keyword that is used to terminate a loop or conditional
statement. Why? Because C# is designed to be easier to learn. ;-) Consistency is important to facilitate learning and C# is all
about consistency.
There is also the "continue" statement that you can use in the body. It terminates execution of the current iteration of the loop.
In VB you would have to put a line label just above the Next statement at the bottom, then GoTo the line label from places in the
body in order to achieve the same thing. (Successfully resisting urge to point out how unstructured and harder to maintain the VB
code is in comparison...)
And there is always the return statement, which does the same thing as VB's Exit Sub and Exit Function statement.
Some Examples:
A for loop with multiple declarations:
for (int i = 0, j = someArray[0]; i < 10; i++)
//modify the array's value all you want, we've stashed it already
A for loop with multiple conditional tests:
for (int i = 0; (i < 10) & (GetUserOK()); i++)
The above only executes the code in the loop body if both tests are true. GetUserOK() is a method that returns a bool. C# only
allows you to do conditional (usually referred to as Boolean operations) on bools.
<sidebar>
To do a Boolean test on a non bool, like an int, (which by definition is a number, not a state of true nor false), you have to
compare the value of the int to something. The comparison will be a boolean result. It either compares or it doesn't.
e.g.
if (myInt) //fails.
if (myInt == 7) // compiles. myInt is equal to 7 (true) or it isn't (false).
if (myint = 7) // fails. Only one = (equals) sign was used. C# treats one equal sign as a directive to do an assignment. To do a
comparison instead of an assignment you use two equals signs. This is one of the changes from the C++ behavior. It prohibits you
from accidentally making an assignment when your intention was to do a comparison. C++ would have happily compiled if (myInt = 7),
then at runtime changed the value of myInt to 7. Very hard bug to track down. That's why you see C/C++ coders structuring their code
like this ( if 7 == myInt). If they inadvertently forget one of the equals signs, this variation won't compile, because you can't
assign a variable to a constant.
Some of you coming from C/C++ (if you even bothered to read this far) may have noticed that I only used one & symbol, and are
thinking this was a mistake on my part. It's not. This is different in C# also. And it's related to the beginning of this sidebar.
Unlike C/C++, C# doesn't do logical operations on integer data types, nor does it do bitwise operations on bools. With C/C++ you had
to use && to signify a logical operation. Otherwise if you used only one & (ampersand) you got a bitwise op. The same kind of bugs
you could get by doing assignment instead of conditional test, like above, were easy to do with logical vs. bitwise.
There is also a hole in the C/C++ situation. Having only 1 logical operative, the designers decided to always short circuit logical
operations. (Just the opposite of legacy VB, where the designers decided to never short circuit). Well, C# has fixed this problem.
(So has VB.NET). Now && and || (logical AND, logical OR) short circuit, while & and | (*new for C#* logical AND, logical OR) do not.
(The && and || directives are illegal when used with integer data types. You can't short circuit a bitwise op) The & and | (bitwise
AND, bitwise OR) still work like they always did when applied to integer data types.
The loop (waaay up there somewhere) will always execute the GetUserOK() method in the conditional. No matter the value of i. Of
course, the loop body won't execute if i isn't less than 10. We don't always do what the user wants now, do we?
</sidebar>
Man, I should have labeled that SIDE TRACKED! <g>
A loop with only a conditional test. This is a variation on the GetNextChunk example above. Decide for yourself which is easier to
read. Either one is valid.
for ( ; (someCancelFlag = false); )
GetNextChunk( myWhoppingFile );
If you have declared an iterator, you don't have to increment it in the action block:
//take 10 snapshots of the screen.
//start at bottom and snap every 64 lines of resolution.
int y = Screen.CurrentScreen.Bounds.Y;
for (int i = 0; i < 10; y--)
{
if (y % 64) // % == VB's Mod operator. Same in C/C++, Java, JScript
{
//take a snapshot using y as starting point
i++
}
}
Obviously not the way you'd really want to do this, but it's the only thing I could contrive to show the possibility. The only good
thing about this piss poor example is that it serves the outstanding purpose of reminding me why it would be a really bad idea for
me to write a book. :-)) My wife says I have a voice for writing, but she's never seen my writing, just my awful attempts at
singing.
Oh, one last thing. Any variable's declared in the declaration area and the body of the loop are only in scope inside the loop.
Keep Smilin'
Ed Stegman
|
|
|
| |
|
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:#2vnVD6gBHA.1176@tkmsftngp07...
[Original message clipped]
Just to be picky, they're not blocks and they don't even contain statements;
they are statement-expression-lists. You can do stuff like call methods,
increment variables, etc. and chain multiple expression-statements together
with commas, but you can't, for example, have a try-catch block, or declare
a new variable.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Ed Stegman |
Yea. I'm not great at terminology.
Hopefully nobody now thinks they can do try/catch there. I used the
terminology to make it easier for the VB guy to understand that all 3 parts
really are separate functional entities. My bad.
What do you mean by "can't create a new variable"? In this sample, aren't i
and j new variables? Of course they have a limited scope, but they sure work
like variables for me. It's VB that makes you create the variables first, not
C#.
public void Main( string[] args){
for (int i = 0 , j = 5; ;)
....
}
Keep Smilin'
Ed Stegman
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:eujYZp$gBHA.1176@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:#mtdPOChBHA.772@tkmsftngp04...
> What do you mean by "can't create a new variable"?
You can do it in the initialiser section, but not the other two sections.
For the interested, see:
ms-help://MS.VSCC/MS.MSDNVS/csspec/html/vclrfcsharpspec_8_8_3.htm
and:
ms-help://MS.VSCC/MS.MSDNVS/csspec/html/vclrfcsharpspec_8_6.htm
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
|
|
|
|
|
|
| |
| Jash P. |
.... and that pesky "_" character for line continuance.
"Dean Cleaver" <Click here to reveal e-mail address> wrote in message
news:uU5as8ugBHA.1568@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
| |
|
|
| |
| Ed Stegman |
Hi Cali, I think we are in agreement about a lot of things. Perhaps this will tip the scales to get you and others to realize that
C# is a better choice for most professional developers.
Out of curiosity, what cons do you have about C#?
Besides responding to your post, I'm going to show another reason why C# is a better choice for professional developers. The C#
evangelists haven't caught on that this is an important reason to prefer it, hence you haven't heard much along those lines, but
it's true that
C# is more productive than VB.NET
In reply to part of your post:
Yes, you can substitute int for a uint for some API calls, and *generally* you will be safe doing so. But this isn't always true.
And when it fails to be true, you'll only know at run time when it blows up. And it'll happen on some user's machine where you have
no hope to debug or even know what GPF'd or why. So, knowing this, why take the risk when you don't have to anymore? That bug can't
happen if you use C#. You don't even have to think about ever happening. So yes, here's a place VB can't go. Glossing over the fact
doesn't make VB go there.
Do you think it a coincidence that VB also doesn't have shift operators? Would have been easy enough to implement both unsigned
integer types, signed bytes, and shift operators, considering the runtime supports them, wouldn't ya think? I haven't heard of any
other languages not being able to get them in there. And the VB team has a budget about 10 times that of the other teams, and it's
not a manpower issue either. You can bet the VB pm's have an open book wrt that. To much at stake not too.
They aren't implemented because they are considered too dangerous for the target user. Period. That means you could do things with
them that MSFT doesn't want you doing. That means you've now got lowered capabilities because you've been restricted from doing
something. All because of potential support costs to a vendor, not because it isn't doable. The key word here is restricted. As in
less functional. As in less productive.
Yea, you can fake shift ops with some custom math functions. But shifting bits that way isn't always 100% correct, and orders of
magnitude slower. And when that ol' most significant bit is being treated as a sign bit because you don't have unsigned integers, it
gets even worse. So you've got to add overflow checking, compensation and what not. Major overhead. Using C#, it's this tough: >>.
Hardly a level playing field, wouldn't you say? As a result, VB.NET *is* less productive than C#. You are now losing productivity
while designing/testing your crufted up fake shift operator functions, because you have to devise work arounds to the language's
lack of what most programmers would consider to be a standard operation. The last I heard, universities are still introducing shift
operators in CS101... Of course, universities don't have to pay support personnel when a student abuses them....
In VB6 at least you had pointers and could invoke RtlMoveMemory() to help speed things up. In VB.NET you don't even have pointers
anymore. Why doesn't VB.Net have pointers? Well, I don't have the exact quote, but somebody at MSFT has publicly stated that they
found out that some VB guys were using them to hack vtables, and it scared the crap out of them, so they took them out. So now
you'll have to work even harder to try and get around VB's lack of support for things. Another loss in productivity using VB
compared to using C#.
It amazes me how people can keep hearing and repeating that "it's a level playing ground now", but when presented with evidence that
it isn't, they keep on proclaiming, and believing it is. "Tell the lie long enough, often enough, loud enough, and they'll
believe!"[1] They keep glossing over things with statements like; "Well, I seldom need to do that. Or, for the apps I'm doing I can
do something else instead that is almost as good. Or, it's not as easy or won't run as fast, but at least I can find a way to get
the end result." Why subject yourself to even being in that position when you don't have to anymore? Every time you find yourself
saying something like the above, stop and realize that you now have another, more productive choice.
The ridiculous justifications remind me of myself when I only had a choice to buy either a convertible with a missing top, or a
conventional 4 door car. I said "Well it hardly rains here in CA, and most of the time I park in a garage anyway. Besides, I'll
fix_it_next_year!" I bought the convertible. I was real happy with it too. Until the first time it rained. But I took my lumps and
kept liking the car. Then I got stuck in a snow storm for two days while on vacation. Put the whole thing in a different perspective
in a hurry.
Now, what if I had been given 3 choices? Broken rag top convertible. Standard hard top. Hard top convertible? A real no-brainer. Get
the hard top convertible. I can drive around protected from the elements and when I want to take the top off and feel the wind in my
hair, it's cake to do so. The best of both worlds.
VB.NET is less productive than C#. Period.
If you have to go spend an hour (or days) tracking down some way to make up for a lack of native support, then you aren't being as
productive as you could be. Which is where a majority of VB6 programmers found themselves when trying to do simple things such as
improve the speed of a string sort, or subclass the message pump so they could catch an ALT+TAB key press. Stepping off a cliff less
safe than C++ when doing so BTW. Sure, it's not that bad with VB.NET, but the intrinsic problem of not fully supporting basic data
types and operators still exists, and for some things, it will be that bad.
For those of you still unconvinced, here's a link (down a few lines) to a recent article by Eric Gunnerson showing how to take a
standard 24bpp color bitmap and transform it into a gray scale image. It's done in C#. Can you do so as productively using VB.NET ?
Before you start, write down on a piece of paper how long you think it'll take you. In fact, do that now. Your a pro, you should be
able to estimate something this simple.
Got it written down? Good! Now see how long it actually takes you. And no, you can't use Bitmap.GetPixel and SetPixel. Your babies
will have beards before doing it that way would ever finish running. Eric even admits as much in his article. Also, don't bother
trying to PInvoke the Win32 GetPixel() function. That function has always been a toad too. The runtime one is probably just a
wrapper around it anyway. No wonder it's a toad.
Please post your solution and how long it took you. Be honest. Even though it'll hurt terribly to admit it.
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp11152001.asp>
O.K., While the emotionally attached are busy pulling their hair out trying to go anywhere they want to using VB, I'll toss out
another issue ;-))
Another thing you are locked out from when using VB is a result of VB not understanding case. There are lots of libraries out there,
written in case sensitive languages, where the only difference between different types and functions are a matter of case. You may
blow this off as bad design on the library author's part, but nonetheless, they exist in plentitude, and it's a place VB.NET can't
go that C# can.
For these, the only option I'm aware of if you are using VB.NET is to create a C# or MC++ module that wraps them up nice and VB'ish
for you. Having to do so is another loss in productivity. And a maintenance PITA. Can you deny this? Can you show me something where
you'd have to do it in VB because C# couldn't deal with it? It's hard to even think to *contrive* an example, let alone find a real
world one.
As a morsel to you VB guys, there are places that C# can't go either.
[1] My apologies for not knowing the source of this quote.
Keep Smilin'
Ed Stegman
"Cali LaFollett" <Click here to reveal e-mail address> wrote in message news:#vJkpergBHA.1948@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:#tUv#ytgBHA.2248@tkmsftngp02...
[Original message clipped]
That depends on what you are doing.
What if you are writing an application that integrates tightly with Office
or IE? Visual Basic would be a better choice here because its ability to
omit function parameters (and, dare I say it, late bind) is a huge
productivity win. Pop quiz: what's the minimum number of lines required to
print the title of Microsoft's home page using each language? (JScript is a
clear winner here at only 5 lines, but I'll keep that out of the
conversation for now).
Scenarios where one wants to automatically bind and unbind to a dynamically
changing event source is also cleaner in Visual Basic, thanks to its
declarative event binding syntax. One could also claim that With blocks
improve productivity. Maybe only slightly, but they do.
Your statement above is a sweeping generalisation. For some situations, it
is undoubtedly true. For others, it is patently false.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Ed Stegman |
Peter,
Inline...
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message news:#axh9N0gBHA.2264@tkmsftngp05...
[Original message clipped]
I guess you aren't aware that C# can easily call functions with optioanal args by using Missing.Value?
Also, optional args are anathema to good design. The issues wrt optional args are numerous. That's why C# uses overloading instead.
It's part of the overall concept of the C# platform, which is to encourage you to create better, more solid, less buggy, code.
[Original message clipped]
Yes, it's more productive to late bind using VB at this time. I wouldn't call it a huge productivity win though. For one thing, most
places I've seen late binding used was because of a faulty design in the first place. There is no good reason to design something
using late binding if you are building all of the components. Late binding, although the only option in some scenarios, should be
your last choice of a way to accomplish a task. There is an enourmous list of the downsides to late binding. Here's a few, in no
particular order:
1. Slow. Late bound code is very, very slow.
2. Errors only show up at runtime. The compiler can't be your friend. This drives up the cost of development tremendously.
3. A simple typo of a name can bring your program down. Again, at runtime. After the client has it installed.
4. Intellisense doesn't work. You've just disabled the single biggest productivity booster created in the last 5 years.
5. If the interface is changed by a new rev of the object you are late binding to, (not a good thing, but it happens all too often),
you may still be able to load your object, have the user spend a considerable amount of their valuable time entering data, only to
see it all disappear when you blow up calling that late bound method that changed. Ever spend a morning working on something only to
have it disappear in a puff of smoke?
The most widely place I've seen late binding used was in VB apps where somebody was late binding to Word or Excel. Well, you don't
have to late bind to them. You can now easily tlbexp those interfaces and early bind to them using VB, C# or your tool of choice.
So, your *enormous* advantage is really a red herring. The vast majority of apps that will be written, if done properly, will not be
using late binding. And why does everybody keep inferring that C# can't do late binding? It can. But your code starts to look like
VB when you do so. Verbose. Pot calling the kettle black?
[Original message clipped]
You've lost me here??? Care to clarify?
If you are going to start using line counts to justify VB (or any lang for that matter) as being the more productive tool, you've
slipped off the deep end. C would be the big winner here. You can damn near write a whole program in one line if you are masochistic
enough.
[Original message clipped]
Yep. Takes two line using C# and only 1 in VB. (C#: 1 to unbind former, and 1 to bind current)
One thing I haven't looked at in VB.NET that was a major PITA in VB6 was that (because of the way VB automagically wires up event
sinks) you had to declare any references to an object you wanted to sink events for at the top of your module (module scope) using
the With Events directive. This made it impossible to declare objects on the fly and sink events for them. (Also forced you to have
higher exposure than absolutely needed too).
You couldn't, for example, have a collection of objects where an object in the collection would raise an event, unless you declared
all the objects at design time with module scope. With C# I can easily create an object on the fly in a method, and tell it where to
send any events. This is a very common need when you have a hierarchical object model (like Word or Excel).
For example, my Car collection has a Wheel collection that has a LugNut collection. I can add LugNuts on the fly and assign the
LugNut.Loosening event delegate to my
LugNut_Loosening() event sink. Now, anytime a LugNut starts to loosen, it can signal me directly. I could also assign the Loosening
event to sinks in the Car collection, and the Wheel collection too, should I desire to do that. And each assignment is 1 whole line
of code.
This was undoable in VB without some nasty work arounds which usually involved creating "messaging" classes, which led you down the
circular reference path, and also destroyed any chance of a clean encapsulation of design, yat, yata, yata. Not very productive.
Does VB.NET continue with this same restriction, or has that been solved? Would you post an example if you get a chance?
[Original message clipped]
I'm a big fan of With blocks. I'd also bet 8 to 5 the next rev of C# has them. :-))
There is a downside to them that can cost you much more than the initial time savings though. That is when your app is in the
maintenance / revision stage. It's impossible (at least for now) to search and find in the code all the occurrences of a usage of a
property or method for an object.
For example, you need to find everywhere that the Foo.Name property was invoked, yet your code looks like the below, and you've got
a 500,000 line program to wade through.
With Foo
....
.Name = "Bar"
....
End With
A cool addition to the Find and the Find in Files dialogs would be to have a "Search in With blocks" options :-)))
[Original message clipped]
I don't have the patent on falsity or generilasations, as you infer. My statement was no more, and no less, generalized then all the
ones being made stating that VB is more productive, or easier to learn, or the correct choice for, or beginners should ...
In fact, I backed up my statements with real world examples of why I think a professional developer will be more productive using
C#. I haven't seen any of my reasons denied or disproved, only minor chipping at the edges of it. And of course I'm not stupid
enough to think that C# will be more productive for everybody. Some people just won't be able to do curly braces, and others will
have an ingrained emotional fear of any language other than the one they first learned, and others just don't have any inclination
to learn anything anymore. For thse people, it wouldn't be productive at all to put them in a C# environment.
How can anybody justify writing something less than a large number of pages to inform others what their best decision will be?
They'll have to generalize now, won't they? If they try and go into enough detail not to be doing a generaliztion, it'll be a book
and not an article, and nobody will read it. Proverbial rock and a hard place. The author is in the hardplace, and we are all
throwing rocks ;-)
Nothing is black and white. For some VB will be a better choice. For others, C# will be. For others, something entirely
non-Microsoft will be. But I still think that, given equal skillsets between C# and VB.NET, the C# programmer will be more
productive in the long run, especially for the typical applications being written by professional programmers. You'll really start
to realize that during the debug and maintenance stages of development, if you haven't already realized it during the coding stages.
Others, of course will disagree with my assessment, and they have every right to do so. If your disagreement is done out of a
logical extension of coherent thought, and not some emotional attachment to VB, I'll be inclined to agree with you too. I've already
done so in the course of this thread as a point of proof.
I'm just dating C# until something better comes along anyway :-)))
Keep Smilin'
Ed Stegman
[Original message clipped]
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:O6ms0T2gBHA.2260@tkmsftngp07...
[Original message clipped]
Cool. For some reason, your mail client is wrapping lines at some
non-standard width. Can you consider changing it to 78 or 76? Makes it hard
to read otherwise. Thanks.
> > What if you are writing an application that integrates tightly with
Office
[Original message clipped]
I am fully aware of that; the point is though that they're no longer
missing! (Missing <==> not there, not specified, etc.). Some Office methods
have upwards of 10 parameters, when for the most part you only need to use
one or two of them. Specifying Missing.Value a dozen times is not very
productive.
> Also, optional args are anathema to good design.
Ah ha! I was expecting you to say this :-).
Earlier you made an argument that, whilst case-sensitive libraries may be
badly designed, they still exist and therefore a case-insensitive language
like VB was less than ideal. Well, object models with optional arguments may
be badly designed, but they still exist and therefore... he he he :-)
> There is an enourmous list of the downsides to late binding.
Oh, I agree it has its downsides, but the point is for a large class of
applications, getting it done quickly is better than getting it done "right"
(again, I'm talking more of the casual developer or the one-off hacker here
than the professional programmer of large-scale applications)
> You can now easily tlbexp those interfaces and early bind to them using
VB,
> C# or your tool of choice.
True, but there are issues with this, mostly because (i) type libraries
don't always tell the truth, and (ii) interop isn't perfect. Sometimes you
have to late bind.
> And why does everybody keep inferring that C# can't do late binding? It
can.
Sure, anyone can call through Reflection, but that doesn't mean the
*language* supports late binding. I can write a C program that uses
IDispatch to late bind to Office, but does that mean that C is a late-bound
*language*? Of course not; it merely has access to a library that can do the
dirty work for it.
[Original message clipped]
It's a simple question -- you want to find out, programmatically, what the
title of Microsoft's home page is. This is of course rather contrived, but
many real-world apps to HTML scraping of one form or the other. It takes
about 5 lines of JS and about 10 lines of VB, but most of that is generated
by Visual Studio automatically (Sub / End Sub, etc).
[Original message clipped]
I posited this as an example to counter your "how do you convert a bitmap
into greyscale" question. Now, I could be wrong, but I think COM interop is
more important to most enterprise developers than image manipulation. And
LOC is certainly one measure of productivity, although it may not be the
best.
> > Scenarios where one wants to automatically bind and unbind to a
dynamically
[Original message clipped]
I think you miss the point. In VB, you do stuff like (pseudo code):
Public WithEvents MyButton As Button
Sub MyClick(...) Handles MyButton.Click
Sub MyDoubleClick(...) Handles MyButton.DoubleClick
Sub MyFooFoo(...) Handles MyButton.FooFoo
You can have as many events as you want. Now you lets say that somebody
changes the reference stored in MyButton from its original value to a new
value. This may be done by your code, or it may be done by some other random
code. VB will automatically unbind all those events from the old instance,
and re-bind them to the new instance, so that the events automatically start
firing from the new instance. You may consider this bad design, but it is
useful. It's possible to do this in C# by manually tracking everything the
same way the VB compiler does, but it's not a productive use of your time.
VB's design-time will also list all the possible events for you in the event
drop-down, which is a time saver in and of itself.
[Original message clipped]
VB can also add and remove events programmatically, pretty much the same way
C# does -- something akin to:
AddHandler MyButton.Click, AddressOf MyHandlerFunction
RemoveHandler MyButton.Click, AddressOf MyOtherHandlerFunction
[Original message clipped]
That's actually a really neat idea!
[Original message clipped]
As I keep pointing out, not all developers are professional. But I'll drop
that for the time being as I'm sure we both understand each other and I'm
getting boring. This discussion is implicitly about "profesional
developers".
My objection is still that it's all about the scenarios. They say the three
most important things about real estate are location, location, location.
Well, it could be said that the three most important things about language
choice are scenario, scenario, scenario (that's an off-hand comment, so
there's no need to pick it apart ;-) ). Would you write a complier in
Prolog? Probably not. Would you write an expert system in VB? Probably not.
Would you customise Office by writing an assembly in C#? Probably not.
> The author is in the hardplace, and we are all throwing rocks ;-)
Glad I'm not an author... ;-)
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Ed Stegman |
Sorry about the line length. I've changed it. Like I said, I'm a newbie at
this newsgroup stuff.
Doesn't your reader word wrap? It never occurred to me that somebody could be
using such a dinosaur of a tool that it couldn't wrap text. Especially when
MSFT is giving away free ones. Or is there something wrong with LookOut
Express I should be aware of?
My responses are inline.
I've snipped some of your responses in the interest of readability. It also
gives me the unabashed pleasure of deleting your good points without
responding to them and hoping nobody notices ;-)) I call that tit-for-tat BTW.
<g>
[Original message clipped]
Oh come on! I'm going to pick a tool because out of the 50 million or so
libraries out there, in one of them some idiot made a couple of functions with
10 parameters, most of them optional, and one tool doesn't force me to hit
CTRL-V 7 times, thereby saving me what? 3 seconds?
Furthermore, I'm not going to have the bugs you are. Because the C# compiler
makes sure that I didn't inadvertantly forget to supply an argument. I'll hit
CTRL-V 50 times for that kind of comfort. Because while you are busy trying to
track down this all-to-common error, I'll be on the beach having a beer and
judging swim suits.
[Original message clipped]
You missed my point. Understandable, since it followed my debunking of your
well worded, yet misleading, statement inferring that C# couldn't do optional
args. My point in saying that optional args are bad was to point out that VB
fosters bad design, and your rah, rah about how wonderful it was to write such
fragile code where the compiler is not designed to help you proves my point.
Not only does it foster bad design and coding practices, you are proud of it
and call it a plus! For what? 3 seconds time saving when initially calling the
method.
C# has the [ClsComplient] attribute you can put in your code and it won't let
you do bad things like create public functions that only differ in case. Of
course this was only added so less powerful tools like VB could come and play.
[Original message clipped]
You think *quick* is better than "right" for a *large* group of VB developers.
That statement alone should send any serious VB developer running to another
tool. You've more than proven my point (for the 2nd time) that the true market
segment targeted for VB is NOT the professional developer. Any of those that
you do manage to get is just icing on the cake. Don't get me wrong. Were it my
product bringing in 4 billion U.S. per annum from casual developers and
one-off hackers, I'd be making damn sure they could shoot theirselves in the
foot, leg, stomach, and heart as easily and as quickly as needed too.
[Original message clipped]
And the percentages of this happening are what?
And being a professional developer with an idl compiler at hand and able to
define your own tlib and use that instead is impossible? Most advanced VB
developers have been doing that for years now just to be able to use some of
the Win32 API. I've probably got 30 or 40 hand crufted ones floating around
here somewhere, and there's probably 1,000's you can find out there on the
WWW. It's not rocket science.
And so what if you decide to be foolish and late bind instead. As I've said,
you can still get the job done with C#. All you've convinced me of here is
(again) that you'd choose fast and wrong over stable and correct.
Let's look at this from a different perspective, because I can see all those
people thinking you might be talking about Word or another app in the Office
family. Those are the primary apps getting automated by late binding today.
Even though the shelves aren't exactly overflowing with Office automated apps,
there are people who do nothing else, and others that occaisionally do it. So,
I'll take the Microsoft perspective here:
Hmmm, I've bet the company on .NET. Office is still my flagship product.
Brings in more money than anthing else. Guess I'll only make sure it works
with VB.NET.... Get real. If any of the Office type libs are munged, or
interop doesn't work with them, none of you guys will be going home until we
have something that works. Period. It wouldn't surprise me if the next
versions of Office shipped with their own CCW's. So stop scaring people. We'll
be early binding to Office apps. Nuff said.
[Original message clipped]
And your point is? Another red herring! What you should have said is that the
C# language doesn't support *anything*. Because it doesn't. It has NO built in
functionality. No separate component you have to ship. No baggage. It *is* the
extension of the CLR and BCL. How does VB late bind BTW? What's going on under
the hood? Reflection? (I don't know, just asking because it interests me.)
Everything you do with C# is through access to a library to do it's dirty work
for it. It comes with the .NET SDK. So what? I call that a win. Everybody
knows that having a base class library is a win. Is it a loss that VB.NET also
has the BCL doing it's dirty work 90% of the time? Nope.
And I reiterate. Properly designed, less than 1% of the apps out there need to
use late binding.
[Original message clipped]
And, you've done a famous job of changing the subject. The subject that I
posted the image manipulation question about was a false statement made that
"with VB you can do anything". I think not, in the context of doing anything
meaning sometime this week with normal effort, as you can with C#. I know that
truly enterprising people can do anything with nothing, given enough time, and
VB.NET is hardly nothing.
The grayscale thing was to show you couldn't "just do anything you want".
Knowing the capabilities of some VB programmers, I really do expect one of
them to solve it. But, the lack of any solutions in a timely manner has
already proven my point that C# is a much more productive environment. You
don't have to stop what you are doing and go muck around for hours or days to
get something accomplished.
I'm still waiting for your solution, and your honest time of how long it took
you to repro the 10 minute C# job BTW. You've got the whole MS damage control
team at your disposal don't you? ;-)) Just kidding. I'm aware you are more
than capable of handling your own damage control, or working out a solution
with VB. Your quick intelligence is what makes it so fun to debate with you.
Oh, and why do you infer that VB is more productive to do COM interop than C#?
Not the bogus optional argument theory again I hope? And why is the
dotnet.framework.interop newsgroup primarily C# stuff? There must be at least
25,000 VB programmers out there for every 1 C# programmer? Interesting
question, isn't it? Given the lopsided numbers in user base, I'd expect to see
a C# question/answer about once every two weeks and thousands of VB
question/answers in between.
(silently, off screen, you can hear the chairs scrape and scurrying sounds of
hundreds of VB devs rushing to post to dotnet.framework.interop in order to
bolster Peter's position and create the good emotional consistency feeling we
all love to have)
[Original message clipped]
And in C# it looks like this:
public Button MyButton
MyButton.Click += new EventHandler(this.MyClick);
MyButton.DoubleClick += new EventHandler(this.MyDoubleClick);
MyButton.FooFoo += new EventHandler(this.FooFoo);
void MyClick(...)
void MyDoubleClick(...)
void FooFoo(...)
Like I said, takes 2 lines of code to VB's 1 per event.
[Original message clipped]
So can C#. So what?
[Original message clipped]
Talk about contrived! Oh yea, that's solid code. I do that all day long. I'm
always switching around my control references.
[Original message clipped]
Oh, even better. Let some outside force go changing around your control
references. You professional developers out there getting this? This is the VB
vision!
[Original message clipped]
As I think you've surmised by now, I find no advantage in having some easy way
to do bad design. And you know it smacks of bad design in the worst way. You
would never ship an app with such a design woud you?
Also, are you sure it's the VB *compiler* tracking this? How can the VB
compiler track this if you can do it dynamically at runtime? You are IL at
that point, and the "random code" in your bad design could be from something
your other bad design late bound to.
[Original message clipped]
You can do the same thing in C# from the "events" property sheet. Although I
do have issues with it and hope they change it before RTM.
Don't get me wrong, I love this feature in VB.NET, although I have what I
consider to be a better version of it that fits more nicely into the VS design
paradigm. Here's a link to some flame I wrote just recently about it. See, I
KNEW there was something we agree on.
http://discuss.develop.com/archives/wa.exe?A2=ind0112B&L=DOTNET&P=R3270
[Original message clipped]
Well, I'm certainly happy to see they threw you this bone. It's been sorely
needed for about forever. Obviously it's just a wrapper over the exact same
event delegate assignment we do with C#, only VB'ized. :-)
Looking at it raises another question. Can you assign, errr. add, the handler
to a completely different object?
For example:
Dim Foo as someObject
AddHandler MyButton.Click, AddressOf Foo.Bar
[Original message clipped]
Whoa! What a slick maneuver! Let me try that:
Would you bungee jump with a rubberband? Probably not. Would you slide down a
5 meter razor blade into a pool of salt and alcohol? Probably not. Would you
kiss Osama bin Laden on the lips? Probably not. Would you use VB to program
anything besides a customization of Office? Probably not.
hehehe I just love it when you set yourself up like that.
Of course I would use C# to do the customization module. Early bound to the
office tlib. And VB is suitable for more uses than customizing office. VB will
be harder to learn, and you won't be as productive, and chances are you'll be
writing flaky, fragile code without even realizing it, and it'll be harder to
debug, but you can still get the job done with it in spite of all that.
Unless you need a jagged array that is. (One more can't do. Anybody counting?)
I've got lots more things VB can't do. I'll trickle them out a little at a
time. Makes denial easier for most people, and I really don't want to loosen
their cocoon too much.
Keep Smilin'
Ed Stegman
|
|
|
| |
|
|
| |
| |
| Jonathan Allen |
> Doesn't your reader word wrap? It never occurred to me that somebody could
be
> using such a dinosaur of a tool that it couldn't wrap text. Especially
when
[Original message clipped]
When I hit Reply to one of your earlier posts, the quotes look terrible.
About every other line is missing the > mark.
I have experimented with turning off wrapping in Outlook Express, but I have
not found a way to get the quotes just right. Maybe if it had a re-wrap
command like other news readers it could do it, but as it stands it just
sucks in that mode.
--
Jonathan Allen
..Net Wish List: http://jonathan.cloverlink.com
|
|
|
| |
|
| |
|
| |
| Peter Torr \(MS\) (VIP) |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:Ovc4ta7gBHA.2212@tkmsftngp03...
> Doesn't your reader word wrap?
Sure, Outlook Express word wraps. The problem is that it word-wraps at x
number of columns (where x varies with the width of the window) but then
your text has hard-coded newlines at every yth column (where x != y). So the
text looks like this:
aaaaaaaaaaaaaaaaaaaaa<wrap>
aaaaaaa<crlf>
bbbbbbbbbbbbbbbbbbb<wrap>
bbbbbb<crlf>
cccccccccccccccccccccccc<wrap>
cccccccc<crlf>
etc. Outlook XP has a neat feature where it removes these extra newlines in
mail messages, but Outlook Express doesn't have it. Thanks for fixing it up
though. Much easier to read.
> My responses are inline.
Yup. As you've noted, many of my points are small and quite insignificant in
a large-scale application. They're also insignificant if you're an
experienced developer. But there's that old phrase "to nickel and dime"
someone out of all their money, and those nickels and dimes add up quickly
if you haven't got much to start with.
[Original message clipped]
It saved *you* 3 seconds, because you're an experienced programmer, you know
what missing parameters are, you know what System.Missing.Value is and how
to use it, etc. But if you're just starting out, and you're trying to use
Office, you look at the VBA documentation and maybe some of the samples, and
they just pass in the arguments that are needed (maybe they even use named
parameters) and you've got no idea that in reality you have to pass in all
this other junk. So the compiler tells you "no overload takes 2 parameters"
or whatever the error is, and you realise that you have to pass in all the
parameters, but what do you put in their place? null would seem to be the
obvious choice, but that doesn't work a lot of the time. So you search the
documentation, read a book, post a message to a newsgroup, or whatever, and
you find out that you should use Missing.Value. But how long did this take?
Maybe half an hour, maybe a couple of days (don't tell me you've never
wasted days on a problem that ended up being simple once you knew how <g>).
The point here is that the VB developer just got on with their job! Maybe
they know all about missing parameters and how they work; maybe they don't.
But the cool thing is that it gives you the choice. You want to early bind
and type everything? Be my guest. You want to late bind to everything
because you're in a hurry? Go right ahead sir. You have no idea what late
binding or missing parameters are and you just want to do your job and go
home at 5pm to see your family? Not a problem.
The developer who early binds and specifies all the parameters (regardless
of what language they are using) will likely have less bugs and fewer
maintenance headaches, to be sure, but at least you can choose to do it "the
bad way" if that's what makes sense. Of course this then boils down to the
argument that the beginning user doesn't even know they're doing it "the bad
way", thus the language helps them form bad habbits, but that's neither here
nor there. If the programmer really cares about doing things "the right way"
then they will likely read the reference manual (which does tell you late
binding is slow, etc.), maybe a book on good coding practices (like "Code
Complete"), etc.
[Original message clipped]
Well I don't drink alcohol, so that's a point in my favour ;-)
[Original message clipped]
"Bad design" or "design for a different purpose"? Having optional arguments
on you nuclear reactor OM is probably a bad idea, but having them on your
word processor OM is probably not, given that most people want to stick with
the (perfectly reasonable) defaults. But this is going nowhere.
> C# has the [ClsComplient] attribute you can put in your code and it won't
let
> you do bad things like create public functions that only differ in case.
Of
> course this was only added so less powerful tools like VB could come and
play.
The CLS specifies a specific set of features that can be used by component
and library vendors so that their products can be used by the largest
possible number of customers. It has nothing to do with "less powerful"
tools -- VB has useful constructs that are disallowed by the CLS, as does
JScript. It's just a way to make the "level playing field" even leveler. :-)
[Original message clipped]
No, I said it is better for a large group of applications -- NOT VB
developers. Consider this simple program:
#include <stdio.h>
void main(void)
{
char name[20];
printf("What is your name?\n");
scanf("%s", name);
printf("Hello, %s\n", name);
}
Is this program "right"? Of course not. There's a buffer overrun waiting to
happen, it doesn't account for the fact that I might enter both my first and
last names, and so on. But if I only need it to handle the case where a user
will enter their first name, and their name is less than 20 characters, it
"works". And it's much quicker than checking for buffer overruns or allowing
the user to specify both first and last names, etc. And, it's not written in
VB, C#, or even JScript ;-)
Disclaimer so nobody sues me: Buffer overruns are very serious things and
you should never actually write code like this. You should also never drive
over the speed limit or run with scissors.
> That statement alone should send any serious VB developer running to
another
> tool. You've more than proven my point (for the 2nd time) that the true
market
> segment targeted for VB is NOT the professional developer.
No, I'm saying that VB is a good tool for non-professionals. That does not
equate to saying VB is not a good tool for professionals.
[Original message clipped]
Well, Internet Explorer for one thing ;-)
[Original message clipped]
See my point about missing arguments above. Many people *have* spent days
mucking around trying to figure out how to call IE or Office with a missing
argument from C#. You have only proven that for some things, and for some
users, C# is more productive. I wholeheartedly agree with you here. I merely
try to show that for some other things, and for some other users, VB is more
productive.
> I'm still waiting for your solution, and your honest time of how long it
took
> you to repro the 10 minute C# job BTW. You've got the whole MS damage
control
> team at your disposal don't you? ;-)) Just kidding.
I know ;-). I haven't even looked at the code because, quite frankly, I
don't care how long it takes to convert a bitmap to greyscale in ANY
language, until I (or one of my customers) really needs to do that. But just
to make things clear:
I don't speak for the VB team, and I don't speak for the C# team -- they
probably both want to see me dead <g>. I think C# is a great language (guess
what JScript .NET is written in?) and I think Visual Basic is a great
language too (my team also produces both VBScript and VBA). Personally, I
use JScript whenever I can, because I love it and because it's the right
thing to do for my customers. Whenever I write C#, I forget the semi-colons
or the parentheses after a new expression or to specify that something is
public. Whenever I write VB, I use // for comments.
My whole reason for being in this thread (which is taking up far too much
time!) is to represent the little guy, the dev doing important but not
mission-critical stuff, the network admin writing logon scripts for her
users, the power user writing macros for their Excel spreadsheet, and so on.
> Oh, and why do you infer that VB is more productive to do COM interop than
C#?
Sorry, I should have said OLE Automation. Everyone knows that Managed
Extensions to C++ is best for raw COM interop. :-)
[Original message clipped]
Consider, for example, some code that is bound to the click event of a
button. If you have a dynamic UI (similar to the Office UI), that button
might be on a toolbar, or it might be on a menu. These are different
instances of the Button class, and it would be the UI portion of your code
(not the button-handling portion of your code) that set the current
reference. Here's some pseudo-code:
Class FileOperations
Dim WithEvents NewDocumentButton as Button
Dim WithEvents OpenDocumentButton as Button
' etc.
Sub NewDocumentClick Handles NewDocumentButton.Click
' Whatever
End Sub
Sub OpenDocumentClick Handles OpenDocumentButton.Click
' Whatever
End Sub
Class MyApp
This class represents all the file operations you can perform through the
UI. Now, somewhere else in your app you allow the user to customise the
menus and toolbars. If they drag the File Open button off the toolbar, you
set FileOperations.OpenDocumentButton to null and the event will never fire.
Later on they decide to add the button back again, and you set
FileOperations.OpenDocumentButton to be a new Button. Events magically get
hooked up. Later on, they move the button off the toolbar and onto the menu.
You replace FileOperations.OpenDocumentButton with a new instance of a
special MenuButton that is a subclass of Button, and again, events magically
get hooked up.
The UI customisation code doesn't need to know which (or how many) events
are hooked up to each button, and the event handling code doesn't need to
know who is changing the instance (or when). You might find this simplistic
example to exemplify horribly bad design, but it works.
Another example would be if your newsgroup reader allowed you to write
custom code to filter new posts. You might write a single function,
something like:
Sub NewPost Handles Post.Arrived
If (Post.From = "Peter Torr") Then
Post.DeletePermanently()
End If
End Sub
And the instance stored in the 'Post' variable changes over time, because
the news reader updates it with each new Post object as it arrives. Your
macro code knows nothing about this, but everything "just works" the way you
want it to. Obviously there are ways of doing this that don't rely on
events, but this is a popular way of doing things.
> As I think you've surmised by now, I find no advantage in having some easy
way
> to do bad design. And you know it smacks of bad design in the worst way.
You
> would never ship an app with such a design woud you?
Actually, we encourage our customers to ship such designs. VBA and VSA are
predicated on this kind of eventing model. It makes perfect sense for their
end users.
[Original message clipped]
The compiler generates properties for the event sources, and those
properties do the binding and unbinding as necessary. Search
http://www.deja.com/ if you want more info on this; there have been
discussions about it in the past and the last thing this post needs is to
get any longer ;-)
> Looking at it raises another question. Can you assign, errr. add, the
handler
[Original message clipped]
You should be able to, although I haven't tried.
[Original message clipped]
I think you're being a little unfair here. I was not trying to "set you up"
in the same way you have set the person up by using ridiculous examples
followed by a legitimate one (I am sure there is a technical term for this
but I can't think of it right now). I believe all my examples were
legitimate, because...
> Of course I would use C# to do the customization module.
....this is clearly not an ideal solution in many situations. The correct
answer was of course to use VBA -- it's built right into the product (and,
by the way, it will early bind to Office if you want it to <g>). Sure, some
times you have to resort to an external DLL, but for the vast majority of
cases, a VBA macro will suffice.
This is now getting further and further off topic ;-)
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Jonathan Allen |
> etc. Outlook XP has a neat feature where it removes these extra newlines
in
> mail messages, but Outlook Express doesn't have it.
Any idea when they are going to add a news reader to Outlook?
--
Jonathan Allen
..Net Wish List: http://jonathan.cloverlink.com
|
|
|
| |
|
|
| |
|
| |
| Peter McMahon |
> Well, Internet Explorer for one thing ;-)
This has absolutely nothing to do with the topic at hand, but since you're
on the inside, Peter, do you have any idea when a 'pure' .NET version of the
IE browser control will be released? A year? Two years?
[Original message clipped]
Another tangent - I have this feeling you've had to defend JScript.NET
against VB and C# within MS as well, and that's why you've got the 5-liner
for grabbing the title of microsoft.com at the ready? True or false? ;-)
[Original message clipped]
Sheesh, if you didn't use JScript yourself and the word got out... in fact,
we don't even want to go there, suffice to say every argument you made for
JScript in this monster thread would be voided ;-)
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:eup5KlChBHA.2156@tkmsftngp05...
[Original message clipped]
Since it has nothing to do with the topic at hand, I can conveniently not
answer that question ;-)
Sorry.
[Original message clipped]
It's hardly the kind of code you need to keep handy for emergencies; it only
takes a matter of seconds to write something that trivial. Besides,
print("Hello world")
is a much nicer example.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
|
|
| |
| alpine |
On Thu, 13 Dec 2001 12:18:12 -0800, "Peter Torr \(MS\)"
<Click here to reveal e-mail address> wrote:
[Original message clipped]
<snip>
Peter, you do a GREAT job of making the point for migrating to C#!
;-)
The fact that VB.Net makes it exceedingly easy to write *really bad*
code should start alarm bells ringing for any current VB devs with
half a lick of sense. There is a lot of marketing-speak around
talking about how VB.Net is now a "first class" language but anything
that goes out of it's way to make doing the "bad" thing easier than
doing things "correctly" is a long way from first class. It may be
good for hobbyists and lazy "programmers" but it isn't a language for
professionals.
It is true that previous versions of VB also fostered bad practices
and bad design but, there wasn't ever a good alternative that offered
reasonably RAD middle ground. Now that there *is* a great alternative
(C#), there isn't any reason for anyone who calls him/herself a
programmer to waste a single second with a "tricycle" language like
VB.Net.
Bryan
____________________________________________________________
New Vision Software "When the going gets weird,"
Bryan Stafford "the weird turn pro."
Click here to reveal e-mail address Hunter S. Thompson -
Microsoft MVP-Visual Basic Fear and Loathing in LasVegas
|
|
|
| |
|
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"alpine" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
How so? But don't bother answering that; this thread has gone on for too
long anyway.
[Original message clipped]
Option Explicit and Option Strict make it illegal to do many of these
*really bad* [sic] things in VB. It's easy to turn off these features if you
want to Do The Right Thing(TM).
It's been said before, and I'm sure it will be said again: bad (or lazy or
inexperienced) developers can write bad code in any language.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
|
|
| |
| Ed Stegman |
Peter, I think we've beat the crap out of this, and it's been really fun :-))
Here's my overall summation of the picture (in 3rd person):
Ed's position and arguments are from the perspective of a professional
developer. He views the language choice like this (MC++, JScript, etc. are
valid choices too, but this is about the VB vs. C# choice):
C#:
For the professional developer, or the beginner whose intention is to become a
full time professional developer.
VB.NET
For everybody else.
Peter's position and arguments have all been made in defense of, and from the
perspective of, what Ed considers as "everybody else". He views the language
choice like this:
C#:
For the professional developer.
VB.NET
For everybody else.
I've seen nothing to indicate otherwise. JScript, et. al, excluded. Peter has
done a great job in raising awareness of the values of those other tools. But
this isn't about those.
If you check inline below, I've debunked your optional argument red herring
yet again, and also added another thing that you just_can't_do with VB.NET. It
hoists you by your own petard too. ;-)
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:OagzfNBhBHA.2280@tkmsftngp03...
[Original message clipped]
Bunk.
Of course this escaped you because you are used to working using very bad
methodologies, such as late binding, (which are encouraged by scripting
languages and VB), and Intellisense doesn't work when you do.
If you early bind, as soon as you type the first left parens this little ol'
tool called Intellisense pops up and shows you a complete list of arguments
and all the overloads for that method. I've already killed the "won't be able
to early bind" red herring in an earlier thread, so don't try tossing that out
again...
<here's another thing VB.NET can't do>
If you write your code using C# you can put XML comments for your method and
each arg and the return value, and tips, and so on. Anybody calling your
method gets these popped up in the intellisense.
Another major productivity win for C# and the professional programmer. Not
having those in VB is just exactly the prolonged nightmare that awaits the
VB.NET dev described bys your scenario above.
Again, this is more proof that VB.NET is targetted at the non-professional.
Non-pro's don't comment code. The internal discussion at MSFT went like this
(my guess):
"VB.NET doesn't need this. Our main user base doesn't comment code or early
bind. We'll maybe toss it into v.next as a bone to those who haven't already
woken up and switched to C#. *If*, they scream loudly enough, and *if* we've
got no other reason we can sell them on for upgrading."
BTW, knickels and dimes do add up. I've given a couple of rolls worth of both
as reasons why C# is better for the professional developer, and also why C# is
easier to learn.
Hey, look! I'm still sitting on the beach judging bathing suits and you are
still slaving away with your inferior design, and toolset that encourages
inferior design, try to handle all your support calls.<g>
To even go further, because I like 'ad nauseaum' sometimes. Especially when
I'm on the easy end of it ;-))
Let's say you were under such a rock as to not have heard of Missing.Value,
although it will be used in *every* pertinent C# sample you see, as it is the
*only* way to pass a missing arg. Being a professional C# dev, you would have
at least looked at one example of something in C# wouldn't you?
So, you if didn't even do that, you'll only have to learn it once. If you
waste hours to find out how to do something simple, (which is going to happen
in any language, no matter how good you are), you certainly aren't going to
waste hours learning it again. <snide comment about becoming pointy haired
mgr. instead of programmer deleted. too dangerous that it may have been
misconstrued to indicate other party, when it wasn't intented that way.>
[Original message clipped]
Then they aren't_a_professional_programmer, and you are correct. They are
using the right tool. VB.NET is for the non-professional. It's the world's
premier tool for the non-professional. We are in violent agreement about that!
:-))
[Original message clipped]
That's it, bury your head in the sand. Another fine example of the responses
to every issue brought up as to why C# is more productive than VB.NET. Nobody
really wants to admit it because it undermines their established belief system
that VB is the most productive tool in general. But, here's what's going to
happen when your customer does decide they need that image converted:
C# programmer:
Just do it.
VB.NET programmer:
Option 1. Find some C# programmer to just do it for me. Include C# module in
distrib package. Write all the documentation, distribution, references, etc.
so we can successfully integrate, maintain, manage, ship, test the C# module.
Option 2. Spend hours or days trying to figure out how to do it in VB. Come up
with half-assed hack that runs twice as slow (or worse), is less robust and
hard to maintain. Double the testing time allotment as this is non-standard
stuff.
The thing here is that the grayscale thing was just *1* small example. It took
me all of 2 minutes to come up with it. There are thousands of other small
examples that people could come up with given a little thought.
Why should the professional subject themselves to being caught in this
position when there is an alternative? Especially when the alternative takes
nothing and adds lots of knickes and dimes of good stuff?
[Original message clipped]
Yes, and you've done a fantastic job of raising my awareness of the legitimate
needs of these people. I honestly had not been including these groups much in
my considerations of anything prior to Peter's article and this thread. They
are a very important group of people in the IT industry, and their needs are
too.
<snipped another long example of truly bad unmaintainable design..>
[Original message clipped]
Yep, this did stray a bit, but it was relevant. You've proven yet again that
the correct tool for the job is not VB.NET. <g>
I have a question. Once office gets .NET'ized, won't you be able to just write
native C# right there inside an office macro? After all, any managed language
should be able to, not just VBA anymore.
Advantage? C# or VB? Nope. All programmers win.
Kills 100% of the arguments about anything to do with automation of Office,
doesn't it?
This is a good thing :-)) But I stray too. This isn't, nor ever was, about
Office automation.
Keep Smilin'
Ed Stegman
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:#fPO4rDhBHA.1568@tkmsftngp07...
> Peter, I think we've beat the crap out of this, and it's been really fun
:-))
Indeed. I'm replying for the last time. Really!
[Original message clipped]
I'm sorry I've had to post yet again but I feel I have to say this in case
someone in the press stumbles across this thread and starts quoting it
(believe me, it happens. Ever read Wired magazine?):
I have never spoken for Microsoft in this thread, and this is not the
opinion of Microsoft. It's also not a complete characterisation of my
personal opinion, but in the interests of killing this thread, I'll let it
go.
> I have a question. Once office gets .NET'ized, won't you be able to just
write
> native C# right there inside an office macro? After all, any managed
language
> should be able to, not just VBA anymore.
That's undecided. VSA (the merging of VBA and Active Script) currently only
supports VB .NET and JScript .NET. C# is a common request for future
releases, and obviously we're taking this into account, but I can't make any
promises. I also can't speak for Office or what their future plans are
regarding customisation. The myth that everyone at Microsoft knows what
everyone else is doing is just that -- a myth!
You should post to the dotnet.vsa group if you have more questions about
this kind of thing.
Peter "never talk about Windows 9x security on a newsgroup" Torr.
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Peter McMahon |
> Indeed. I'm replying for the last time. Really!
Thanks very much for your comments, Peter. I've thoroughly enjoyed your
animated debate(s) with Ed, and they've definitely given me a better
perspective on the issues at hand. I really appreciate the time that both of
you have taken, and if the time I've spent on this thread is anything to
judge by, then both of you must've spent a good 20+ hours composing
elaborate (good thing) replies. Thanks!
To the rest of you who also gave constructive input, thanks as well. To
Jacob Grass and Cali LaFollet [for solving Ed's image manipulator
'challenge'] - all I can say is, "You guys are good." :-)
If I don't post to any of you until then, Merry Christmas and Happy 2002!
Cheers
Peter
--
Peter "I can flatter just as much as Peter Torr" McMahon ;-)
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
[Original message clipped]
|
|
|
| |
|
| |
| |
| Cali LaFollett |
[Original message clipped]
Thanks Peter, it has been a pleasure to read what I have so far. I think I
will take it slow Sat. morning and read through this thread a little better.
Unfortunately, I have had to skip much of the content as I was running out
of time. ;-) That's a good thing though!
> If I don't post to any of you until then, Merry Christmas and Happy 2002!
Same to you and yours! Looking forward to having you post again!
Cal
|
|
|
| |
|
| |
|
|
|
|
| |
| Mike Fleischauer |
>>I think you're being a little unfair here. I was not trying to "set you
up"
[Original message clipped]
Correct term or not, what he is doing is baiting.
That asside, im not completely sure why you are even bothering with this
conversation anymore, although it has been interesting to read. I could
potentially give 1000 scenarios where one language is more proficient then
another. Flipping back and forth between examples really will prove
nothing. Then again, day to day, I probrably use six or so different.
Dim myVar as Int; // Oops, semi colon and wrong comment.
myFunction(&myVar); // and again, doh, passed by ref
What I wouldnt give for the language that merges all the aspects together,
that I take from each language and put it into one!
One final thing! If you are on the JScrip.NET team, that means that you are
probrably partially responsible for JScript 1.3??? Now, there is a language
ive used out of need, and need alone! Version's support different methods
massively between IE versions, especially the array functions.
Also...
if( myVar = undefined) then ....
under some versions works, on others you get the error...
undefined is undefined.
This, although looking funny, is I suppose just another one of those
annoyances, but:
var undefined = undefined;
Abosolutly should not work!!! Although it does... hell, its the first line
of way to many of my scripts. I just pray to something, that JS.NET is much
much much better!
Sorry, felt like venting!
Mike
|
|
|
| |
|
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Mike Fleischauer" <Click here to reveal e-mail address> wrote in message
news:OFeGyLWiBHA.2260@tkmsftngp07...
[Original message clipped]
You're right that anyone can come up with an example of where one language
is "better" than another, but it actually did prove a point.
Ed initially made the claim that C# is more productive than VB, without
giving any qualifications to that statement. I simply had to show one
example of a problem that was solved more productively in VB than C# to
disprove this claim. Ed then qualified his statement, made a lot of good
points to back up his argument, and we both agreed with each other (more or
less) in the end.
If somebody says "All apples are red", you only have to show them one green
apple to disprove that claim. It doesn't matter if they show you 100 or 1
million red apples, and it doesn't matter if you can also show them a yellow
(or purple or blue) apple -- a single non-red apple is all you need to
disprove the claim that all apples are red.
> One final thing! If you are on the JScrip.NET team, that means that you
are
> probrably partially responsible for JScript 1.3???
No; there is no such thing as JScript 1.3. You are thinking of JavaScript,
which is Netscape's implementation. JavaScript 1.3 was probably about the
same as JScript 3, which was before my time.
[Original message clipped]
I don't quite understand why you think this is a bad thing -- we added new
features in new versions of the language. Isn't that what people want? ;-).
If you are talking about differences between the DOM of Netscape Navigator
and Internet Explorer, our team has nothing at all to do with that.
[Original message clipped]
You probably meant ==, not =, but anyways, the undefined keyword only became
part of the language in JScript 5.5 (ECMAScript Edition 3, JavaScript 1.5 or
perhaps earlier). Before that, you had to use:
if (typeof(myVar) == "undefined")
[Original message clipped]
Why should it not work? You declare a variable named "undefined". It's
initial value is the undefined value. You assign the value of the
"undefined" variable (which is the undefined value) to itself. This is
exactly the same as:
var undefined
so I don't know why people go to the added effort of assigning undefined
back to itself, but whatever. It works, so people do it. Maybe some
cross-browser, back-compat issue.
[Original message clipped]
Well, JScript .NET is backwards compatible with JScript 5.x, so that still
works. But yes, it's a much much better language now.
> Sorry, felt like venting!
Don't we all sometimes? :-)
Happy Holidays,
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
|
|
|
|
|
| |
| Peter McMahon |
> How can anybody justify writing something less than a large number of
pages to inform others what > their best decision will be?
> They'll have to generalize now, won't they? If they try and go into enough
detail not to be doing
[Original message clipped]
Yeah, and I have this really bad feeling that no matter what I put into my
version 2 article on the subject I'm still going to have a few camps of
people who vehemently disagree with parts of what I've said.
Basically the purpose of the original article was simply to inform people
new to .NET. It wasn't a lame flame-bait article claiming that "VB.NET is
king and everything else sucks", which is bound to incite years of bitter
infighting on the newsgroups. In fact, it's not even aimed at the very
people that would climb into a flame war to defend their language of choice.
It's aimed at people new to .NET, for the simple reason that since I
launched dotnet.za.net (http://www.dotnet.za.net), I've had quite a few
readers tell me things like this: "I'm an MCP in Visual Basic and I'd like
to try out this .NET stuff. What do you think's a good choice for me?" or
"I've never programmed before, but I heard that .NET is 'the next big
thing', so I thought this would be a good time to get into the marketplace.
What language do you reackon I should go do a course on?" Instead of just
catering for the complete newbie and the relatively experienced VB
programmer, I decided I'd try and give *general* advice to the other 'main'
groups as well (former ASP/JScript developers; former C++ developers; former
Delphi/Java/Perl/Python etc developers). In fact, I think for most of the
article's target audience this whole thread would be pointless.
Before I get set to write the 2nd edition, I'd like to get your opinion on
the following, Ed:
1. What do you recommend experienced/component VB developers go for, and
briefly, why?
2. What do you recommend experienced/component C++ developers go for, and
briefly, why?
3. What do you recommend complete programming newbies go for, and briefly,
why?
4. Do you agree that even if someone makes the 'wrong' choice initially,
switching to C#/VB.NET a little later is almost a trivial matter?
5. What are your definitive comments on Peter (Torr)'s assertion that
JScript.NET is a good choice for people who just want to get things done in
..NET (people like sysadmins etc) and are only going to be using the code
once or twice, so it doesn't matter what it looks like?
6. I have a feeling you'll agree with me here ;-), but would you agree that
Delphi programmers would do well to choose C#?
Any other comments on the matter that you'd like me to consider?
Cheers
Peter
|
|
|
| |
|
| |
| |
| Ed Stegman |
Peter, I got a couple of hours sleep, and it bothered me that I left you
hanging. So I banged this out. Hope it even resembles coherency. I'm getting
some coffee, cold pizza and going back to bed. Have fun, and let me know how
many times I contradict myself :-))
The rest is inline..
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:egXj2k6gBHA.2172@tkmsftngp05...
snip some of my old drivel..
[Original message clipped]
That's the life of an author isn't it? Don't ever let it bother you. Take the
constructive stuff and learn from it.
[Original message clipped]
I never took it as flame bait. I'm sure you feel your summations were true. I
responded because I simply don't agree with them.
I want people to not listen to the party line and to actually investigate and
think about things for themselves. I know that 95% of the people are
followers, and a large portion of the remaining 5% just don't have the time to
do that, and they will end up following the party line anyway. So be it. But
maybe, just maybe, somebody has read this thread and divorced themselves from
the emotional attachment, the safety net of being like everybody else, and
decided to see for themselves that C# *is* a very reachable and easy to learn
language. Also that it is very productive and they may find themselves in a
better financial position in the future because they decided to spend a few
days to get up to speed on it.
I see C# getting stuck in right along with the C++ stigmata of difficulty, and
it's no more fair than the stigmata good VB programmers have had dumped on
them. C# != C++. I can't emphasize that enough.
Somebody, sorry, I forget who, said they wanted a language between C# and VB.
Get my point? There is nowhere between the two. Unless they want typeless
programming AND pointers? hehehe
[Original message clipped]
You are correct. People badly need some guidence wrt these issues.
Unfortunately, it's not as clear cut a decision as it first appears. The
options are now so much greater. It's no longer VB or C++ as the two main
decisions, and there are many, many factors involved in which language is more
suitable for an individual. A lot of these factors have nothing to do with the
quality of a language or how productive you can be in it. They are more
questions of your goals, as Peter Torr has so elequently shown us.
[Original message clipped]
I disagree completely. This thread has explored much more than the pisssing
contest you usually see when people debate about the virtues of their favorite
language. (Read: typical religous bloodbath flame wars.:)
All of it is grist for the mill, and you were 100% correct to include
JScript/Delphi/etc.. people into your sphere of interested parties. Although I
expect a version of Perl and Python to be running on .NET, and JScript isn't
dead by a long shot, MC++, C# and VB may be something these people would be
happy doing too. If they won't be, I hope at least they've had a few good
laughs :-))
[Original message clipped]
Man, I can't do anything briefly. Briefly is what got you in trouble in the
first place. ;-))
This will be the largest reply, simply because my take on this is the most
controversial and also the hottest topic.
Remember, I'm speaking of competent professional developers. This does not
include the average person who is a developer, but hasn't reached a level of
professional competency. This also does not include junior programmers still
learning VB.Even if they are competent for their level and experience. They
should finish learning it before moving on to anything else.
I think that for any professional programmer to grow s/he should try and learn
a new language at least every 2 years. Every year would be better, but most
people aren't up to that. Otherwise, what you end up with is somebody saying
they have 10 years experience, when what they really have is 1 year experience
for 10 straight years. This is reason enough for any experienced VB dev to go
after C#.
It's not like they'll have to start all over learning to program. To a
competent programmer, an algorithm is an algorithm, is an algorithm. They'll
have to learn the BCL (as will all devs using .NET), so that's a push. Most of
them already can read C++ to the extent needed to decipher Win32 help files
and examples, so the syntax isn't going to take more than a few hours, and the
F1 key is always there. They'll spend a bit more time to learn the different
semantics of the looping and case constructs, but again that is trivial.
So far, it doesn't look like much of a barrier, and it's very doable. Many of
them won't take it any further, and will be successful and happy campers.
Others will want to stretch out and keep learning. They'll attempt to grok
pointers a bit at a time until they get it. Some people will never get it.
Some C++ people never get pointers, and they end up moving on to another
language. It's not unusual. I think you are born with the inherent ability to
grok pointers or you aren't. It doesn't make you stupid if you struggle with
it. It means you are better at something else.
But the beauty of C# is that the people that don't get pointers, or don't want
to, can still be very productive in it. Just like they are in VB today. (C#
isn't about pointers.)
And they'll have become better programmers for the exposure to a new language,
new concepts, and tearing down of false barriers they never knew were there. I
don't see any downside in this scenario.
It should also be easy (if maybe somewhat painful for me, although not for
others) to jump over and use VB.NET. It's not like you can avoid seeing it. A
lot of samples, help files and certainly posts to newsgroups are full of both.
Usually side by side. They'll pick it up by osmosis. That's a good thing. If
they find themselves needing a gig and it's VB.NET or nothing, they'll be able
to easily wade in and get the job done. You know that.
If a person is finding themselves already stressed by having to learn so much
new stuff, then they should quit programming. It's never going to end. Believe
me. I've been doing this since well before the PC was invented, and it's even
more true today than it used to be. But, they still need to work and it's hard
to go asking for a 100k $ year entry level position doing something else, so
they'll need to pick a language to. For these people, my advice is to map it
as straight across as possible. And pick a specialty like WinForms or
WebForms, or middle tier components. Focus on the new tools to get that
vertical job done using as much existing knowledge as the framework will let
you. If you are more comfortable with ADO, then tlbimp the sucker, and use all
the old methods and manually stuff your data forms and manually stuff changes
back to the server as you've always done. Whatever gets the job done and
doesn't get you fired.
So you see, it more of a "what's the current needs and future goals" than
what's the right lang. Peter Torr has already show why non-serious programmers
and one-off hacks should use VB.NET. I agree completely with his assessment. I
also threw in the power secretaries. They're people too!
Also, here's how I see things:
Tricycle: VB - jump on and go. Just don't go too fast. And turn at your own
peril.
Bicycle: C# - Takes a couple days to get balance. Can go faster, but not THAT
fast.
Drag Bike: C++ . Better have your shit together or you are gonna crash. At the
best you'll bleed only a little. Very few learn to ride really well, and it
takes years to do so. The rest are faking it.
Missile: Assy. Nuff said.
It's time for competent tricycle riders to get on the bicycle. They've had
plenty of time to grow out of the tricycle. No matter how many times you get
them a bigger tricycle, it'll still be a tricycle.
[Original message clipped]
If they are true petal to the metal or the kind of people that love a good
challenge, they'll probably be happier in MC++. I've already explained in
another post why most C++ coders will be unhappy with VB.NET. and will prefer
C#. Most of your C++ application devs will migrate there once they see the
benefits. Here's an interesting take from one of the best out there:
http://sellsbrothers.com/spout/#know.net
This group of people should also be looking at learning a new language. And
don't laugh, there is a big market for JScript now and will be for quite some
time. They could do theirselves a favor to learn it. Or Perl. But, it's really
not easy to expect somebody making top $$ to take a pay cut just to learn
another language. And JScripters just don't come close to the salary potential
of a good C++ developer. The ones that a move to JScript or Perl will be good
for are those who's primary goal isn't money, and who like to shake things up.
There are more people out there like this than you'd think. I'm digging deeper
into JScript next year myself, although my primary goal *is* money. I just
won't be actively seeking full time JScript type jobs, although it's about
impossible to avoid using no matter where you work. The browser is truly
everywhere.
[Original message clipped]
dedication and energy it takes to become a true professional developer, and is
only interested in getting a few credits for some CS elective, then VB. They
can get their pile of crap up and running and not care if it's working right
or not. Also, I don't want any of these people using C# because someday I'll
probably have to fix their mess. No thank you.
For serious newbies, C#. It's easier to learn than VB. Period. I've pointed
out numerous reasons to back that up. VB was only easier to learn when
compared to C/C++. I don't consider getting a pile of crap to launch learning
anything.
VB doesn't read like English no matter what people say. Any grammar teacher I
ever had would flunk me out of school for any 1 line of VB tortured grammar.
(It would be the second time every one of them flunked me too!)
A very large portion of the world are not English speaking for their native
language. Would you consider it easy to learn to program if the language you
were learning on was some half tokenized, half bastardized version of
Portuguese? I'll bet the Portuguese people out there wouldn't even want to do
that. VB is not easier than C#, nor will they be better programmers for having
learned VB first. They will be better programmers for having learned C# first.
It's the difference in the philosophy of the two products.
They won't be duped into learning bad habits that will be hard to break. C#
fosters good habits better than any language I've seen in my life.
No offense, but, in general, the average C# programmer they'll be working
with will be much better than the average VB programmer they'll be working
with. And before you go getting all hot and bothered about that statement,
realize that it's NOT because C# programmers are so smart, or VB programmers
are so dumb. It's because there are so many VB programmers with no interest in
being a good programmer that the numbers are against them. Quality of
workmates is important when you are learning.
[Original message clipped]
Yes. Obviously. But in reality, whatever choice people make now they'll be
stuck with to a certain degree. It's human nature. Once they make the choice
they will grow legs like a centiped to hold up their decision. It will be very
difficult, if not impossible to change their mind, or convince them they blew
it. That's why we always have, and always will have language wars, O.S. wars,
etc. People have to put in a hell of a lot of life force to fully grok a
language, learn an O.S., etc. Then you ask them to admit it was all for
nothing, or only for a bit, and they will do anything not to admit that to
themselves. No way their self esteem could take the blow. I still know a
couple of people who only write assy. at home. Higher level langs came out
just after they learned it, but no way could they make the move. You get the
picture. Besides, there really isn't a "wrong" language. They all can
manipulate bits one way or another.
Better to ask the question: "If somebody chose VB or C# today, and in the
future an opportunity came to learn the other while working on a project,
could they jump over and do it, and still be productive enough to justify it?
I'd say yes to that too. And this is the category most competent devs fall
into today, and the most likely scenario they will encounter too.
[Original message clipped]
I'd say he was correct. Peter is a very insightful guy. Even if he is still
stuck in the past wrt VB being the most productive language ;-)
[Original message clipped]
language and there is a very real shortage of good Delphi programmers already.
But I think they'll find C# more to their liking because, as with C++, they
aren't used to being constrained by their programming tool like VB will
constrain them. I haven't used Delphi for over 5 years, so I'm not exactly up
to speed wrt what's happening in that area. Perhaps you could shake loose a
couple who've tried both VB and C# and ask them. Again, it may be more a
matter of personal emotional state, goals, and what-not, than a matter of
language capabilities.
> Any other comments on the matter that you'd like me to consider?
Nah, I'm just idling waiting for another couple of posts so I can drop in some
more new things nobody is mentioning out loud that VB can't do ;-))
Oh, yea. I'd like to hear from any VB programmers that do decide to do C#
because they read some of my postings here and it made sense.
I'm also interested to hear from VB people that consider themselves competent
or advanced, but have decided not to even try doing something with C#, and
why.
If any of you don't want to publicly post, but would like to send me an email,
take out the "no" and the "spam" from the addr below:
Click here to reveal e-mail address
You can flame me here too. I've got my asbestos underwear on.
Keep Smilin'
Ed Stegman
|
|
|
| |
|
|
| |
| |
| Peter McMahon |
Hi Ed
Thanks very much for the reply - I think we've all ended up losing some
sleep on this thread, probably mainly thanks to the time zone differences
(I'm @ GMT+02). When I've managed to catch up all the work I've now missed
(I must've spent at least 10 hours on this wretched thread ;-), I'll compile
the follow-up article, including your ideas, along with Peter Torr's, my own
and any other good points that the other contributors to this thread raised.
I can't guarantee I'll please everyone ;-) [mainly because I don't take
quite as radical a stance towards VB.NET as you do, even though I understand
where you're coming from, I err towards Peter Torr's opinions], but we can
agree to disagree on some of the finer details.
'Dig the tricycle/bicycle/drag bike/missile analogy ;-)
You seemed interested in the situation of Delphi programmers, and their
opinion on C#/.NET - I'm mildly qualified to speak here, since my
programming career follows steps something like the following: RISC BASIC ->
QBASIC -> VB -> Delphi -> ASP -> .NET. That's in order of what I did/do
'mainly' - obviously there was a little overlapping, especially with the
Delphi/ASP 'era', as I was doing more web dev work than Windows app work,
but I was more or less using the two simultaneously. I moved from VB to
Delphi for two main reasons: 1.) I just got fed up with it 2.) I wanted a
new challenge. Moving to Delphi was actually a darned bright move though, in
hindsight, as it was Delphi that tought me most of what I know about OOP.
Delphi's a very cool language, and I'd probably pick it over VB anyday for
most tasks. However, at the same time I was doing Delphi, the web was
getting big, so I learnt HTML and then tried out ASP, which I was doing full
time up until about Nov last year, when I started finding out about ASP.NET.
After getting hold of Beta 1 of VS.NET, I was hooked on ASP.NET, but the
whole .NET idea really appealed to me for Windows app development as well,
so Delphi's pretty much a goner for me now. I've still got a copy on my
machine, but I've probably only used it about 5 or 6 times this whole year,
and most of those times were for mundane things. Borland hasn't done too
much new and innovative with Delphi 6 as far as I can see, and although
Kylix (Delphi on Linux) seems appealing (if only just to try out for the fun
of it), the Mono project (an attempt to rebuild the .NET Framework SDK for
*nix - www.go-mono.com) actually seems to be progressing quite nicely, so if
there was one reason to stay with Borland, it's pretty much gone now.
Although Delphi 6 has support for building 'web services', I think that
without a doubt VS.NET is the easiest and best environment do both build and
consume services in. It is second to none, as far as I'm concerned. For me,
Delphi was a good choice at the time as it was better, IMHO, than VB, and
yet it was more productive than using C++. However, all the gripes I had
with both VB and C++ pretty much disappear in .NET and C#/VB.NET, so
although Delphi was good, .NET is *much* better. That's my take on it
anyway. I've seen a few other Delphi converts on the .NET newsgroups as
well, so I'm pretty sure I'm not the only one who sees it this way.
Cheers
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:uDqv0$8gBHA.1964@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
| |
|
| |
| Peter Torr \(MS\) (VIP) |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:uDqv0$8gBHA.1964@tkmsftngp02...
[Original message clipped]
[bla]
This is an excellent post (yeah I know it was addressed to the other Peter
;-) ). Even if I don't agree 100% with all the opinions, it's definitely
well thought out and covers various approaches to the problem.
I agree with Ed that this has not been a waste of time, and even if most
people stopped reading this thread a long time ago, I think the end result
in Peter's follow up article will be worth it.
Now, it's back to answering the really important questions, like "why
doesn't MessageBox.Show work in an ASP .NET page?"
Seriously.
Peter "flattery will get you everywhere" Torr <g>
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Peter McMahon |
[Original message clipped]
When I said that for most of the "target audience of my original article" a
lot of this thread would be a waste of time, I was speaking about the people
who are either beginners at programming or total newbies, because they
wouldn't have a clue about half the stuff that's been said, especially from
Ed and Peter (other one ;-) [I can just see the face of a newbie reading
through the intense arguments of early- vs late-binding and the image
manipulation sample, just two of many]. However, I definitely agree that for
"competent" developers (by Ed's definition), this thread has definitely been
very productive, and certainly hasn't ended up with people aimlessly flaming
each other without backing up their statements.
[Original message clipped]
Don't even get me started on that one ;-) Just as Ed believes that VB can
foster bad programming practices in beginners, I believe that ASP.NET and
VS.NET are very *bad* for newbies to begin learning web programming with,
for the simple reason that they don't force the newbie to understand the
fundamentals of DHTML and HTTP. I wrote quite a well-received article on the
matter here - http://www.dotnet.za.net/viewarticle.asp?articleid=10" target="_blank">http://www.dotnet.za.net/viewarticle.asp?articleid=10. And
that won't start a whole new 500Kb thread, because everyone here will agree
with what I've said. I hope. ;-)
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
|
|
|
| |
|
|
| |
|
|
|
|
|
| |
| Larry Serflaten |
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote
[Original message clipped]
I dunno if you have a 'clear winner' there, VB seems to be able to do it in 3,
plus the declarations. Exactly what does that JScript code look like?
Here is my VB code (on Form1):
'Reference Microsoft Internet Controls for:
Private WithEvents IExplorer As InternetExplorer
Private Sub Command1_Click()
1 Set IExplorer = New InternetExplorer
2 IExplorer.Navigate "www.microsoft.com"
End Sub
Private Sub IExplorer_DocumentComplete(ByVal pDisp As Object, URL As Variant)
3 Debug.Print IExplorer.Document.Title
End Sub
The title printed is "Welcome to the Microsoft Corporate Web Site"
<g>
LFS
|
|
|
| |
|
| |
| |
| mule |
"Larry Serflaten" <Click here to reveal e-mail address> wrote in message
<ee7eK#8gBHA.2200@tkmsftngp05>...
[Original message clipped]
Erm, C#, 1 line. It goes like this:
System.Diagnostics.Process.Start("IExplore.exe",
"http://www.microsoft.com/";);
Complete compilable program:
using System;
class openIE
{
static void Main()
{
System.Diagnostics.Process.Start("IExplore.exe",
"http://www.microsoft.com/";);
}
}
Why the big deal?
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
| |
| |
| Larry Serflaten |
"mule" <Click here to reveal e-mail address> wrote
[Original message clipped]
That doesn't perform as required. You did not print out the title of the web page.
> Why the big deal?
I don't know, Peter seemed to think JScript had a lock on the language that
required the least amount of code, as above....
LFS
|
|
|
| |
|
|
| |
| |
| mule |
"Larry Serflaten" <Click here to reveal e-mail address> wrote in message
<u#O4Yg$gBHA.1012@tkmsftngp03>...
> That doesn't perform as required. You did not print out the title of the web page.
yours printed to the debug window, mine printed to the title bar of
the IE window. I hardly think either qualify as real printing.
[Original message clipped]
Quite. The qn was meant for Peter.
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
| |
|
|
| |
| Peter Torr \(MS\) (VIP) |
"mule" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
That's not good -- you don't programmatically have the title of Microsoft's
home page. I want the title of the document as a string (which you can then
print out to prove you have it).
> Complete compilable program:
Which is 8 lines, but whatever ;-).
There's no real point to this other than to show that it is more productive
(for some definition of the word "productive") to do tasks like this in a
language that allows late-binding as a first class operation.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| mule |
"Peter Torr \(MS\)" <Click here to reveal e-mail address> wrote in message
<#Avkt2$gBHA.2384@tkmsftngp03>...
[Original message clipped]
No fair, braces don't count as lines.
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
|
| |
|
|
|
| |
| Peter Torr \(MS\) (VIP) |
"Larry Serflaten" <Click here to reveal e-mail address> wrote in message
news:ee7eK#8gBHA.2200@tkmsftngp05...
> I dunno if you have a 'clear winner' there, VB seems to be able to do it
in 3,
> plus the declarations. Exactly what does that JScript code look like?
The JScript program (complete and runnable) is
import System.Threading
var x = new ActiveXObject("InternetExplorer.Application")
x.Navigate("http://www.microsoft.com";)
Thread.Sleep(1000) // Adjust as necessary
print(x.document.title)
I mentioned somewhere else that VB does it in about the same number of
lines, *plus* declarations. Visual Studio will do the declarations for you,
but if you are using only the Framework then you have to write them
yourself.
Here's the code, for the record:
Module Foo
Sub Main
Dim x =
Microsoft.VisualBasic.Interaction.CreateObject("InternetExplorer.Application
")
x.Navigate("http://www.microsoft.com";)
System.Threading.Thread.Sleep(1000) ' Adjust as necessary
System.Console.WriteLine(x.document.title)
End Sub
End Module
> Here is my VB code (on Form1):
That's VB 6! You're cheating! :-)
[Although of course, realistically, you'd do this kind of task in WSH and
never touch .NET. Horses for courses.]
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Jim Ley |
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:euXqh7$gBHA.836@tkmsftngp02...
[Original message clipped]
Yeah, but importing System.Threading, relying on an arbitrary time for
the Sleep... nah don't want to do that kind of stuff:
xmlhttp=new ActiveXObject("Msxml2.XMLHTTP")
xmlhttp.open("GET","http://www.microsoft.com/";,false);
xmlhttp.send()
print(xmlhttp.responseText.match(/<TITLE>.*<\/TITLE>/gim))
(Of course if MS used XHTML (No reason why it should of course) it would
be simpler, you may want to alter the RegExp to remove the TITLE's that's
up to you, it'd still be 4 lines though :-)
Jim.
|
|
|
| |
|
| |
|
| |
| Daniel Pratt |
Hi Peter,
I decided that I was curious enough about how JScript accomplishes its
magic to dig into the IL. Phew! quite a lot going on under the hood, eh? I
was humored to find a method called LickArgumentsIntoShape :-) Is this your
doin's?
Regards,
Dan
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:euXqh7$gBHA.836@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Daniel Pratt" <Click here to reveal e-mail address> wrote in message
news:uXKu3aMhBHA.2260@tkmsftngp07...
[Original message clipped]
No, that's not my doing, but it is rather funny. I'm a Program Manager,
which means I do stuff like read newsgroup threads, rather than actually
doing useful stuff like writing code.
From an implementation perspective, JScript .NET is quite complex.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Warren R. Zeigler |
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:OHHot6MhBHA.2112@tkmsftngp03...
> From an implementation perspective, JScript .NET is quite complex.
I just got into this group.
JScript.NET?
--
Warren R. Zeigler
Understanding Objects - The class people have been looking for - even if
they don't know it.
www.UnderstandingObjects.com
|
|
|
| |
|
| |
| | |
|
|
|
|
|
|
| |
| Jacob Grass \(MVP\) |
Okay Ed, you knew someone would do it, so I converted this code to VB.NET
the best way I knew how. . . And, I'll be honest, it took me about 5 hours.
.. . The majority of this time was spent reading documentation. .. A little
background, I have never programmed with pointers or bitmaps, I have only
ever used C# once (that lasted about 20 minutes), I have never programmed in
any othe C-Style language, I have used the Marshal class in the framework
once (and that was with help from Mattias) . . . I am posting my first
working solution. . . I don't know if there is a faster way. My solution is
about 4.5 times slower than the fastest solution posted by Eric. . . (and, I
don't know if there is overhead from calling a VB.NET DLL from C#) . . .
This is Eric's relevant code from the article:
*************************************************************************
public void MakeGreyUnsafeFaster()
{
Point size = PixelSize;
LockBitmap();
for (int y = 0; y < size.Y; y++)
{
PixelData* pPixel = PixelAt(0, y);
for (int x = 0; x < size.X; x++)
{
byte value = (byte) ((pPixel->red + pPixel->green + pPixel->blue) / 3);
pPixel->red = value;
pPixel->green = value;
pPixel->blue = value;
pPixel++;
}
}
UnlockBitmap();
}
public void LockBitmap()
{
GraphicsUnit unit = GraphicsUnit.Pixel;
RectangleF boundsF = bitmap.GetBounds(ref unit);
Rectangle bounds = new Rectangle((int) boundsF.X,
(int) boundsF.Y,
(int) boundsF.Width,
(int) boundsF.Height);
// Figure out the number of bytes in a row
// This is rounded up to be a multiple of 4
// bytes, since a scan line in an image must always be a multiple of 4
bytes
// in length.
width = (int) boundsF.Width * sizeof(PixelData);
if (width % 4 != 0)
{
width = 4 * (width / 4 + 1);
}
bitmapData =
bitmap.LockBits(bounds, ImageLockMode.ReadWrite,
PixelFormat.Format24bppRgb);
pBase = (Byte*) bitmapData.Scan0.ToPointer();
}
public PixelData* PixelAt(int x, int y)
{
return (PixelData*) (pBase + y * width + x * sizeof(PixelData));
}
public void UnlockBitmap()
{
bitmap.UnlockBits(bitmapData);
bitmapData = null;
pBase = null;
}
}
}
********************************************************
And, here is my equivalent code:
********************************************************
Public Sub MakeGrey()
Dim size As Point = PixelSize
Dim pixBytes(Marshal.SizeOf(GetType(PixelData)) - 1) As Byte
Dim pixStruct As PixelData
Dim tempPix As IntPtr
Dim PixelDataSize As Integer = Marshal.SizeOf(GetType(PixelData))
LockBitmap()
tempPix = pBase
Dim Count As Integer = size.X * size.Y
Dim temp As Int32
Do While Count <> 0
Marshal.Copy(tempPix, pixBytes, 0, PixelDataSize)
temp = CType((CType(pixBytes(0), Integer) + _
CType(pixBytes(1), Integer) + _
CType(pixBytes(2), Integer)) / 3, Int32)
With pixStruct
.blue = CType(temp, System.Byte)
.green = .blue
.red = .blue
End With
Marshal.StructureToPtr(pixStruct, tempPix, True)
tempPix = IntPtr.op_Explicit(tempPix.ToInt32 + PixelDataSize)
Count -= 1
Loop
UnLockBitmap()
End Sub
Public Sub LockBitmap()
Dim Unit As GraphicsUnit = GraphicsUnit.Pixel
Dim boundsF As RectangleF = Image.GetBounds(Unit)
Dim bounds As Rectangle = New Rectangle(CType(boundsF.X, Int32), _
CType(boundsF.Y, Int32), CType(boundsF.Width, Int32), _
CType(boundsF.Height, Int32))
m_width = bounds.Width * Marshal.SizeOf(GetType(PixelData))
If m_width Mod 4 <> 0 Then
m_width = CType(4 * (m_width / 4) + 1, Int32)
End If
m_BitmapData = Image.LockBits(bounds, ImageLockMode.ReadWrite, _
PixelFormat.Format24bppRgb)
pBase = m_BitmapData.Scan0
End Sub
Public Sub UnLockBitmap()
Image.UnlockBits(m_BitmapData)
m_BitmapData = Nothing
pBase = Nothing
End Sub
******************************************************
Simply submitted for your viewing pleasure. . .
--
Jacob Grass
Microsoft .NET MVP
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:#tUv#ytgBHA.2248@tkmsftngp02...
> Please post your solution and how long it took you. Be honest. Even though
it'll hurt terribly to admit it.
>
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/ht
ml/csharp11152001.asp>
>
|
|
|
| |
|
| |
| |
| Ed Stegman |
Absolutely fantastic job! See what I mean about there being some real pro's
using VB?
That Mattias guy is a real gem of a person, isn't he? I'm astounded at his
depth of knowledge, and coupled with his care and willingness to help others
puts him in a class by himself. :-))
You realize, of course, that you proved my point?
The time you spent on this one method could have been spent on learning C#
instead[1], and then you wouldn't have to waste 5 hours to do a 10 minute job
ever again, only to fall short of the acceptable perf objective anyway.
The C# people are going to need MVP's too ya know :-))
Keep Smilin'
Ed Stegman
[1] Given 8 hours, I could have somebody of your caliber writing as good C#
code as you do VB.NET code right now. That time would be less if I was
somebody that knew how to teach.
Toss in a couple 3 days for pointer stuff and you'd be over the top! Ask
Mattias if you don't believe it.
"Jacob Grass (MVP)" <Click here to reveal e-mail address> wrote in message
news:#OemVQDhBHA.2004@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Jacob Grass \(MVP\) |
Ed-
Okay, I modified my version and now it is much faster. . . (I couldn't leave
well enough alone. . ) : )
My first version was 4.5 times slower. . . This version is 1.3 times slower
than Eric's . . . The conversion function is below:
Dim size As Point = PixelSize
Dim PixelDataSize As Integer = Marshal.SizeOf(GetType(PixelData))
Dim pixStruct As PixelData
Dim tempPix As IntPtr
Dim RowByteSize As Int32 = size.Y * PixelDataSize
Dim pixBytes(RowByteSize - 1) As Byte
Dim i As Int32
LockBitmap()
tempPix = pBase
Dim Count As Integer = size.X
Dim temp As Byte
Do While Count <> 0
Marshal.Copy(tempPix, pixBytes, 0, RowByteSize)
For i = 0 To RowByteSize - 1 Step 3
temp = CType((CType(pixBytes(i), Short) + pixBytes(i + 1) + pixBytes(i +
2)) \ 3, Byte)
pixBytes(i) = temp
pixBytes(i + 1) = temp
pixBytes(i + 2) = temp
Next
Marshal.Copy(pixBytes, 0, tempPix, RowByteSize)
tempPix = IntPtr.op_Explicit(tempPix.ToInt32 + RowByteSize)
Count -= 1
Loop
UnLockBitmap()
--
Jacob Grass
Microsoft .NET MVP
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:O3sn#9DhBHA.1684@tkmsftngp03...
> Absolutely fantastic job! See what I mean about there being some real
pro's
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Cali LaFollett |
> Okay, I modified my version and now it is much faster. . . (I couldn't
leave
> well enough alone. . ) : )
You Animal! ;-)
|
|
|
| |
|
| |
|
|
|
|
| |
| Cali LaFollett |
[Original message clipped]
ml/csharp11152001.asp>
[Original message clipped]
Ed,
Been busting my butt doing design on a new project at work and just now
getting to your challenge. I started this at 7:25 pm (EST) tonight and it is
now 11:10 pm. I had originally given about 3 1/2 hours.
As Jacob already mentioned, it is about 4 times slower. There isn't much I
can see to fix it but it does work. Anyways, have a look see. (it is the
whole project mind you)
Cal
|
|
|
| |
|
| |
| |
| Ed Stegman |
Very nice.
I see you didn't stop at the first non-GetPixel() solution, but instead, kept
kicking at it until you found a way to double the speed! It's apparent your
employer doesn't have to worry about 1/2 assed work getting done :-)
Keep Smilin'
Ed Stegman
"Cali LaFollett" <Click here to reveal e-mail address> wrote in message
news:OXmqkZFhBHA.1688@tkmsftngp03...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Cali LaFollett |
> I see you didn't stop at the first non-GetPixel() solution, but instead,
kept
> kicking at it until you found a way to double the speed!
I wanted to actually tweak it fast and try to get rid of those damned
marshal calls! ;-) Maybe this weekend. By the time 11:15 pm roled around
though, I figured it was time to call it quits for the night! I am already
dreaming custom tree nodes and treeviews (due to current design), don't need
them damn pointers in there too! ;-)
[Original message clipped]
That's always my goal. I am not necessarily the fastest all the time but I
can say that when it is done, I have but every synapse at my disposal to the
cause! ;-)
BTW, when I asked my earlier question as to what you thought VB was lacking
in comparison to C#, I wasn't trying to imply that I don't like C#.
Personally I would love the ability to use it OR VB (depending on the task
mind you). My employer is under the gun to get a product released before
it's time (sound familiar to anyone out there? ;-) and feels that with a my
knowledge base being more from the VB side than the VC++ side, it was best
to stick with VB. I actually proposed Delphi 5/6 but lost that one!
As to my earlier comment of wanting a language that makes use of the best of
both worlds. Personally, I think a language that is close to what I want
already exists. I am not sure yet if it does for .NET though. It's called
Object Pascal, the language that makes up Delphi.
Object Pascal has the readability (not verbosity though) of VB and the power
and flexibility of C#. There a couple of things I would do to tweak in it
such as:
1. Having the ability to declare variables within the procedure where ever I
want
2. The ability to control the visibility of objects (there is no really
concept of private classes).
3. Add for...each capability! This is a must for working with collection
type objects.
4. Change the "set" operator from the horrid ":=" to "=". (Still not sure
what to do with the Equality comparison operator though)
5. Add "static" class members. Right now you would have to create a "module"
variable and then a class member that access just that variable.
People may knock Delphi and Object Pascal but I think those that are
knocking the loudest are also those that have never touched it. Just replace
the good ol' "*" pointer with "@", "{" with "begin" and "}" with "end" and
you have it made! ;-)
Well that's my two cents before I head off work!
--
Regards,
Cal
|
|
|
| |
|
| |
| |
| Ed Stegman |
LOL! All the things you want for object Pascal, C# already has :-))
BTW, I posted the "real" solution to the grayscale challenge to this ng
(.framework). I didn't cross post though because I started a new thread and
I'm not sure about the etiquette of cross posting. The solution is on a post
titled "GrayScale Challenge - Pure GDI+ Solution :-))"
Have a good weekend!
Keep Smilin'
Ed Stegman
"Cali LaFollett" <Click here to reveal e-mail address> wrote in message
news:uPK0OnJhBHA.2368@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Cali LaFollett |
> LOL! All the things you want for object Pascal, C# already has :-))
As well as VB.NET! ;-) That's why they were on my wish list! ;-)
That's the whole reason for my comment of having a mix of C# and VB.NET.
Object Pascal already has the ability to do Pointers, delegates ("method of
object" pointers) and much of what you take for granted.
You had previously mentioned "variable casing" (bitmap and Bitmap for
instance) and that it was bad for VB not to have this ability. I actually se
it as good because, as the lazy programmer I am ;-), I can type most
anything in all lower case knowing that the IDE will case it properly. For
those of use that don't have secretary like accuracy with the keyboard, this
is a savior! ;-)
What I wish C# had may be more from and IDE support perspective than
anything. This may be there in RC1 but I haven't checked yet. If I were to
type the following line in the IDE:
Bitmap bitmap = new Bitmap //<-- leave the parrens off
The IDE does not put the "()" parrens on for me. In VB.NET, this happens
automatically. Again, a savior on the key strokes and carple tunnel! ;-) I
personally hate hitting that "Shift + 9" then "Shift + 0" all the time.
But on the flip side, I like the fact that C#, for the most part, is much
less verbose when declaring voids (Subs) and functions as well as other
areas regarding syntax. This is where the carple tunnel typing comes back to
haunt me! ;-)
[Original message clipped]
I'll have to go check it out!
> Have a good weekend!
You too! Now go eat some cold Pizza, drink some luck warm coffee and get
back at that keyboard Mister! ;-)
--
Regards,
Cal
|
|
|
| |
|
|
| |
| |
| Ed Stegman |
You can always create a macro / hotkey pair so it's only 1 stroke :-)
Personally, I wouldn't like the auto behavior. Anytime I forgot the parens, I
probably forgot the arguments too. Auto putting the parens on would then call
the default constructor, and if that wasn't my intention, I'll have a booger
of a time debugging later.
No thanks. I'd much rather let the compiler catch it than run the chance of it
getting past the testing dept. and out to a client.
A comprise might be nice. Type in new objectName, hit space and it puts the
left parens and pops up Intellisence. I could learn to like that :-))
Keep Smilin'
Ed Stegman
[Original message clipped]
|
|
|
| |
|
| |
| |
| Cali LaFollett |
> A comprise might be nice. Type in new objectName, hit space and it puts
the
> left parens and pops up Intellisence. I could learn to like that :-))
I like it! Maybe somebody from MS could add this to the C# wishlist!
Then what could happen is if you hit enter and did not include a parameter,
the IDE could finish off the line with a right paren and the semicolon! This
gives the best of both worlds, control and typing speed. One knows that by
hitting enter, you do not want to enter a parameter and to move on!
Cal
|
|
|
| |
|
| |
| |
| Ed Stegman |
Sorry, that doesn't work. Hitting enter means no more in C# than hitting the
space bar. Many times I hit the enter key so I can format the parameter. I
sure don't want the IDE getting in my way here.
Here's an example of multi-line formatting.
float[][] grayShear = {
new float[] {0.5f, 0.5f, 0.5f, 0.0f, 0.0f},
new float[] {0.5f, 0.5f, 0.5f, 0.0f, 0.0f},
new float[] {0.5f, 0.5f, 0.5f, 0.0f, 0.0f},
new float[] {0.0f, 0.0f, 0.0f, 1.0f, 0.0f},
new float[] {0.0f, 0.0f, 0.0f, 0.0f, 1.0f}};
Keep Smilin'
Ed Stegman
"Cali LaFollett" <Click here to reveal e-mail address> wrote in message
news:eWwf3lKhBHA.1940@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
|
| |
|
|
|
|
|
| |
| Peter McMahon |
> As to my earlier comment of wanting a language that makes use of the best
of
[Original message clipped]
I'm one of those Delphi programmers who made the move to .NET, and although
there is "Component Pascal" for .NET, it doesn't look professional at all,
and the user support seems to be about nil, so I'm sticking with C#/VB.NET.
Object Pascal was definitely the ideal language before .NET was released
though, I've got to agree with you there. I moved to Delphi from VB, and
whoa, what a difference! It's much more powerful and flexible, and it's very
productive as well. For beginners it's also great because it does its best
to enforce good programming practices (typed programming, always declaring
variables etc) and it fully supports OOP. However, with .NET out, I have
this feeling that the Delphi user base is only going to get smaller, despite
the best efforts of Borland with Kylix and Delphi 6.
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
|
|
|
| |
|
| |
| |
| Cali LaFollett |
> I'm one of those Delphi programmers who made the move to .NET, and
although
[Original message clipped]
Yea, it would be a shame to see Delphi fade away! There are small rumors
running around that they may try to come up with a Delphi.NET. Personally, I
don't see where I would truly want it unless they made it interop like VC++
does and use managed extensions. One of the greatest things with Delphi is
its raw runtime speed. It is fast enough to rival the likes of some of the
best C++ apps and compiles in a fraction of the time!
I am going to stick with VB.NET until I get my latest project at work done
and then I will probably concentrate on C#. The idea of having natively
supported typesafe pointers back would be great! I don't see MS adding this
support to VB in the near future if ever either. These are one of the things
I miss in Delphi.
Oh well, if I made the choices here at work, I may not even be monitoring
this news group ;-) It would probably be labeled something like
public.borland.delphi! ;-)
--
Regards,
Cal
|
|
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
| james |
Ed, your right I probably was doing a bit of name calling there and I'm
sorry. But , given that it is so common in the VB newsgroups (where the
original poster Cross-Posted this message and the entire thread has been
cross posted to) it came across to me as more of the same old thing of
C++ is a better language than VB and VB is a toy language , only now it
has started to come from someone in the C# camp. That is the reason I
used the term, C# snobs.
As for the language choice thing, it isn't relative to "dotnet.framework".
The original author posted his announcement to a whole carload of
newsgroups. And I read and responded to it and your statements in the
"microsoft.public.dotnet.languages.vb" group.
I do agree that VB does make it easy to "learn or aquire" bad programming
habits. But, I've seen some pretty bad programming habits
in other programming languages too. As your statement seems to make clear,
it is up to the individual programmer to obtain good programming habits.
And that can just as easily be done in VB as in C++ or any other language.
Unreadable code can be generated in any language.
What I think I am trying to say here is that given proper learning
skills,
there is almost nothing that a VB.Net programmer cannot do as opposed to
someone programming is C#.
And who knows, maybe I'll give C# a whirl.
Maybe the best thing for a serious programmer to do in this case is to learn
both VB.NET and C#.NET. And then use whichever tool will do the job as
needed. Besides, it is better to have more than one tool on one's toolbelt
!
james
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:#LTGsDqgBHA.2428@tkmsftngp03...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Ed Stegman |
Apology accepted. I can perfectly understand how the good VB programmers (and even the bad ones with the false impression they are
good) are so full of angst and are so touchy. It's a prime example of why prejudice in any form is a very evil thing.
Although I've been lurking around listservs since the beginning of time, I've avoided newsgroups like the plague. So, forgive me for
being a "newbie" and not realizing that if I responded to a message I d/loaded from dotnet.framework that it my response would go to
dotnet.languages.vb. I certainly had no intent of SPAM'n you guys. Although I am happy to have your feedback.
Any reason why the cross poster wasn't vilified, sawn and quartered, and discarded like an old rag? I guess the etiquette rules are
different here?
Keep Smilin'
Ed Stegman
|
|
|
| |
|
| |
| |
| Peter McMahon |
> Any reason why the cross poster wasn't vilified, sawn and quartered, and
discarded like an old rag? I guess the etiquette rules are
> different here?
The reason I cross-posted to so many newsgroups is I wanted to get feedback
from all the camps (e.g. if I hadn't posted to .jscript, then Peter Torr
probably wouldn't have found it), and I know there's quite a fair number of
people who monitor only the newsgroups dealing with their languages and not
the .general and .framework ones.
So, to answer your question - either the people here saw the logic of my
cross-posting, or they're kind ;-)
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
|
|
|
| |
|
| |
| |
| Ed Stegman |
No doubt your being well liked has something to do with it too. :-)
"Peter McMahon" <Click here to reveal e-mail address> wrote in message news:#$hsB1ugBHA.2248@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
|
| |
|
|
| |
| Robert Chapman |
Ed,
I don't usually get into these threads because they go nowhere and just piss
me off. This thread seems to have more intelligent conversation than most
so I thought I would jump in.
What burns a lot of VB people, myself included, is that these threads tend
to speak in wide sweeping generalities. Most of these threads forget some
of the most important things (some already covered in this monster thread by
now):
- not all VB programmers suck at programming
- crappy design and poor code turns up in all languages
- every language, or OS, is good at solving particular problems
- productivity, deadlines, time to market, team environment all play a role
in what tools are used, this was more relevant before .NET
I AM A VB.NET PROGRAMMER and I'm never going to believe that it makes me a
second rate coder. I bet that I have read more books in the last 6 months
about programming (.NET and other) than most people do in a few years.
What's my point? It's the programmer and their passion that make a program
great, not the language.
Cheers
--
Robert Chapman, MCSD
Manager Applications Development
prairieFyre Software Inc.
http://www.prairiefyre.com
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:ukbn9ltgBHA.1640@tkmsftngp07...
> Apology accepted. I can perfectly understand how the good VB programmers
(and even the bad ones with the false impression they are
> good) are so full of angst and are so touchy. It's a prime example of why
prejudice in any form is a very evil thing.
[Original message clipped]
|
|
|
| |
|
| |
| |
| Ed Stegman |
I agree with you 100%.
My main point was to debunk the author's blanket statement that VB was the correct choice for people wanting to learn programming.
The article's conclusions were so obviously biased clone speak that I felt compelled to give people something else to think about.
Do I think VB.NET is a great language? Yes. It's light years ahead of VB6 in most regards, and VB6 is a damn good tool, so that's
saying a lot. But C# keeps getting short-shrifted, as the marketing machine keeps telling people "It's for C++ coders wanting to
move to .NET". Well, that's bullshit. Writing a program in C# is NOTHING like writing C++. The only similarities are the operators,
loop constructs, and conditionals. Yes, you can jump into "unsafe" code blocks and use pointers, and it will look much like C++ when
you do so, but you_don't_have_to. And it still isn't C++ when you do.
C# is a only a good language for C++ coders to move to because they are not used to being constrained or hindered by their toolset,
and they'll be overly frustrated by this if they switch to VB. They are still going to be frustrated with C#'s lack of
flexibility[1] anyway, but not to the same degree. The silly names the VB team decided to pick for OO established concepts wouldn't
go over very well either.[2]
A couple of important issues for professional developers are salary and job availability. This was also, not given any consideration
by the author of the article when advising to use VB to start learning. I'd give the availability edge to VB (for now), and the
salary edge to C# (for now).
Historically, those programmers fluent in multiple languages have drawn higher salaries. Knowing multiple languages also opens up
the market for you. Anything with a C in it and the salary goes way up. MSFT has really lowered the bar with .NET to enable people
to become productive in a multitude of languages now. It really is all about the CLR and the BCL. My point? C# is as easy as VB.NET
if you are going to be doing the same things as you would have in the VB.NET project. As everybody keeps pointing out, they are
very, very close in functionality.
You CAN learn and use C# very easily. If you look past the syntax, which is easy if you aren't using pointers[3], you'll see that it
is *much* closer to VB than to C++. Just check out all the examples done in both, and you'll see what I mean. Change the curly
braces to BEGIN END blocks as you would in T-SQL if that makes it easier for you to get started. Once you get started you'll realize
you already know most of the stuff anyway. Once you do, you'll have raised your income potential and the job market will be a much
wider playing field.
Another thing that will be in your favor is that people are slow to change their concepts of things. That means they'll be paying
much more for a C# developer than s/he's really worth because anything with a C in it *must* be hard, however patently untrue that
misconception now is.
As an example, PowerBuilder developers are getting an average of 10-15 $ U.S. per hour more than VB devs right now. Why? Because
there aren't as many around, the support system pales in comparison to VB's community, so it isn't so easy for them to put together
something they aren't entirely familiar with. As a result, it's perceived that for anybody to be good at it they must be top notch
people. You can learn C# must faster than PB, and it'll be perceived that you are more top-notch than the PB guy. Gotta love that
"C" stigmata!
Perhaps one of the enterprising authors in this forum will come out with a book or series of articles targeted at getting VB dev's
up to speed with C#. It really will be a thin book if you don't go into unsafe code. :-))
So, spread your wings a bit, take a step, and see what's over the wall. You don't need a ladder truck to do so anymore. :-))
Keep Smilin'
Ed Stegman
"Foolish" consistency is the hobgoblins of little minds.
Ralph Waldo Emerson
[1] C#'s unsafe blocks are *not* a drop into native code. They just let you use pointers is all. Also, you can't inline Assy.
either. Everything must still compile down to IL.
[2] Although, I do have to admit that if "virtual" hadn't been a term around since the beginning of OO, widely used and accepted by
every other OO language out there, I'd prefer mustOverride.
[3] After looking at several solutions done in C#, I found myself amazed at the absolute lack of pointer usage by the coders. A
couple of them had zero occurrences, while the others only used it in places where, if the app were done in VB, they would have had
to create a C++ .dll to get the job done. Good programmers catch on fast! :-))
"Robert Chapman" <Click here to reveal e-mail address> wrote in message news:u9RbZ4wgBHA.772@tkmsftngp04...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Robert Chapman |
I agree with your points. I don't know to many programmers who only use one
language. I flip between several each day, from crappy script languages, to
VB 6, to VB.NET and to InstallShield Script to name a few. It's one of
those funny things in this profession, you have to specialize in at least
one core language, yet still be a competent generalist in many others. I'm
in a very small company so I kind of have to learn what I need to know on
the fly. I suspect that bigger companies, by their very nature, don't force
this level of diversity on their employees.
And I agree that VB.NET has a lot of stupid keywors etc. Why do I have use
MustInherit instead of Abstract or some other accepted word??
--
Robert Chapman, MCSD
Manager Applications Development
prairieFyre Software Inc.
http://www.prairiefyre.com
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:umhOCK1gBHA.1964@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| David Rothgery |
"Robert Chapman" <Click here to reveal e-mail address> wrote in message
news:ep3Pff1gBHA.1592@tkmsftngp02...
> And I agree that VB.NET has a lot of stupid keywors etc. Why do I have
use
> MustInherit instead of Abstract or some other accepted word??
I'd say a better question is 'Why did something as abstract as abstract or
virtual become an accepted keyword?'
YMMV.
--
Dave Rothgery
Click here to reveal e-mail address
|
|
|
| |
|
| |
| |
| Robert Chapman |
I'm with you, pin COM down, put a bullet in it, and make sure that it never
gets up again...
--
Robert Chapman, MCSD
Manager Applications Development
prairieFyre Software Inc.
http://www.prairiefyre.com
"David Rothgery" <Click here to reveal e-mail address> wrote in message
news:OBZtQQ2gBHA.1176@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
| |
|
|
| |
| Mike Hofer |
As a matter purely of point, I have been a hardcore VB programmer since
version 1.0 (Windows 3.1 still gives me the shudders). But I picked up C#
very quickly, and have arrived at a place where I feel more comfortable with
it than with VB.NET.
<RANT>
There are some things about VB.NET that disappoint the hell out of me:
- Lack of unsigned types (big no-no)
- Namespace mangling. Just be specific, and save the sanity of TNPB.
- Hokey keywords (shared instead of static? Stick with the tried-and-true.
How am I supposed to explain to someone that they're the same? Worse, why
should I have to?)
- No operator overloading. I write object-intensive code, and I would
definitely like to see this soon.
- No block comments? Come on, guys. How hard is this to implement? And
what's up with that hokey line separator character? Surely there's a more
elegant solution.
- If VB is a 1st class citizen, how come it doesn't get that spiffy
XML-based documentation thingy that C# does?
- Modules? Will someone *please* put these out of their misery? What's the
point of being object-oriented if you're gonna let 'em write non-object
oriented code? Oh, wait - that's right. It's for backwards compatibility.
Excuse me, but isn't that how the VB language got so bastardized in the
first place?
</RANT>
On the other hand, VB.NET is light years ahead of VB6. And thank the Divine
that all that COM foolishness is going the way of the dodo (more or
less)--although that's admittedly a .NET thing and not specific to VB. I
could die happy if I never had to track down another broken binary
compatibility issue. But at least the objects are real, you can inherit,
override, and so on. It's about time.
As I see it, C# is the best of C++ and VB in one spiffy package. I get the
terse syntax of C++ (which I like, a *lot*), with some of the cooler aspects
of VB (like a better [if not perfect] switch statement, and a foreach
construct). It would be nice if C# had a With statement, but you can't have
everything (at least, not if Microsoft has anything to do with it).
Ultimately, I find that C# is simply better *for me*. I can't consciously
say one is easier to learn than another. My gripes about VB are mostly about
things I *need*; those that don't need them won't miss them. And I suspect
that C# was easy for me because I have a passing familiarity with C and C++
(just enough to be dangerous). But let's be honest: VB.NET doesn't look
anything like VB6 or its predecessors, so you can't just fall back on the
same old arguments before. It's a whole new ball game. If you want to
recommend a language to someone, I guess you'd have to suggest something
close to the language they came from (C, C++, Java, Delphi = C#; VB, PB,
etc. = VB.NET. Or something like that.)
Thankfully, as has been pointed out elsewhere, the differences between the
languages aren't enough to render code from either completely illegible
(which is a good thing, since Microsoft can't seem to decide if it wants to
do all the code samples in one language or the other).
Anyway, just my 2 platinum pieces.
Mike
"Robert Chapman" <Click here to reveal e-mail address> wrote in message
news:ep3Pff1gBHA.1592@tkmsftngp02...
> I agree with your points. I don't know to many programmers who only use
one
> language. I flip between several each day, from crappy script languages,
to
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Craig Powers |
Mike Hofer wrote:
[Original message clipped]
OO is -not- the be-all and end-all. It's very nice for many problem
sets, but there is still a time and a place for procedural programming.
Sometimes both in the same project.
|
|
|
| |
|
| |
| | |
|
|
|
| | |
| |
| Peter McMahon |
Hi Ed
> "It's for C++ coders wanting to move to .NET". Well, that's bullshit.
Writing a program in C# is NOTHING like
> writing C++. The only similarities are the operators,
Since that's in quotes, I presume this is a reference to my comments in the
article - if so, which language would you like me to suggest for C++
programmers wanting to move to .NET, other than C#? C++.NET?
Peter
|
|
|
| |
|
| |
| |
| Jim Ley |
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:O6nTXU6gBHA.620@tkmsftngp02...
[Original message clipped]
JScript of course :-)
I don't understand what the whole threads been about, All of the MS .NET
languages are very similar, there's not LISP.NET or something knocking
about to confuse things, anyone competent in either JScript/c++/VB should
have no trouble in learning any of the others, we're talking of a
Vocabulary of 10s of words, with stunningly similar Grammars (to use a
natural language analogy) Learning natural languages to a comptetent
level is tough, but learning please/thankyou/can I have beer is easy,
especially if you ignore grammar complications.
You may have a certain aesthetic like of a particular language, but
that's all it is the concepts underlying C# and JScript or even VB are
still so similar as to be irrelevent. The loop example keeps appearing
with some VB people suggesting that verbosity makes something clearer,
that's clearly rubbish verbosity does no such thing, just understanding
the tokens makes something clearer, and all VB gives is tokens which more
closely match their English equivalents (so this verbosity is
particularly no value to non-English speakers.) Verbosity does not make
things clear, we do not call a spade an agricultural earth moving
implement and claim it's easier to understand. so the difference between
i=1 to 10 and i=1;i<11;i++ is purely down to a knowledge of the tokens.
There are of course only a few tokens to understand in any language, and
you can surely understand them quickly, which language you is down to the
aesthetic beauty especially in .NET where capabilities are near
identical.
Jim.
|
|
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
| Jacob Grass \(MVP\) |
Ed-
[Original message clipped]
I agree with you here. . . .I think it comes down to personal preference
more than anything. . .
[Original message clipped]
I was a VB6 developer like this. . . I played around with C# and VB.NET with
Beta 1 and my ultimate decision was to go with VB.NET. . . I chose this for
a couple of reasons:
1) I prefer the verbosity of VB.NET over C#. With Intellisense and
Auto-completion, the speed of churning out code comparable, imho. . .
2) The things I develop are primarily Business Applications and Controls
(now that I have inheritance). These types of applications don't typically
need things like Pointers and Operator Overloading.
[Original message clipped]
So true. Once I realized that I already knew most of this stuff, I was
almost instantaneously productive. . .
[Original message clipped]
It does hurt to go back to VB6. . . .Very, very badly. . .
[Original message clipped]
I think that these are very valid items, except that you can do Overloading
(not operator) in VB.NET. . .
[Original message clipped]
What baggage are you referring to?
<snipped bits that I couldn't answer or that I agreed with>
--
Jacob Grass
Microsoft .NET MVP
|
|
|
| |
|
|
| |
| |
| mule |
"Jacob Grass \(MVP\)" <Click here to reveal e-mail address> wrote in message
<OISOxslgBHA.392@tkmsftngp04>...
[Original message clipped]
On Error Goto
All of Microsoft.VisualBasic namespace
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
| |
| |
| Michael Giagnocavo |
> > > C# doesn't have any baggage, and one of the primary concerns in the
design was to keep things consistent and at the same time
> > > prevent common mistakes that lead to bugs. It's much simpler to learn
C# than VB.Net, even for new programmers.
[Original message clipped]
I don't use On Error, and I barely use Microsoft.VisualBasic.
[Original message clipped]
|
|
|
| |
|
| |
| |
| mule |
"Michael Giagnocavo" <Click here to reveal e-mail address> wrote in
message
<uglcdrmgBHA.2448@tkmsftngp03>...
[Original message clipped]
Good.
But, You had no other method for error trapping in VB6, hence
baggage.
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
|
| |
|
| |
| Dean Cleaver |
I barely kill people too. Does that mean I do, or don't. The "law" doesn't
think that "well, he doesn't do it much so it doesn't count".
Michael, I hate to break the news to you, but you either do or don't use it.
There is no "barely" about it. 1 time is "I do use it". Never is "I don't
use it".
Decide.
Dino
"Michael Giagnocavo" <Click here to reveal e-mail address> wrote in message
news:uglcdrmgBHA.2448@tkmsftngp03...
> and I barely use Microsoft.VisualBasic.
|
|
|
| |
|
| |
|
|
|
| |
| Ed Stegman |
I find your reason for liking VB over C# "because VB is more verbose" a very legitimate issue for people to consider when
determining what language would be best for them.
It would be stupid of me, or anybody else, to think C# would be a better language for you, now that we know this. More good
information for the author to put into his revision. :-))
Don't forget the knife cuts two ways though. For people who dislike all the verbosity, VB wouldn't be a good choice. It is one of
the primary reasons I dislike it. I hate scrolling when reading code. Especially horizontally.
"Jacob Grass (MVP)" <Click here to reveal e-mail address> wrote in message news:OISOxslgBHA.392@tkmsftngp04...
snip...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Peter McMahon |
> I hate scrolling when reading code. Especially horizontally.
Lol, that's why I run my machine @ 1152 x 864 ;-)
P
|
|
|
| |
|
|
| |
| |
| Dean Cleaver |
That all?
I have LCD monitors, so am restricted... I used to work at 1600x1200 on a
21" monitor, but now use the LCDs so am restricted to 1280x1024, although
would never go back to a fish-bowl monitor now anyway...
Oh - and I use Times New Roman 9 pt for my font... that makes a HUGE
difference, and really annoys the VB programmers who rely on a fixed width
font for all their spacing al la:
Private Const cintX = 0
Private Const cintVariableWithABiggerName = 1
Dino
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:eEGQD1ugBHA.2248@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Peter McMahon |
I'm a poor programmer, so I've only got a 17" monitor, but that's good
enough ;-) I have no idea how some programmers survive on 800x600. Why would
you want to use Times New Roman though? I way prefer fixed width fonts, but
if I had to use another I'd definitely opt for Arial.
P
"Dean Cleaver" <Click here to reveal e-mail address> wrote in message
news:#ixFFRvgBHA.1552@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Dean Cleaver |
To be honest, just try it... you'll find that TNR is not too bad. Arial is
actually a bigger font, and takes more space. Personally I hate fixed width
fonts... each to their own.
I used to have a 17" fishbowl too, but even then I ran it at 1280x1024...
:-)
Dino
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:uodnWswgBHA.2308@tkmsftngp03...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Jeff Kohn |
"Dean Cleaver" <Click here to reveal e-mail address> wrote in message
news:e86Lr2zgBHA.2496@tkmsftngp03...
[Original message clipped]
Best font anywhere, is 'Arial Monospace for SAP'. It's a monospace,
non-serifed font that is slightly more narrow and a bit shorter than Arial,
but just as readable. Only downside is that the only way I know of to get it
(legitimately, anyway) is by installing the SAP client on your machine.
|
|
|
| |
|
| |
| |
| Peter McMahon |
[Original message clipped]
Do ya mind posting it on the NG for us? ;-)
P
|
|
|
| |
|
| |
| |
| Dean Cleaver |
SAP client or the font? ;-)
Dino
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:#AcxG50gBHA.1816@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
|
| |
| | |
|
|
|
|
|
|
|
|
|
| |
| Bob |
In article <e4KyakhgBHA.2264@tkmsftngp05>, Click here to reveal e-mail address says...
[Original message clipped]
A troll, I see. Obviously I can skip the rest of the post as it won't
contain anything useful.
Bob
|
|
|
| |
|
| |
| |
| Dean Cleaver |
Bob,
Nice assessment. Shame you were so wrong.
I have known Ed for about 6 years. Finally me him last June whilst in the
US. Fantastic guy with a fantastic mind (not to mention his family).
He's very focused and single-minded about his work, and as such can come
across as a bit harsh. But you really made a bad judgement call there. I'd
recommend going back and re-reading his message. You might learn something.
Ok, so I am a convert to C#... half at the badgering of Ed, half from my own
mind of a "fresh start"... begin with a new language that has no
hangovers...
Dino
"Bob" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
|
| |
|
|
| |
| Mark Hurd |
"Ed Stegman" <Click here to reveal e-mail address> wrote in message
news:e4KyakhgBHA.2264@tkmsftngp05...
[Original message clipped]
I don't agree with this logic: VB.NET has a VB heritige and C# has a definite
C/C++ heritige (with some Delphi too, AIUI).
If they produced a language that used the VB.NET keywords, but the C# syntax,
eg using "shared" not "static", etc then you might be able to claim that C#
has no baggage.
[ Elsewhere I have seen a post listing all of the things that VB.NET provides
that is not available to or harder to do in C#. It seems rather relevant to
this thread... but I can't find it right now :-( ]
[Original message clipped]
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)
|
|
|
| |
|
| |
| |
| mule |
"Mark Hurd" <Click here to reveal e-mail address> wrote in message
<eTCNKcygBHA.2396@tkmsftngp04>...
[Original message clipped]
The C# terminology is more concise and more internally consistent
than VB which seems to me to be a higgledy piggledy conglomeration
of terms from here there and everywhere. And has been for a long
time.
What is so good about shared?
[Original message clipped]
I don't believe there is anything that can be done more easily in
VB.Net. I'd like to see a demonstration if that's true. There are VB
shortcuts which get around some of the requirements to fully specify
namespaces -- but that isn't exactly what I'd call making things
easier, confusing things a little I fear.
mule
--
"jewels and binoculars hang from the head of the mule"
Bob Dylan
|
|
|
| |
|
| |
|
|
|
|
| |
| Joe Schmoe |
I agree. I think VB will still be the best language for the first-timer.
Not to imply that all VBers are incompetent hacks, but allot of these guys
are going to be turned off by the additional discipline required to engineer
an app with a truly OO language with strong type enforcement like C#. I
think the goal of VB is to make programming easier (and cheaper) whereas the
goal of C# is to make programming better. I have been thoroughly amazed at
the power of C# and its relative robustness when compared to C++ code. I've
found it much tougher to crash a C# app than a C++ app. I think C# will
lead to less frustrating software. Although I still think there is
something wrong with the garbage collector.
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:OLgqK9egBHA.1816@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Dean Cleaver |
Joe,
I find it interesting your choice of words:
goal of VB is to make programming easier (and cheaper)
Fine...
goal of C# is to make programming better
Ok... so you're saying the goal of VB is to enable people to produce crap
that works, as opposed to C# which forces people to do it right. Therefore,
anyone new to programming really should learn to produce crap as a first
choice?
Don't get me wrong... I am a VB programmer, who is switching to C# for
several reasons:
1. I can. Isn't that cool?
2. It's not so much learning C#, it's learning .Net that is taking the time.
3. I have unsigned ints, operator overloading and binary shift operators.
Never had them before in VB, and have no idea how to use them, but I _CAN_
if I want to learn.
4. I don't have to deal with VB.Hangover or whatever they call it.
5. I'm learning how to transfer all my bad coding styles from VB to a whole
new language.
And yes, I still catch myself doing "counter = counter + 1". A friend who
shall remain nameless "scalded" me and corrected it to "counter += 1". At
which point I "scalded" him and changed it to "counter++".
And yes, I got the usual "missing ;" error. Why oh why doesn't MS implement
a "double click this error and I will correct it for you" option. Woudld
save shitloads of VB programmers time when using C#.
Same goes for "Method X referenced without ()" ;-)
Dino
"Joe Schmoe" <Click here to reveal e-mail address> wrote in message
news:#aFCIPjgBHA.1320@tkmsftngp05...
[Original message clipped]
|
|
|
| |
|
| |
|
|
| |
| Peter McMahon |
Hi Peter
When I was writing the article, particularly the summary of JScript.NET, I
thought to myself, "If that Peter Torr guy ever finds out about this
article, I'm finished - I can still remember his strong adovacy for his baby
about this time last year when people started dissing it." Hey, and what do
you know - you found it. Darn. ;-)
Thanks for the reply though. It's always nice to get some constructive
criticism back. I've made comments inline.
Cheers
Peter
--
Peter McMahon
http://www.dotnet.za.net - The Premier Microsoft.NET Resource in South
Africa
*
> "Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:OLgqK9egBHA.1816@tkmsftngp02...
[Original message clipped]
Although I can see where you're coming from, I feel that it'd probably be
better just to start off with VB.NET. JScript.NET may very well be easier in
certain circumstances, but I think the problem comes in when the new
developer has learn his .NET language of choice after programming it in
Notepad for a few months, and now decides s/he wants to get Visual Studio.
If s/he learnt VB.NET, s/he could just buy VB.NET, and s/he'd be happy, but
if s/he'd learnt JScript.NET, s/he'd have to buy VS.NET (or VB.NET or
VC#.NET) and learn that language. Admittedly s/he wouldn't have too much of
a rough time doing so, because most .NET programming is programming against
the base classes rather than the languages, but it's still a hurdle that is
IMHO unnecessary.
[Original message clipped]
Yup, I know. I said that in the article (I hope ;-).
> 2) Visual Studio doesn't support every .NET language -- only those
languages
> that have explicitly added support for it via VSIP.
Yeah, I know. Maybe I didn't make that clear enough in the article, although
I did imply it, since I said that JScript.NET is available in the VS.NET
environment yet.
[Original message clipped]
Ah, thanks for that tidbit! Adds another piece to the puzzle...
[Original message clipped]
Lol, as I said up top, I knew you'd have issues with what I'd said about
JScript.
[Original message clipped]
I think there are actually two schools of thought on the
client-side/server-side language issue. However, before I dive in there, I
think it'll be quite some time (if ever), that web developers will be able
to safely use JScript.NET as their client-side scripting language without
worry about support in other browsers (like Opera/Mozilla - particularly on
the Linux platform). I know that IE holds about 85% of the share, but when
you're building a site that's expecting lots of traffic, that 15% is a lot
of people that you're isolating. You'll probably disagree with me, but I
don't think we'll see a day when it's possible to write JScript.NET code for
the client-side and not worry about cross-browser compatibility issues. If
you reply telling me that Opera and Mozilla have both agreed to implement it
in their next releases, I'll be a very happy man.
Now, on to the debate about whether using the same language for both server-
and client-side development is a good thing. As I said, there're normally
two camps holding radically different opinions on this matter. Firstly, for
relatively inexperienced web developers, I think that it is a very bad thing
because newbies often get confused by which code is client-side and which
code is server-side. The whole .NET Framework is confusing enough,
especially since it makes extensive use of client-side script for its own
workings in ASP.NET, so I think it's probably best to use two different
languages for client- and server-side code, so that you've got another layer
of separation to help avoid confusion.
[Original message clipped]
With regard to the scripting focus of JScript.NET, this is another reason
why I don't advocate it as a mainstream .NET language, but more as a niche
player. My article was intended more for people beginning .NET programming,
so scripting their own applications isn't much of a consideration at that
stage.
[Original message clipped]
Well, I'm not sure if you'll easily be able to take over the number of C#
and VB.NET developers. Perhaps it'll evolve into what web client-side
JavaScript is today (in terms of user base, which is obviously huge), but
when a new developer is looking for support from the developer community,
getting help and advice from experienced former VB/C++/Java programmers is
probably going to be a lot better than getting advice from developer's
who've only had experience with JavaScript, IMHO.
[Original message clipped]
I haven't had too much of a look at it, but from what I understand of it, it
looks set to be a niche language for power-users, esp. with it's native and
unmanaged code capabilities. I think that C# and VB.NET will be the "big
two".
[Original message clipped]
I've had a look at both Perl.NET and Python.NET from ActiveState, and
they're really very polished, so that's one reason, and another is that
there're probably more Perl and Python developers than there are COBOL,
FORTRAN, Eiffel, Haskell etc programmers combined. However, I wasn't for a
moment suggesting that COBOL programmers wanting to try out .NET shouldn't
consider Fujitsu's offerings, because that's probably what they'll be most
comfortable with. It's just that I don't really see COBOL becoming a major
..NET language - I think that Perl and Python have a much better chance
because of their substantially larger user bases (although most of those are
*nix people who wouldn't touch "Micro$oft" tools, so maybe I'm just digging
myself into a deeper hole here, although the go-mono.com project does give
me hope...)
[Original message clipped]
I took a brief look at Component Pascal a while back (since I'm
traditionally a Delphi programmer), and I wasn't very impressed, which is
why I recommend C# for Delphi programmers - the syntax isn't *that*
different, and C# is definitely going to go further than CP.
[Original message clipped]
I'm still not convinced ;-). JScript.NET might be an easier entry point for
new developers, but I still think its lack of both developer community and
VS.NET support make it difficult to recommend as a language for mainstream
development.
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:O8aGeMjgBHA.2144@tkmsftngp07...
[Original message clipped]
I think I see the flaw in your initial plan. You posted to
....languages.jscript ;-)
I think we'd both agree with each other (more or less <g>) if you changed
the focus of your article slightly. At the moment, it just talks about
people new to programming or new to .NET, but it appears that you are really
targetting people new to programming / .NET who want to write large
applications or become professional developers (it also appears that this is
what most of the other respondents have assumed).
There is a world of difference between someone who just wants to program for
fun, or to "scratch an itch", or because they have to, versus someone who
programs for a living or as their passion. For the first group of people,
all they need to do is to get the code to run. It doesn't matter if it's
slow, unmaintainable, inelegant, or even incorrect -- as long as it solves
their immediate problem. Often the program is only executed once or twice,
and the total running time of the progam (over its entire lifetime) is
measured in minutes or seconds. In such situations, it doesn't make sense
for the development time to be measured in hours or days. These are the
scenarios where all the "bad" things like typeless programming, optional
variable declaration, and so on are actually "good" things. If you're only
writing a 10-line program, even the cost of launching Visual Studio may seem
disproportionately large (versus running Notepad).
The second set of people (which most of us probably fall into) tend to write
entirely different kinds of programs, and approach them with an entirely
different attitude. Professional developers want their code to be
performant, correct, aesthetically pleasing, concise, elegant, maintainable,
well documented, etc. etc. etc. They take pride in their work -- as well
they should -- and often adhere to strict coding standards to maintain
product quality. It is therefore not unreasonable that such developers try
to instill similar coding practices in "newbies", lest they follow the Dark
Side into spaghetti coding, but at some point you need to step back and say
"what is this person's goal in writing code?"
My favourite analogy is with a professional race car driver. They probably
have a fairly new car, which they keep in tip-top shape, checking the oil
regularly, tuning the engine and the tranmission, always checking their tyre
pressure, washing the car every weekend, etc. I, on the other hand, drive a
beat-up old Honda. The trim used to be held on by duct tape (until it fell
off), I have no clue how to check the tyre pressure, I've changed the oil
twice in the last 2 1/2 years, and I'll probably never wash the thing. Why?
Because I don't care. The car gets me from A to B and that's all I need it
to do. When it finally dies, I'll probably buy another beat up old Honda and
abuse it in the same manner.
If Mr. (or Mrs.) Professional Driver met me on the street, would they want
me to change my oil, check my tyres, etc. etc.? Probably. Would it be
reasonable for them to expect me to do that as diligently as they do?
Probably not. By the same token, would you want everyone to declare their
variables, use strong typing, thouroughly document and test their code,
etc.? Sure, but would it be reasonable to expect the vast majority of
non-professional developers to do this? I don't think so.
My whole point is that just as there are more "casual" drivers in the world
than professional drivers, so too are there more "casual" developers than
professional developers, and yet the developer community, in general, tends
to ignore or deride these people. Hopefully you can address some of this in
your "alternative viewpoint" piece you mentioned elsewhere in the thread
;-).
[Original message clipped]
The primary target would be Intranets, where the client technology is (or
can be) controlled. Having said that... how many people (again, NOT thinking
primarily about professional developers) care about this? If it works on
their machine, that's good enough.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Ed Stegman |
Peter,
I found your post very thoughtful and insightful. Your points are all very true. They also prove my statement that for people at
MSFT, VB is to be targeted at power secretaries and those that just want to see something work without any real effort to learn
anything about programming or the tool itself. This line, especially drove the point home:
[Original message clipped]
Many people have taken this statement of mine to infer that I think all VB programmers fall into this category, and have been
throwing rocks at me. I'm sorry if my post gave that impression. I didn't say that, and I don't feel this way at all. I don't
consider somebody a bad programmer because they use VB. Some of the best and brightest programmers I've met used VB extensively.
There are many, many outstanding programs out there written in VB that are testaments to their authors' skills as programmers.
Especially considering that VB makes it easy to write simple one-off programs, but it becomes very difficult to stretch your wings
and fly with it.
Unfortunately, even though there are bad programmers using all languages, all the *really* bad programmers use VB too. Sadly, the
bad ones outnumber the good ones by 100 to 1. Lot's more Hondas out there than race cars. Why does VB attract the bad programmers so
much more than other languages? Because it's designed and marketed to do so. It's heavily marketed as not requiring any effort to
learn or program with. Lack of effort is usually the defining quality for a bad programmer, wouldn't you say? It's like a moth to
the light.
The exploitation of this large market of people who absolutely_are_not_interested in writing the best code possible, or of even
learning anything more than absolutely necessary, and sometimes not even that, (as you point out) is what made VB so successful as a
product. Some marketing genius, after visiting several peoples houses and noticing that the majority of their VCR's were still
blinking 12:00 (because they couldn't be bothered to read the simple one paragraph telling them how to set the time), realized this
early on, and took VB in that direction. It's still going in that direction, and will continue to do so. If people are buying corn,
you plant corn. Simple enough concept. I just can't figure out why so many VB programmers fail to see this and get all bothered
about it.
Until .NET arrived, VB was the tool of choice to get acceptable applications delivered in a timely manner. This was not because of
support for typeless programming, and all the other terrible programming practices it encouraged, nor because, as some people think,
the syntax was easier.
It was because:
1. Developers didn't have to deal with memory management, other than to protect against circular references.
2. The forms designer was the best in the business, and extremely easy to use. Modifying an existing form was cake too.
3. Wiring up event sinks was extremely simple, albeight not very robust. Good enough for 95% of the scenarios though.
4. No includes or #ifdef's, etc. to deal with. It just worked.
5. The debugger was simple, yet very flexible. One of the real strong points that didn't get the press it deserved BTW. (Edit &
continue, jump here or there, etc.). It was easy to find and fix bugs if the program was well written to begin with.
Now we find ourselves here in the .NET world. VB is not the only language to have these desirable traits anymore. There is a new
player on the block that has every one of these traits, and is more powerful also. Yet people have been thinking for so long that VB
is the only tool for RAD app dev, that they are failing to see something better right in front of their faces. Maybe it's just an
emotional attachment for VB? That is also as valid a reason to use VB.Net as any. Emotional comfort is high on the list of
desirables.
In a nutshell, here's how I see it. VB and C# are very close in capabilities. But, C# can do everything VB can do, and much more.
Doesn't matter if I use the "more" pieces every day, but it is nice having them there when you need them. VB and C# capabilities
will fork even more as they mature. This is normal. They both have to follow the needs of their primary audience target. Being a
serious developer, and C# clearly being targeted at serious developers, it's an easy choice. I don't see anything I can do faster in
VB, or better in VB. Yet there are many things I can do faster and better in C#. YMMV.
Keep Smilin'
Ed Stegman
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message news:OIevKVngBHA.592@tkmsftngp02...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Mark Lewis |
This is my favorite of all the posts here yet, you are right on as to why VB
caught on. Unfortunately, I see these same elements as why .NET will not
catch on until it adds higher level, not lower level "power programming"
features, to facilitate rapid development. I am neither a power secretary
nor a JAVA/C++ wannabe but rather someone who just needs a tool that gets
the job done quickly with a minimum of fuss and jargon. Do you think .NET
meets those requirements yet....I don't but have hopes.
..NET is clearly great for web applications, this is versus ASP I am not
qualified to say if the JAVA experience is still better or not, but doesn't
yet provide a better experience for building day-to-day desktop business
applications any more easily than does VB6. If I treated my customers like
the .NET developers have treated VB programmers, making wholesale syntax
changes in pursuit of some obscure technical not business goal, I would not
have any clients left. I don't think that .NET will ever bring the JAVA
crowd back to the Microsoft world, as most of those people hate anything
with Microsoft's name on it<vbg>, but it seems pointless to needlessly piss
off your loyal customers, whatever one might thing of their coding
abilities.
What would have been the harm in adding full VB6 compatibility to the CLR?
Such a feature is after all just a job for the compiler and there cannot be
any serious technical reason why this could not have been done. This would
have kept the "low level" people happy and still add features at the "top
end". Please note that, I use these pejorative terms very advisably as I
have seen just as many bad unmaintainable apps written in a "low level
BASIC" fashion as I have seen written in a "professional C/C++/JAVE/OO"
fashion. Usually the second group also took much longer to screw things up
than the first group which really pisses off the user community.
I want easier syntax to use, let the compiler do its job and figure out what
I mean<g>, not change for changes sake. Both VB.NET and C# seem a bit too
"academic" for my tastes. I too have never found bound controls worth the
effort but keep hoping that they could be finally made to work so as to take
some of the drudgery out of building basic database interaction screens. Our
users are more concerned about time to market than religious wars among
programmers.
Mark Lewis
President
Mark D. Lewis Inc.
Click here to reveal e-mail address
a 1994 Windows World Open winner...using VB of course...
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Mark Lewis" <Click here to reveal e-mail address> wrote in message
news:OFU5wpJhBHA.1892@tkmsftngp04...
[Original message clipped]
Hey Mark,
One of the big differences between VB 6 and VB .NET is that in VB 6, objects
are destroyed deterministically (thanks to the semantics of COM's reference
counting) but objects in .NET are garbage collected at indeterminate times.
Many people write code that depends on the timely destruction of objects --
for example:
Set f = File.Open("foo.txt")
str = f.ReadAll()
Set f = Nothing
File.Delete("foo.txt")
This style of coding works perfectly well in VB 6 and because the second
last line destroys f, thereby releasing the OS level file handle, thereby
allowing the Delete to succeed. In .NET, setting a variable to Nothing isn't
enough -- you have to call Close or IDisposable::Dispose in order to "clean
up".
Having a garbage collected memory management scheme that can also do
deterministic finalisation via reference counting would seem to represent a
"serious technical reason why this could not have been done".
Peter
(I know I said I wouldn't post again, but this is a different sub-thread,
don't you think?)
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
|
|
|
| |
| Peter McMahon |
Hi Peter
Comments inline.
[Original message clipped]
That'll teach me for not watching the .jscript NG vigilantly - I'm normally
at the .csharp, .vb or .aspnet groups where you only post occasionally, so I
fooled myself into thinking you'd lost your original enthusiasm for
defending your pet project on the newsgroups. Bad miscalculation. :-)
[Original message clipped]
True, true, I guess there is another side to the coin.
[Original message clipped]
The only problem is a lot of these 'accidental programmers' turn into
professional developers in time. I should know - I'm one of them :-) And all
those bad habits that were learnt when the programming you did didn't matter
and had a very short life expectancy need to be reversed when you make the
transit. But then, that's an entirely different issue...
However, if you're touting JScript.NET as the perfect replacement for people
like sysadmins who previously used WSH to perform system tasks (and the
script is often made and used for one particular incident only), then
there's a potential niche.
> My whole point is that just as there are more "casual" drivers in the
world
[Original message clipped]
Basically, I think this summarizes it: for professional developers, VB
people should move to VB.NET, and everyone else should move to C#. However,
for non-professionals who just want to get stuff done (as with
VBScript/JScript and the WSH), then JScript.NET is a viable option. Any
newbies that want a taste of programming might do well to try out
JScript.NET, but newbies with a view to become professional programmers
should go for VB.NET or C#. How's that? Hopeful a conclusion like that in my
next installment on the matter should leave all parties happy, but then
again, that's probably never going to happen.
[Original message clipped]
And that's one of the reasons why there's so much trash on the 'net ;-) And
as for intranets, the people building them are most likely to be
professional developers, so I think JScript.NET's role there falls away a
bit in favour of C# or VB.NET. However, if the sysadmins are building the
intranet, then they likely won't care about best programming practices, so
you win one in that scenario...
> Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
My curiosity is killing me, and it's probably going to make me look stupid
(which might not be far from the truth), but can you please explain the
Vengabus joke to me? :-)
Cheers
Peter
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:eievmaugBHA.772@tkmsftngp04...
[Original message clipped]
One could argue endlessly about this, but compromise is the art of diplomacy
(or something like that) and this is pretty good general advice.
[Original message clipped]
There is a suitably silly but infectious pop song called "The Vengabus (We
like to Party)" by a group called the Vengaboys. It's about a bus that is
also "an inter-city disco". You can get a sound clip from
http://www.cdnow.com/cgi-bin/mserver/SID=1165911097/pagename=/RP/CDN/FIND/al
bum.html/artistid=VENGABOYS/itemid=657496
The bus is going from "New York to San Francisco", but I'm waiting for the
darn thing to reach Seattle.
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Jim Ley |
"Peter Torr (MS)" <Click here to reveal e-mail address> wrote in message
news:e3Vr#TzgBHA.1640@tkmsftngp05...
> There is a suitably silly but infectious pop song called "The Vengabus
(We
> like to Party)" by a group called the Vengaboys. It's about a bus that
is
[Original message clipped]
/al
[Original message clipped]
But they're not Seattle - they're going to Eat Pizza - they tell you
later on the album (presumably I've only heard the singles..)
Jim.
|
|
|
| |
|
|
| |
|
| |
| Peter McMahon |
> One could argue endlessly about this, but compromise is the art of
diplomacy
> (or something like that) and this is pretty good general advice.
Yeah, I guess whatever I say there're always going to be a few people that
totally disagree with me and start flame wars, but I'm positioning the
article as one for people new to .NET, trying to help out with their
language choice decision, so I'll leave it at that.
[Original message clipped]
Ah yes, I remember it. But what's it got to do with the MS copyright notes?
(I automatically assumed it was related since it was on the same line...)
P
|
|
|
| |
|
| |
| |
| Peter Torr \(MS\) (VIP) |
"Peter McMahon" <Click here to reveal e-mail address> wrote in message
news:OuKGR70gBHA.2012@tkmsftngp03...
[The Vengabus]
> Ah yes, I remember it. But what's it got to do with the MS copyright
notes?
> (I automatically assumed it was related since it was on the same line...)
Well I never used to have a "disclaimer" in my signature until they said I
had to put one in. So I put something stupid there to try and ease the pain.
The copyright page is so long that by the time you've finished reading it,
the Vengabus may well have arrived!
I think it's time for a change...
Peter
--
Peter Torr -- Click here to reveal e-mail address -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
|
|
|
| |
|
|
| |
| |
| Peter McMahon |
[Original message clipped]
Lol, very creative. Very creative...
P
|
|
|
| |
|
|
| |
|
|
| |
| Ed Stegman |
I wasn't trying to start a flame war. Sorry if you feel that way. The good news is that you've gotten a lot of good feedback too
think about from everybody. Maybe not all as positive or nicely said [1] as you may have liked, but I think that all in all it's
been an enjoyable and enlightening thread. And it's been more like a few sparks than a flame war.
Keep Smilin'
Ed Stegman
[1] My fault, I'm not good at niceties or sugar coating, even though I am a likeable guy. That is, once you get used to my penchant
for saying exactly what I think without pulling any punches.
"Peter McMahon" <Click here to reveal e-mail address> wrote in message news:OuKGR70gBHA.2012@tkmsftngp03...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Jacob Grass \(MVP\) |
[Original message clipped]
And you are always Smilin' :p
--
Jacob Grass
Microsoft .NET MVP
|
|
|
| |
|
| |
| | | | | | | | | | | | | |
|
