«

Abubakar wrote:
> ummm Ladies and Gentlemen, this is not a newsgroup for c# vs vb
> discussions
>

But is a newsgroup for C# discussions, is it not? If not, I beg you a
pardon...

--
Fernando Gómez
www.fermasmas.com

Jeff Johnson wrote:
> ""Fernando A. Gómez F."" <> wrote in message
> news:%...
>
>> VB6 completely sucked
>
> Which is what made it the most popular Microsoft language ever, right?

Yep, but wasn't it the only MS language at the time?

>
> Oh, I almost forgot: bite me.
>
> (Flame on!)

Easy man, we're here to talk. Why did you have to go aggressive?

--
Fernando Gómez
www.fermasmas.com

dgk wrote:
> On Tue, 16 Jun 2009 16:19:59 -0500, "Fernando A. Gómez F."
> <> wrote:
>
>> nak wrote:
>>> pfft! You would not believe how many new articles pop up a year stating
>>> that.
>>>
>>> And more often than not they are written by self righteous C# developers
>>> who think it is a "better" language.
>>>
>> Finally, they've taken the blame out of us, C++ers... LOL
>>
>>> Has Harry rightly said above, Microsoft are improving development of
>>> both C# and VB.NET to the extent that both languages will receive new
>>> features at the same time. It's all horses for courses really, I write
>>> in both C# and VB.NET regularly, and personally I prefer VB.NET.
>>>
>>> So nope... VB.NET is far from being dead.
>>>
>> VB6 completely sucked, but the .NET versions kinda improved the language
> ....
>
>
> I love lines like that. I wrote several apps in VB6 (for a former
> employer) that are running fine today. I know because I still play
> tennis with the old company once or twice a summer. They do exactly
> what they were supposed to do and never crash and never leak memory.
>

So did I. I guess they still run, they did their purpose quite well. VB
had its market share, and it was designed for a specific purpose. In
particular, we used to create the front end in VB and back end
components in C++ with COM.

> I once wrote a voice mail system in VB3 for a 12 step group that had
> no money. It ran, 24 hours a day, 7 days a week, on a 40 mhz 386
> system, no UPS, for 15 years. It used a third party tool called Visual
> Voice from Stylus Innovations.
>
> I remember that it took me about two hours to figure out how VV
> worked, and about two weeks to write the app. I recently was asked to
> do something similar, but the brilliantly simple Visual Voice is no
> longer available. I investigated somethings offering the same TAPI
> functionality with DotNet. Due to the wonderful "object oriented"
> design, it is now much, much more complicated. There's a Phone object,
> and a Call object, and oh, so much more. And, the cheaper version
> doesn't allow you to issue a flash, so you can't do three-way calling
> (that's how the old app would patch through to a volunteer).
>
> The learning curve was staggering because the complexity was off the
> charts. All to do the same stuff as VV did.
>
> I work in DotNet, and have since version 1, so I'm well used to object
> oriented technology. But it isn't always better and this was a clear
> example to me.
>

Perhaps it was a bad design. At any rate, I agree that OO is not always
the better. Each paradigm has to be chosen according to the design goals
of the application involved.

> I always laughed at guys like you, bemoaning how VB wasn't a real
> language because it had a runtime. I guess C# isn't a real language
> because it has this big runtime called DotNet.

Please, re-read my post. I never said it wasn't a real language, that
was your assumption. It was designed for specific tasks and under
specific conditions, as happens with any other language. The thing is,
it had all these hidden features and hacks that made the language
unclean and error-prone. Its paradigm was some kind of hybrid between
structured and OO, yet it didn't allowed truly OO design.

You can write apps with any language, and certainly each project must
choose the proper language and platform according to its design goals,
etc. I did that a long time ago, that's why I wrote VB6 code. And that's
why, when needed, I write VB.NET code (although I don't like its syntax,
which I consider too verbose). But that has nothing to do with language
characteristics, rather more with the framework and the programmer's
skills.

And as for that, from an OO perspective, VB6 lacked several features,
despite being marketed as an OO language. That is why I think VB6 sucked.

Best regards.
--
Fernando Gómez
www.fermasmas.com

Herfried K. Wagner [MVP] wrote:
> ""Fernando A. Gómez F."" <> schrieb:
>> However, the VB version can't be shortened... can it?
>
> I wonder why there should be the possibilty to shorten it.

Nobody said there should be one... IIUC, Neb said that VB was too
verbose (which I agree, but I guess that it is a matter of getting used
to). Rossum's reply implied that C# was also too verbose, just by adding
whitespace. The point of my post was to state that C# does not have to
be verbose, but that VB had to be verbose.

If only because that was one of the original primary design goals for
the language.

> The way the
> property is defined in VB allows for easy extension by adding new
> statements to each accessor's body.
> If I want to see the signatures only, I use the class view or object
> browser instead.

Best regards.

--
Fernando Gómez
www.fermasmas.com

"vanderghast" <vanderghast@com> schrieb:
> Probably doable too in VbNet, the line:
>
>
> public int WhatIsThat { get; set; }
>
>
> ***completely*** defines a perfectly working read/write propery, with
> anonymous variable 'sustaining it', in C#, since version 3.5 of the
> framework (if not before). It is not 'just' the signature. I don't see it
> often used, though, in comparison with the long version., which uses an
> explicit declaration of the local variable (the one capturing the 'value'
> for the set definition and returning what get expect to return), and an
> explicit statement for each get and set access.

Well, I never said that it's the signature only. I just mentioned that I
prefer the long version because it's easier to extend. The long version's
code skeleton is typically generated by a code snippet, including the
backing field.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

""Fernando A. Gómez F."" <> wrote in message
news:...
> Jeff Johnson wrote:
>> ""Fernando A. Gómez F."" <> wrote in message
>> news:%...
>>
>>> VB6 completely sucked
>>
>> Which is what made it the most popular Microsoft language ever, right?
>
> Yep, but wasn't it the only MS language at the time?

Nope, sure wasn't.

Nobody wrote:
> ""Fernando A. Gómez F."" <> wrote in message
> news:...
>> Jeff Johnson wrote:
>>> ""Fernando A. Gómez F."" <> wrote in message
>>> news:%...
>>>
>>>> VB6 completely sucked
>>> Which is what made it the most popular Microsoft language ever, right?
>> Yep, but wasn't it the only MS language at the time?
>
> Nope, sure wasn't.
>
>

Sorry I missed that. Which other languages had MS at the time?
Certainly, C++ is not a MS language... Perhaps you refer to J++?

Best regards.

--
Fernando Gómez
www.fermasmas.com

Timothy Casey wrote:
> "Branco" <branco.medei...@gmail.com> wrote in message
>
> news:4b956516-9ff5-4a14-86ca-...
>
> [SNIP]>And having 3rd parties cast out off the Windows API is great,
> >considering the amount of trouble bad usage of said API and COM has
> >brought to us all in the years before .Net.
>
> [SNIP]
>
> No, it was mostly hackers and malware that caused the most persistent
> problems that weren't already caused by defects in the API and COM
> themselves *- and nearly all of the malware causing these problems got in
> due to slack security settings that allowed the JavaScript, VBscript, &
> ActiveX autoloaders to execute without the user's knowledge or consent.

Yes, but, then, not exactly (IMHO). It's true that the lack of
security in the OS allowed for a really fun ride for hackers, script
kiddies and their neighbour's dog, but the political development of
the Windows API, the different models it had (has) to support to
favour legacy compatibility, etc, well, it seems to me that that
allowed for a lot of damage also, due to friendly fire. I seem to
remember a nasty bug in the GetWindowText API caused by some clever
programmers using the window caption to pass (binary) data around
between running instances of their apps. Programmers (from big
companies like Adobe) went through hoops and jumps and twists to force
Windows behave according to their plans and then there were the
counter hoops and anti-jumps placed by MS to revert Windows back to
its (uh...) "correct" behavior (sorry for not providing factual
references, these are stories I remember reading in my long gone --
stolen, mind you -- MSDN Magazine collection *before* it was branded
"MSDN Magazine").

> As for buggy software, no serious problems here. Back in 1999, I surveyed
> nearly 500 software packages and less than twenty functioned substantially
> as documented. Most didn't function at all, many were pretendware (GUI with
> no other object code), and about 1 in 5 blue screened windows or crashed
> Windows altogether if they were set to run on startup. The Windows 98SE
> operating system that bore the full fury of these tests still runs to this
> day, and is more stable than some WinXP and Vista systems.

That doesn't surprise me a bit, I had my fair share of non-working
commercial applications or the ones that subverted the system in such
a way as to drive it (and me) nuts.

> I might add that third party software is much improved. Fully half of it
> actually works these days and pretendware is much rarer than it was in the
> 90's. Nonetheless if buggy software caused the amount of grief you mention,
> that clunky old Win98SE system of mine would be reduced to a smoking pile of
> blue-screens by now. This is not the case.
<snip>

"Fully half of it actually works" is some statement! =)) It seems we
actually agree. Don't you think that having those bad programmers
working in a more "secure", "rich", "easier to learn" and "accessible"
environment (.Net) may produce better applications? In the meanwhile,
nothing would stop the real bad *ass* programmers from giving us
Proccess Explorer and similar (unmanaged, native, API based, etc)
shining apps.

Here in Brazil we have the expresion "Boi de piranha". It's how you
call the cow that is sent alone as bait to cross the river downstream
so it attracts all the piranhas (really, really bad fish) and allows
for the rest of the cattle to cross safelly upstream. To me .Net is a
boi de piranha for the general programmer. I consider myself a
reasonable to good programmer and I notice that I write better .Net
apps than I write "API based" apps (damn, I just realized I'm a
piranha!)

Best regards,

Branco.

mayayana wrote (responding to a post of mine):
Me:
> And having 3rd parties cast out off the Windows API is great,
> considering the amount of trouble bad usage of said API and COM has
> brought to us all in the years before .Net.

Mayayana:
> * I daresay that whole idea of "get the clowns
> out of the API" is a good example of a cliche
> that's been spread around, and that people have
> picked up without really thinking about it. As the
> marketing experts know, it's very easy to get
> people to accept a premise by simply repeating
> it over and over.

It's certainly a coincidence that this is repeated over and over and
also a cliché, besides being my educated opinion =)))

>
> * When your anti-API statement is scrutinized it's really
> a somewhat illogical thing for a programmer to say. It
> amounts to saying, "I'm happy to be put into a sandbox
> where I can't access the system if that helps to block
> other people who don't know what they're doing."

Well, yes, nicelly put. Of course, nothing is really restraining me
from actually using tools that allowed me access to the API. So, yes,
its a choice I make and I hope others make too, so the guys who "don't
know what they're doing" (API-wise) can come to this bandwagon and
know a little better =D

> * Beyond that there's a profound implication in
> the changes brought by .Net's sandbox. The end result
> of shutting off the real API is the transformation
> of Windows from a platform to a service. The
> security/stability issue is a red herring. (Remember,
> the original idea was that an OS is a "platform"
> that supports software by interfacing with the
> hardware. It's important to distinguish between
> needed security improvements on the one hand,
> and radical redefiniton of the product on the other.)

I don't see the problem in Windows turning (evolving?) from platform
to service. That's actually what Windows -- and it's API -- allways
longed to be (IMHO). This role of providing a thin abstraction layer
between application and hardware was never played very well by Windows
since its inception, and I doubt it defines this OS as we know it.

> *...And speaking of cliches, what's with all the
> badmouthing of COM? I don't mean just what you
> said. I've heard derision of COM for years. But I don't
> find any problems with it. It's been great for scripting.
> And Windows itself is still extensively COM-oriented,
> while being almost entirely free of .Net.

Yeah, I see your point, but don't get me wrong: I'm not bad mouthing
COM. My opinion is that COM was a fantastic breakthrough in
application interoperability, a really visionary and radical approach
(yes, there was CORBA, but COM actually *existed*, contrary to CORBA).
Trying to learn COM made me a better programmer, really =))

But COM for the masses had an intrinsic complexity that no tool
(besides VB) would easily circumvent (C++ smart pointers were
"discovered" too late in the game when there was a lot of damage
already done by programmers forgetting to call AddRef/Release
appropriately). Thus there were lots of badly written COM application
(or so the legend says). I remember that .Net exploded on our faces
just when COM was preparing to turn into COM+. For a few months MS' PR
was "COM+ this" and "COM+ that", "COM+ is the wave of the future", and
then *boom* there was .Net. It really seemed to me that a political
tour de force had ensued inside Microsoft and this new platform (lol
sorry, "service") got the upper hand, maybe because it provided
answers to COM "faillures" that outshone COM's benefits (DLL hell,
registry bloat, referene counting, anyone?)

The merit of .Net, in my opinion, is to provide this really rich and
*likable* environment (for a programmer such as myself) while it
allows the OS to continue its regular existence: as you notice,
Windows is vastly COM-based still.

>
> >> But people are writing Windows software with a 200 MB
> >> dependency
>
> *The "dependency" part is really relative, don't you aggree?
>
> * Ultimately, sure. But a basic XP system is about 1GB.
> .Net2 is about 88 MB unpacked, by my measure. As I
> understand it, .Net3 is over 200 MB. It's adding some
> 25% to the OS. So where do you draw the line with
> what's "relative"? Would you install a 2 MB Java program
> if you knew it was going to require a 200-300MB VM?
> I wouldn't.

I'd install Vista, which would change the contribution of disk usage
from the .Net libraries to mere 2% of the OS =)))

I'm just kidding of course. Or maybe not. Vista takes up 10GB of space
in a regular install, if I'm not mistaken. What drives us to install
such a monster? Even the slim and fat-free (yeah, right) XP seems huge
if we compare its 1GB (I'm trusting your numbers, here) to, say, a
functional Linux install that fits what? 100 MB? And then came World
of Warcraft. Damn, that thing alone is 15GB!!

> * *We're talking here about whether .Net is a sensible
> choice for desktop software -- not just whether some
> people will be agreeable to having the .Net runtime
> installed. There are issues of bloat, security, possible
> instability, etc. It's not just a question of how long it
> takes to download the package.
>
> * If the "relative" bloat of the runtime were not an issue
> then .Net installers wouldn't be designed to sneak out
> and download the runtime without even asking the person
> installing the software.
>
> * Then there's also the general unsuitability in the design
> of .Net for Windows software. If you read Mark Russinovich's
> piece from the link you'll see that his whole point is the same
> point that I'm making. (And I suspect that most of the people
> reading this also agree, and are probably using .Net not
> for Windows software but rather are using it where
> they might have formerly used Java -- server-side or for
> producing corporate intranet web services.)

I'm using VB.Net to write corporate apps that are used in a daily
base. It replaced both VB6 and Delphi as the default development
platforms here, and suffocated to death (I really like this image,
considering the people involved) a movevement that wanted to migrate
all our development to Java. =))

What I see is: .Net is kind of fresh still, and it allowed a freedom
in development that really shines if compared to the alternatives. Is
there bloat? yeps, but this is good fat, not bad fat, and comes mostly
from new services and tools mayde available to you. Is there
instability? uh, I really hardly see it (there was a 3rd party app
once that failed to install with no elucidative message. I installed
the 3.0 redist -- the machine had only 2.0 -- and everything worked
without a glitch). Lack of security? In C# maybe. I suppose it's
easier to write a faulty app (security-wise) in C, unmanaged C++ or
unmanaged C# than to write a faulty managed .Net app (I may be wrong,
of course, we VB programmers once had a history of circumventing the
system).

Best regards,

Branco.

"Fernando A. Gómez F." <> wrote:
>
>Sorry I missed that. Which other languages had MS at the time?
>Certainly, C++ is not a MS language... Perhaps you refer to J++?

By that definition, Basic is definitely not a Microsoft language. It
predates Microsoft by a decade.

The only truly Microsoft language is C#.
--
Tim Roberts,
Providenza & Boekelheide, Inc.