Use of VB or VC in consumer apps
-
I kind of hinted on this topic on another thread but would like to hear all the responses from you Hard Core develoeprs :-) However, what are the pros and cons of using VB or VC in a consumer application, basically, would you as a developer use VB to release an application to the consumer market (let's make the focus shareware type applications or shelf applications) From a consumer point of view, saying they where part of the 90% of users who barely know how to turn on their computer, and use their CD trays as coffee cup holders :-) they wouldn't know the difference between something written in VB or VC, I feel from this aspect it is mostly programmer ego, I would think :-) But not only analyze the consumer end but also as developers, VB offers RAD, great debugging tools, a lot of ActiveX control support. VC supports POWER, threading, etc... But please let me here all you expierenced developer view on development issues with either language. All the applications I have developed professionally have been in house, so I don't know what it is like to respond to user questions, support issues, etc... Basically, let me here your pros and cons on either language on development, debuggging, piracy issues, etc... on using either language for consumer level apps. Thanks (Sorry if my post is incoherent trying to take care of my 4 year old son who is just wriggling around for no apparent reason) Sam C ------ Systems Manager Hospitality Marketing Associates
I used to program my shareware utility "AnyWhere" (then, AnyWhere 95) in VB. For about two years people were forced to download a 2mb install just to use this little tiny app because I had to distribute the vb runtime dlls with the install (You almost can't get away with not shipping the dlls. End users don't understand dll-hell and would rather throw your app away than hunt down runtime dlls). Most people just passed it up. I had been toying with the idea of using C++ for quite a while, but VC didn't have a built in "directory tree" like VB. Eventually, I broke down and coded it. Statically linked, the entire thing came out to around 180k. I saw 120% increase in downloads and a big boost in sales. While many people are using high-speed dsl or cable now, the majority are still on dialup and won't tolerate a large download. In my opinion, VC is the only way to go for shareware. -Mike Stevenson CoderX@liquidmirror.com Owner, Liquid Mirror Software (http://www.liquidmirror.com) Owner, Shareware Junction (http://www.sharewarejunction.com) Owner, Internet Shopping Spree (http://www.internetshoppingspree.com/)
-
I used to program my shareware utility "AnyWhere" (then, AnyWhere 95) in VB. For about two years people were forced to download a 2mb install just to use this little tiny app because I had to distribute the vb runtime dlls with the install (You almost can't get away with not shipping the dlls. End users don't understand dll-hell and would rather throw your app away than hunt down runtime dlls). Most people just passed it up. I had been toying with the idea of using C++ for quite a while, but VC didn't have a built in "directory tree" like VB. Eventually, I broke down and coded it. Statically linked, the entire thing came out to around 180k. I saw 120% increase in downloads and a big boost in sales. While many people are using high-speed dsl or cable now, the majority are still on dialup and won't tolerate a large download. In my opinion, VC is the only way to go for shareware. -Mike Stevenson CoderX@liquidmirror.com Owner, Liquid Mirror Software (http://www.liquidmirror.com) Owner, Shareware Junction (http://www.sharewarejunction.com) Owner, Internet Shopping Spree (http://www.internetshoppingspree.com/)
Thanks for the bit of input Mike, I have always used MFC as a dynamically linked library thinking it would would add a tremendout amount of overhead to distributed code (file size). But 180k is not bad considering you can get a basic MFC skeleton app compiled at about 15-20k in size. That is something I would consider as amicable. (Going to try statically linking the MFC library to some of my sample apps :-) and gauging file size). Sam C ---- Systems Manager Hospitality Marketing Associates
-
Thanks for the bit of input Mike, I have always used MFC as a dynamically linked library thinking it would would add a tremendout amount of overhead to distributed code (file size). But 180k is not bad considering you can get a basic MFC skeleton app compiled at about 15-20k in size. That is something I would consider as amicable. (Going to try statically linking the MFC library to some of my sample apps :-) and gauging file size). Sam C ---- Systems Manager Hospitality Marketing Associates
That is why for my shareware projects right now I use WTL. Most of the same functionality as MFC and no statically linked mfc dlls. Steve Maier, MCSD
-
That is why for my shareware projects right now I use WTL. Most of the same functionality as MFC and no statically linked mfc dlls. Steve Maier, MCSD
Steve, can you post some links to WTL? Mainly something that will describe it I hear a lot about it, but never had time to go indepth with it. In the meantime I'll look on MSDN as well as search this site for information pertaining to WTL. Thanks. Sam C ---- Systems Manager Hospitality Marketing Associates
-
Steve, can you post some links to WTL? Mainly something that will describe it I hear a lot about it, but never had time to go indepth with it. In the meantime I'll look on MSDN as well as search this site for information pertaining to WTL. Thanks. Sam C ---- Systems Manager Hospitality Marketing Associates
There are alot of articles on CP on WTL. Here are a few links off of it. DevelopMentor ClipCode Plus the forums have had alot of talk about it too if you search the old posts. Steve Maier, MCSD
-
I kind of hinted on this topic on another thread but would like to hear all the responses from you Hard Core develoeprs :-) However, what are the pros and cons of using VB or VC in a consumer application, basically, would you as a developer use VB to release an application to the consumer market (let's make the focus shareware type applications or shelf applications) From a consumer point of view, saying they where part of the 90% of users who barely know how to turn on their computer, and use their CD trays as coffee cup holders :-) they wouldn't know the difference between something written in VB or VC, I feel from this aspect it is mostly programmer ego, I would think :-) But not only analyze the consumer end but also as developers, VB offers RAD, great debugging tools, a lot of ActiveX control support. VC supports POWER, threading, etc... But please let me here all you expierenced developer view on development issues with either language. All the applications I have developed professionally have been in house, so I don't know what it is like to respond to user questions, support issues, etc... Basically, let me here your pros and cons on either language on development, debuggging, piracy issues, etc... on using either language for consumer level apps. Thanks (Sorry if my post is incoherent trying to take care of my 4 year old son who is just wriggling around for no apparent reason) Sam C ------ Systems Manager Hospitality Marketing Associates
Just a side note: the Moped vs. Crotch Rocket comparison is not really accurate. Each language can produce very fast code and the best written VB app will be fater than the worst written C++ app. In many ways this is an apples to oranges comparison. Case in point: My wife worked on the site for the Ericsson Open tennis match that was held in March. She programmed the dynamic scoring pages (realtime scores, ~15 sec. turnaround), dynamic draw sheets and other dynamic parts of the site (player info w/ match and score info, upcoming matches, etc.). She programmed this in VB6 on a single cpu Win2K web server and a single cpu SQL 2000 server hosted out of Jacksonville, FL. The dynamic pages were 95% of the site hits, 90% on a single page (the live scoring page). The site served up ~45 million hits over 12 days, with peak usage hitting about 2000 hits/minute. That's not a moped! ;) Would the app have performed better if it were programmed in C++? Probably, but she coded her part of it in six weeks. -John
-
There are alot of articles on CP on WTL. Here are a few links off of it. DevelopMentor ClipCode Plus the forums have had alot of talk about it too if you search the old posts. Steve Maier, MCSD
Thanks I went ahead and looked up some information on this site as well as MSDN. So far WTL looks to be a more abstract replacement for ATL, which I hardly use (another admission to naivety :-) ) But I'm going to delve into it even further and see what more it has to offer. Thanks for the links to the cool sites! Sam C ---- Systems Manager Hospitality Marketing Associates
-
Just a side note: the Moped vs. Crotch Rocket comparison is not really accurate. Each language can produce very fast code and the best written VB app will be fater than the worst written C++ app. In many ways this is an apples to oranges comparison. Case in point: My wife worked on the site for the Ericsson Open tennis match that was held in March. She programmed the dynamic scoring pages (realtime scores, ~15 sec. turnaround), dynamic draw sheets and other dynamic parts of the site (player info w/ match and score info, upcoming matches, etc.). She programmed this in VB6 on a single cpu Win2K web server and a single cpu SQL 2000 server hosted out of Jacksonville, FL. The dynamic pages were 95% of the site hits, 90% on a single page (the live scoring page). The site served up ~45 million hits over 12 days, with peak usage hitting about 2000 hits/minute. That's not a moped! ;) Would the app have performed better if it were programmed in C++? Probably, but she coded her part of it in six weeks. -John
That is what I felt as well, so the speed issue is a mute point when it comes to consumer app development, as end users get more powerful machines then speed is not mission critical. Granted, if it was a process intensive applications, byte/character manipulation, FPU intensive algorithms, etc... performance may be noticed. However, when it comes to simple every day applications which consumer use and buy, checkbook balancer, sound player, etc... Does the speed issue really come into play? My impression from this entire thread, and thanks to all those who participated, is the right tool for the right job! The consumer doesn't care as long as it is within reasonable limits. Sam C ---- Systems Manager Hospitality Marketing Associates
-
That is what I felt as well, so the speed issue is a mute point when it comes to consumer app development, as end users get more powerful machines then speed is not mission critical. Granted, if it was a process intensive applications, byte/character manipulation, FPU intensive algorithms, etc... performance may be noticed. However, when it comes to simple every day applications which consumer use and buy, checkbook balancer, sound player, etc... Does the speed issue really come into play? My impression from this entire thread, and thanks to all those who participated, is the right tool for the right job! The consumer doesn't care as long as it is within reasonable limits. Sam C ---- Systems Manager Hospitality Marketing Associates
well, today i feel a little verbose... i don´t want to start a flamefest, but the old saying "it´s no big deal, pc´s are getting powerful, now we have thz processors and 500gb hard disks" it´s really wrong, because software requirements grow in the same proportion, so, it´s the other way around..."because software is getting bloated people need to buy powerful hardware". There is a law that states this, but i can´t remember it´s name, and to be fair, it not only applies just to vb apps. i don´t know there in the US, but here in Argentina, and i suppose in most countries like mine, end users, small shops and big companies (hey, everybody!) don´t have the budget to upgrade their pc´s every now and then. And almost all of the internet connections are done via 56k modems so for apps delivered via the internet...e.g the other day i was forced to download a 10 megs app from the I.R.S. ( not the one in the US! ) and it was just a wrapper for a thirty field database, a couple of calculations and a printed form. It used to be a 200k Clipper5-like app, but now that is written in vb... Gabriel don´t worry, drink happy (and sorry my english )
-
well, today i feel a little verbose... i don´t want to start a flamefest, but the old saying "it´s no big deal, pc´s are getting powerful, now we have thz processors and 500gb hard disks" it´s really wrong, because software requirements grow in the same proportion, so, it´s the other way around..."because software is getting bloated people need to buy powerful hardware". There is a law that states this, but i can´t remember it´s name, and to be fair, it not only applies just to vb apps. i don´t know there in the US, but here in Argentina, and i suppose in most countries like mine, end users, small shops and big companies (hey, everybody!) don´t have the budget to upgrade their pc´s every now and then. And almost all of the internet connections are done via 56k modems so for apps delivered via the internet...e.g the other day i was forced to download a 10 megs app from the I.R.S. ( not the one in the US! ) and it was just a wrapper for a thirty field database, a couple of calculations and a printed form. It used to be a 200k Clipper5-like app, but now that is written in vb... Gabriel don´t worry, drink happy (and sorry my english )
Touche! You actually made a point I did not even consider. When I came to the company I work for presently their main empahsis was being a data warehouse and all the information was kept in dBase files! They where still using dBase III+ However, it ran fast, and code for it compiled in clipper ran fast and was small as well. Damn, you actually make a really valid point. It's true most people have computers sitting on their desk that is 10-20times more powerful than computers used to land the first people on the moon! Yet, application size does increase can this be due to the complexity of the ever evolving MsOS? What size do Linux applications compile and link to? Does anyone know. That OS is said to be fast and nimble on late 386 early 486 computers? Is there code smaller? Thanks for your input Lemmy, you brought up a point I never considered. Sam C ---- Systems Manager Hospitality Marketing Associates
-
I kind of hinted on this topic on another thread but would like to hear all the responses from you Hard Core develoeprs :-) However, what are the pros and cons of using VB or VC in a consumer application, basically, would you as a developer use VB to release an application to the consumer market (let's make the focus shareware type applications or shelf applications) From a consumer point of view, saying they where part of the 90% of users who barely know how to turn on their computer, and use their CD trays as coffee cup holders :-) they wouldn't know the difference between something written in VB or VC, I feel from this aspect it is mostly programmer ego, I would think :-) But not only analyze the consumer end but also as developers, VB offers RAD, great debugging tools, a lot of ActiveX control support. VC supports POWER, threading, etc... But please let me here all you expierenced developer view on development issues with either language. All the applications I have developed professionally have been in house, so I don't know what it is like to respond to user questions, support issues, etc... Basically, let me here your pros and cons on either language on development, debuggging, piracy issues, etc... on using either language for consumer level apps. Thanks (Sorry if my post is incoherent trying to take care of my 4 year old son who is just wriggling around for no apparent reason) Sam C ------ Systems Manager Hospitality Marketing Associates
I use VB for prototyping and for quick and dirty apps. I would never release a commercial app written in VB for a number of reasons, some of them are valid, some ego. 1) I can tell a VB app just by looking at it. For some reason, it just "feels" different to me, and has some kind of subtle feel to it, this gives me an unconscious negative feeling about the app. I know other programmers probably have the same feeling as well - Chalk it up ot ego I suppose. The reason that it feels different is probably due to the lack of skill of most VB designers, and the ease of which you can design things. Therefore newbie designers tend to make interfaces more complicated because it's not that much work. In VC, a complex interface is more work and you have an incentive to make it simpler. 2) VB is difficult to scale into larger apps. VB doesn't provide a good code management system, and the interface encourages putting code into the UI versus writing business logic. Note that I said "encourages" not "forces". I think it requires a lot more self-discipline as a programmer to create "good" VB code than it does in VC simply by nature of the UI. So, for me, VC takes less effort for large scale projects than VB does, this translates into faster development cycles and is a very real reason for me to not use it. 3) VB *CAN* be used to write commercial quality apps, but most people take the easy route and use data controls and other simple mechanisms which provide a very generic look and feel. I like my apps to have a unique look to them, and go out of my way to make them asthetically pleasing. The more asthetically pleasing it is, the less strain the user will have in using it. I can do this much easier in VC than in VB. VB's "easy" stuff also locks you into a more generic look.