Maximum PC

discuss

Lack of cross platform compatibility. Additionally, many hardened programmers will frown upon you for using so much of other people's code.

I have no real issues with its use for rapidly developed windows applications.

Fail. MONO. http://www.mono-project.com/VisualBasic.NET_support

Are you serious? What does that have to do with VB.NET? You can use code over and over no matter the language, and you are actually a fool if you don't re-use code. There is a reason people release their code, make it available.

Rapid development is the key thing about any .NET language. It is just as viable for windows apps as it is for web apps.

Calm down. lol.

I dont have any issues with it, I'm just speculating why people do. When I say using other people's code - I mean the framework/libraries/thousands of built in functions.

What does it matter whether Microsoft wrote the code or some 3rd party wrote the code? That's like saying you'd be frowned upon for using Java's built in print function, rather than using your own, or someone else's. The only time I would see using the built in function being bad is if it is really buggy (which most of the time it isn't), or if it wasn't fast enough (which will only be an issue in very very high performance apps)

I've never met an IT professional who would agree with that assesment.

Also, I'm not sure whether you're aware of it, but you just omitted the entire open source movement and everyone who has submitted code to an OSS, GPL, APL, or other open license from the category of 'hardened programmer'.



So the C++ STL is not used by 'hardened' programmers?

The Boost library?

Have you seen the library of perl modules availabe from CPAN?

The entire Java API?

Really?

For the OP: VB.Net has pros and cons, just like any other tool.

And, just like any other aspect of IT and computers in general, if there is the possibility of differing opinions, you'll find blowhards, fanboys, and their siblings all loudly proclaiming that their opinions are FACT.

Rather than ask such an inflammatory question, I suggest you try something like: "What would you use VB.Net for?" ... that way, you can ignore the people who scream out 'NOTHING IT SUX0RS' and weigh the advice given to you by those who seem to present a more balanced opinion.

I apologize, my statement was a bit broad.

This summer at work I wrote proprietary program in VB to manipulate XML documents for our learning management system. It didn't take me very long, which I completely owe to .net. However, some built in functions I was using to handle different aspects of the XML were tripping me up. For me, using a function without being able to see the code behind it was like taking a shot in the dark. I also felt documentation was rather vague, maybe I just wasn't reading hard enough. I eventually got it to work (quite well actually), but I don't think it would have taken me much longer to write my own functions to handle the XML file as I needed - and may have been a bit more efficient. I heard Microsoft opened up some of this code to viewing since then, but I don't know. Overall I was happy with the result, and everything worked perfectly.

Honestly when I program in visual basic I feel like I'm piecing together other peoples code, not writing my own.

You do that when you work with Java, with the STL, anything. People reuse code. That is one reason why .NET is successful, it supports rapid development with the libraries.

I have never used the XML libraries 100% as they are, I have always used a custom wrapper that I made to expand those features.

If you had to write EVERYTHING from scratch every time, you would never get anywhere.

Say what? When you write code in VB.NET you're using other people's code. It has to compile to IL (Intermediary Language) and then IL is compiled into Assembly language on the fly.

There's nothing wrong with using other people's code, it can simplify your life. I could easily write exception handlers that will make my day to day simpler, but Microsoft already has Application Blocks, so why reinvent the wheel?

In addition, in Enterprise Development, if I quoted your statement to my Developer Lead, I would easily lose my job.

Then you obviously don't know OOP. The principle behind this is that you shouldn't know how the code works, only that it does what it's supposed to do. Why do you care as to how DataSet.GetXml() works? All you need to know is that when you call it, it returns a string of the DataSet's XML. That's it. You're making life a lot easier.


Go and grab yourself a punch card machine like in the old days. Your code is built on top of other people's works.

The principle that you're describing is black box abstraction which is really seperate from OOP. For example, you don't need to know how a C function like printf() works in order to use it. The critical feature of OOP is that it merged attributes and operations into a single unit. Take a stack for example...



Regarding VB, I've heard a number of people complain about statically linked libraries causing trouble in different versions of the language. I believe this only occurs with pre-.NET VB code though.

I like VB.NET -- except for System.Xml. Those classes don't have very good documentation at all.