C++ vs. "language-oids" like VB
-
I am currently working (with another colleague) on a VB6 project that relies mostly on a database (our company does outsourcing). We are now doing all the code-patching (because I just cannot call it programming) required to add new features and replace bugs ;P. As I came from C++, I was strongly impressed by the akwardness of working in VB -- you can't go very low, cause the language won't let you and you can't fly very high, because the language won't back you up. You don't have pointers so you won't get hurt, you poor baby. All low level code is best avoided -- it's terribly slow; VB just wasn't designed for this. Buy a component to solve the problem. The classes in VB are just structures with functions. Generic programming is limited to doing a sort function on built in types by passing variants. Generating collections with class builder seems like stone-age when you have the STL containers. The "visual" part that VB people are so thrilled of is just underpowered, and I had to rely on WinAPI code (which is harder to use in VB, partly because you have to generate your own function definitions). I could not use threads. (I understand this is implemented in VB.NET, but frankly I don't plan to learn more VB.) To build your own controls, starting from scratch, is purely masochistic (the only case when it can be easy is when you don't care how it looks & feels). In fact, I found that almost everything besides assembling components akward and ineficient to do. There are lots of fashionable "languages" at the moment, but I think that all of them have similar problems -- ineficiency in low level code and not enough support for good design. Why would anybody choose them? Who are those "C++ developers that did VB (or whatever) and didn't want to go back" that all VB book-writers talk about? How do these languages cut down development times? (It is my opinion that, at least in the long run, they actualy don't.) I know most of you guys on Code Project think more or less the same. What I am looking for is an article that goes beyond the myths of "rapid development" and give you the real figures. Perhaps you guys know one (or even better, write one). Florin Crisan
-
I am currently working (with another colleague) on a VB6 project that relies mostly on a database (our company does outsourcing). We are now doing all the code-patching (because I just cannot call it programming) required to add new features and replace bugs ;P. As I came from C++, I was strongly impressed by the akwardness of working in VB -- you can't go very low, cause the language won't let you and you can't fly very high, because the language won't back you up. You don't have pointers so you won't get hurt, you poor baby. All low level code is best avoided -- it's terribly slow; VB just wasn't designed for this. Buy a component to solve the problem. The classes in VB are just structures with functions. Generic programming is limited to doing a sort function on built in types by passing variants. Generating collections with class builder seems like stone-age when you have the STL containers. The "visual" part that VB people are so thrilled of is just underpowered, and I had to rely on WinAPI code (which is harder to use in VB, partly because you have to generate your own function definitions). I could not use threads. (I understand this is implemented in VB.NET, but frankly I don't plan to learn more VB.) To build your own controls, starting from scratch, is purely masochistic (the only case when it can be easy is when you don't care how it looks & feels). In fact, I found that almost everything besides assembling components akward and ineficient to do. There are lots of fashionable "languages" at the moment, but I think that all of them have similar problems -- ineficiency in low level code and not enough support for good design. Why would anybody choose them? Who are those "C++ developers that did VB (or whatever) and didn't want to go back" that all VB book-writers talk about? How do these languages cut down development times? (It is my opinion that, at least in the long run, they actualy don't.) I know most of you guys on Code Project think more or less the same. What I am looking for is an article that goes beyond the myths of "rapid development" and give you the real figures. Perhaps you guys know one (or even better, write one). Florin Crisan
I think you have answered your own questions. :-) Maybe you should be the one writing the article. VB originates from a successions of legacies. I'm guessing Basic - > AdvBasic -> MSBasic -> Windows Basic-> VB 1.00. The guts is it was never designed to be a one stop solution for everything. It has gone from a 32k usage assembler language to a compiled multithreaded development environment. C++ has evolved simarly but hasn't gone through such radical changes of intention. Regardz Colin J Davies
Sonork ID 100.9197:Colin
Warning Link to the minion's animation, do not use. It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
-
I am currently working (with another colleague) on a VB6 project that relies mostly on a database (our company does outsourcing). We are now doing all the code-patching (because I just cannot call it programming) required to add new features and replace bugs ;P. As I came from C++, I was strongly impressed by the akwardness of working in VB -- you can't go very low, cause the language won't let you and you can't fly very high, because the language won't back you up. You don't have pointers so you won't get hurt, you poor baby. All low level code is best avoided -- it's terribly slow; VB just wasn't designed for this. Buy a component to solve the problem. The classes in VB are just structures with functions. Generic programming is limited to doing a sort function on built in types by passing variants. Generating collections with class builder seems like stone-age when you have the STL containers. The "visual" part that VB people are so thrilled of is just underpowered, and I had to rely on WinAPI code (which is harder to use in VB, partly because you have to generate your own function definitions). I could not use threads. (I understand this is implemented in VB.NET, but frankly I don't plan to learn more VB.) To build your own controls, starting from scratch, is purely masochistic (the only case when it can be easy is when you don't care how it looks & feels). In fact, I found that almost everything besides assembling components akward and ineficient to do. There are lots of fashionable "languages" at the moment, but I think that all of them have similar problems -- ineficiency in low level code and not enough support for good design. Why would anybody choose them? Who are those "C++ developers that did VB (or whatever) and didn't want to go back" that all VB book-writers talk about? How do these languages cut down development times? (It is my opinion that, at least in the long run, they actualy don't.) I know most of you guys on Code Project think more or less the same. What I am looking for is an article that goes beyond the myths of "rapid development" and give you the real figures. Perhaps you guys know one (or even better, write one). Florin Crisan
VB was the beginning of RAD. It introduced some important new concepts which are now standard in almost all new languages. However, it didn't take them far enough, and it skimped in some crucially important places. One of those is pointers, another is inheritance. Isn't inheritance a very important part of fast object-oriented programming? I think the new concepts in .NET carry the VB concepts to where they should be - instead of very limited function pointers, you have delegates, the forms are easy to work with but they have a whole lot more power.
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma Gandhi -
VB was the beginning of RAD. It introduced some important new concepts which are now standard in almost all new languages. However, it didn't take them far enough, and it skimped in some crucially important places. One of those is pointers, another is inheritance. Isn't inheritance a very important part of fast object-oriented programming? I think the new concepts in .NET carry the VB concepts to where they should be - instead of very limited function pointers, you have delegates, the forms are easy to work with but they have a whole lot more power.
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma GandhiYou're forgetting templates -- I haven't heard of templates in VB.NET. I know they are not necessarily an OOP concept, but generic types (classes) and functions are a very powerful concept. So, how powerful are those new additions in .NET? (I had to learn VB for this project; it should have been ported to .NET, but the management decided it would be too expensive to do it at this time -- so I didn't bother to learn .NET. However, my colleague had to learn .NET for the web client, and he told me it's still no big deal.) And most important: you mention RAD -- which is a good thing, especially to the management. ;P I think this is the merit of the tools (the Visual in VB); you have these kinds of tools for C++. How does the language make you "more productive"? (I hate this productivity cliche.) Florin Crisan
-
You're forgetting templates -- I haven't heard of templates in VB.NET. I know they are not necessarily an OOP concept, but generic types (classes) and functions are a very powerful concept. So, how powerful are those new additions in .NET? (I had to learn VB for this project; it should have been ported to .NET, but the management decided it would be too expensive to do it at this time -- so I didn't bother to learn .NET. However, my colleague had to learn .NET for the web client, and he told me it's still no big deal.) And most important: you mention RAD -- which is a good thing, especially to the management. ;P I think this is the merit of the tools (the Visual in VB); you have these kinds of tools for C++. How does the language make you "more productive"? (I hate this productivity cliche.) Florin Crisan
Florin Crisan wrote: And most important: you mention RAD -- which is a good thing, especially to the management. :laugh: I find RAD to be helpful, but generally not VB6's version. RAD helps you to concentrate on your individual app, not on the low-level stuff. But in many ways VB classic got in the way of this anyway. By the way, you can make VB6 do almost anything you want, but as I've learned, you end up taking so much time "hacking" VB that you take more time than you would've just using a non-RAD programming language. For the most part, this is gone in .NET (by the way, I hardly use VB.NET - mainly use C#). Florin Crisan wrote: You're forgetting templates -- I haven't heard of templates in VB.NET At least in the SharpDevelop IDE, there are templates, and you can even make your own.
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma Gandhi -
You're forgetting templates -- I haven't heard of templates in VB.NET. I know they are not necessarily an OOP concept, but generic types (classes) and functions are a very powerful concept. So, how powerful are those new additions in .NET? (I had to learn VB for this project; it should have been ported to .NET, but the management decided it would be too expensive to do it at this time -- so I didn't bother to learn .NET. However, my colleague had to learn .NET for the web client, and he told me it's still no big deal.) And most important: you mention RAD -- which is a good thing, especially to the management. ;P I think this is the merit of the tools (the Visual in VB); you have these kinds of tools for C++. How does the language make you "more productive"? (I hate this productivity cliche.) Florin Crisan
Florin Crisan wrote: So, how powerful are those new additions in .NET? What I like about .NET in general is: *The class library (of course, this isn't a lang. feature, but all the same...). I was working on one in VB, but it took so long... *Delegates! This is instead of dangerous function pointers or clumsy sinks. *multi-threading made easy! cross-thread marshalling is accomplished by using Invoke or BeginInvoke. You can also easily find out whether you need marshalling *At runtime, you can switch event handlers or add a new one (part of the delegates side of things) *Better support for UDTs than COM has *The latest window features built into the system.windows.forms form *classes built in multiple languages can be put in the same assembly *handling functions built into data types (.ToString, .Append, .Length, etc) What I don't like about .NET in general is: *have to re-write all my API declares *Can't build a stand-alone app *built-in scrolling support is lousy (but I can easily implement it myself) What I like about C# is: *The power of C++ with the ease of VB *No more having to figure out whether to use "->", ".", or "::" to reference members *The power of pointers without the hassle, even in "safe" mode (btw, you can use pointers in C#, but only in "unsafe" mode - but the "ref" statement usually suffices) What I don't like about C# is: *no "with" statement *case sensitivity (you have this in C++, but not in VB)
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma Gandhi -
Florin Crisan wrote: So, how powerful are those new additions in .NET? What I like about .NET in general is: *The class library (of course, this isn't a lang. feature, but all the same...). I was working on one in VB, but it took so long... *Delegates! This is instead of dangerous function pointers or clumsy sinks. *multi-threading made easy! cross-thread marshalling is accomplished by using Invoke or BeginInvoke. You can also easily find out whether you need marshalling *At runtime, you can switch event handlers or add a new one (part of the delegates side of things) *Better support for UDTs than COM has *The latest window features built into the system.windows.forms form *classes built in multiple languages can be put in the same assembly *handling functions built into data types (.ToString, .Append, .Length, etc) What I don't like about .NET in general is: *have to re-write all my API declares *Can't build a stand-alone app *built-in scrolling support is lousy (but I can easily implement it myself) What I like about C# is: *The power of C++ with the ease of VB *No more having to figure out whether to use "->", ".", or "::" to reference members *The power of pointers without the hassle, even in "safe" mode (btw, you can use pointers in C#, but only in "unsafe" mode - but the "ref" statement usually suffices) What I don't like about C# is: *no "with" statement *case sensitivity (you have this in C++, but not in VB)
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma GandhiWhat do you mean exactly by The power of C++ with the ease of VB? The new additions in .NET look OK as you put them -- but I didn't get to use .NET until now (I know, I know, shame on me). But those are platform stuff, you can use them from C++, can't you? I tend to have the impression of "underpowered" for all "RAD" languages, including, but not limited to, VB (whatever version), C#, Java etc. Does this thing really matter? What exactly is it easier to do in these languages than in C++? Florin Crisan
-
What do you mean exactly by The power of C++ with the ease of VB? The new additions in .NET look OK as you put them -- but I didn't get to use .NET until now (I know, I know, shame on me). But those are platform stuff, you can use them from C++, can't you? I tend to have the impression of "underpowered" for all "RAD" languages, including, but not limited to, VB (whatever version), C#, Java etc. Does this thing really matter? What exactly is it easier to do in these languages than in C++? Florin Crisan
Well, .NET is a whole new concept, but still C# and C++ can be compared in many ways. I suggest that you take a good look at the C# documentation, and decide for yourself. Also, if you really think you need everything you are used to in C++, you might look into C++ .NET. The power of C++ with the ease of VB *you get inheritance, bit-shift operators, overloaded functions, *You don't have to handle the re-sizing/allocation/etc of strings BUT You still have the capability of appending, replacing, etc without a lot of re-allocation. you can access each character of a string like you would w- a C++ char array you can either use the escape char system of C++ for string literals, or the VB way. *Delegates give you the power of function pointers without the dangers. *arrays - safe like in VB, but you get to initialize the values like in C++: string[] names = new string[3] {"Matt", "Joanne", "Robert"}; you also get jagged arrays *quick type conversions: a=(string)b; OR a=b.ToString(); OR long num = Convert.ToInt64(s); *property procedures *you get most of the C++ operators, and the ones you don't get have replacements: +=, ++, --, -=, *=, ..... Some things that C# doesn't have that C++ has: *bit fields *optional arguments - use overloaded functions instead *pointers - but you can use them in "unsafe" mode, and I do this all the time. Also, you can do most of what you do with pointers, without them. Some things that C# has that C++ does not have: *foreach *delegates *typeof *is - compares two object vars to see if the point to the same object *automatic XML documentation
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma Gandhi -
Well, .NET is a whole new concept, but still C# and C++ can be compared in many ways. I suggest that you take a good look at the C# documentation, and decide for yourself. Also, if you really think you need everything you are used to in C++, you might look into C++ .NET. The power of C++ with the ease of VB *you get inheritance, bit-shift operators, overloaded functions, *You don't have to handle the re-sizing/allocation/etc of strings BUT You still have the capability of appending, replacing, etc without a lot of re-allocation. you can access each character of a string like you would w- a C++ char array you can either use the escape char system of C++ for string literals, or the VB way. *Delegates give you the power of function pointers without the dangers. *arrays - safe like in VB, but you get to initialize the values like in C++: string[] names = new string[3] {"Matt", "Joanne", "Robert"}; you also get jagged arrays *quick type conversions: a=(string)b; OR a=b.ToString(); OR long num = Convert.ToInt64(s); *property procedures *you get most of the C++ operators, and the ones you don't get have replacements: +=, ++, --, -=, *=, ..... Some things that C# doesn't have that C++ has: *bit fields *optional arguments - use overloaded functions instead *pointers - but you can use them in "unsafe" mode, and I do this all the time. Also, you can do most of what you do with pointers, without them. Some things that C# has that C++ does not have: *foreach *delegates *typeof *is - compares two object vars to see if the point to the same object *automatic XML documentation
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma Gandhi"is" checks to see if an object is of a certain type to compare two object references, you use ==