Making an Argument Against Using Visual-Basic? 690
ethan_clark asks: "I work for a small company (< 10 employees) as a software engineer. The company got its start with a software product written by the owner in VisualBasic. He hired me to assist in rewriting the software – only catch is, he's stuck on having it re-written in VisualBasic. This scares me, but I honestly can't make a good argument against VB because I'm not familiar enough with it.
So my question is twofold: I am looking for some confirmation to my suspicion that VB isn't the greatest language for large projects; and If VB isn't good, arguments against using it. If it is good, what arguments would you use to argue for it (for my sake)?" If you are going to argue against a language, it is best if you do so after you become familiar with it so that you can argue fairly on its merits and deficiencies. VisualBasic, like just about every other language, has its place. For the sake of discussion however, what tasks would VisualBasic not be suited for?
Can .Net Provide a Vehicle for alternatives? (Score:5, Insightful)
Do the
That's the way I helped a Fortune 500 company start adopting Linux back in 1998... the friendly and subversive way!
As for the tasks VB are not suited for (again, I only know VB6, not VB.Net) the biggest glaring omission in my experience was the lack of decent Regular Expressions, or Hash Tables / "Dictionaries"--unless you link to the VBScript/IE6 library like everyone used to. On the other hand, there are IMOHO problems with languages like Perl that make them bad for a number of solutions, but that hasn't stopped nutty fanatics from treating them like "golden hammers".
While I'm writing disclaimers, there are a number of commercial applications out there written entirely in VB. In all cases I've observed, they "evolved" out of a simple and useful app and fell into being examples of the most counter-intuitive user interfaces and over all "kludginess".
Re:Can .Net Provide a Vehicle for alternatives? (Score:5, Informative)
.NET simply provides the programmer with the ability to program in the language they either know better or in a language that seems better suited to the job, without taking a performance hit, since they all compile to the same intermediate language.
.NET 2.0 takes this to even more extremes, in that, more toolbox items are available and virtually all of the components are data aware. Also, Visual Studio 2005 Pro includes a development IIS instance and SQL Server 2005 Express is included.
Check out the Visual Studio Website [microsoft.com] for more information.
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Funny)
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Informative)
That is not always true. Unless you put the following line in your AssemblyInfo file your class library, it is likely the resulting byte code can not be used by other
[assembly: System.CLSCompliant(true)]
Visual Studio 2005 Pro includes a development IIS instance
It's actually Cassini. The only real nice thing about this is that Cassini is much lighte
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Interesting)
I don't think I have ever had to worry about a graphics card for 2D widget blitting. Why is VS2005 different? I have also noticed this same slowness in another large
6) Partial classes?
Don't use them if you don't want.
It is not me that is creating these freaks of nature, but rather VS2005 GUI editor. It uses these partial classes for code behi
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Informative)
By the way, in terms of speed
Re:Can .Net Provide a Vehicle for alternatives? (Score:4, Insightful)
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Insightful)
90% of laptop owners
80% of windows users
Even current integrated graphics won't cut it with Vista... And really, how many computers will have been purchased between now and Vista? I'm guessing that the amount of computers purchased that have adequate Video Cards to run Aero will be less than half, so this does little to really change the ratios.
You're right, computers without amazing video cards will be able to run Vista, but the whole point of this thread
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Insightful)
Re:Can .Net Provide a Vehicle for alternatives? (Score:5, Insightful)
Where the true advantage of the
Im a C# programmer at heart, but the existing codebase here is VB. I migrate it to vb.net as needed and all new stuf is coded that way.
vb.net is not the same old vb6 that you grew up with. It now has all the advantages of C#, but with the VB syntax. When your employer is clueless about
Re:Can .Net Provide a Vehicle for alternatives? (Score:5, Informative)
.NET languages are all pretty much interoperable, so long as you make sure to build your assembly as CLSCompliant [msmvps.com] (which may limit usage of some language features). The main problem is that VB.NET is quite a bit different from VB6. For someone who's only ever done VB code, it's easier to learn VB.NET than C#, but for everybody else you may as well start directly with C#. In the past, I'd have advocated building your UI with VB and calling C++ COM objects for any heavy lifting. Now, I'd recommend you go C# and do everything there.
You get regular expressions and collections with .NET (though not as many different collections as in Java, unless you bring in the J# assemblies for your project). You also get generics, anonymous methods (anonymous delegates, lambda functions, closures, whatever you want to call them), and quite a bit more cool stuff, though I have no idea how well that's exposed through the VB.NET language. Even cooler than that, you could subversively write modules in a functional language like F# [microsoft.com] (a dialect of ML) and nobody'd know the difference from their VB.NET or C# environments. (yeah, you can do that with Java as well.)
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Insightful)
Any user interface, regardless of language, should be usability tested at every major release. A lot of developers are horrible at adding interface widgets because they're too wrapped up in the solution rather than the proble
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Funny)
Re:Can .Net Provide a Vehicle for alternatives? (Score:4, Informative)
Just FYI about
VB.NET directly supports dictionaries, even by using generics.
It also suports reasonably powerful regular expressions via the System.Text.RegularExpressions namespace.
VB's not that bad (Score:5, Informative)
I have one customer that specs VB.NET for all their apps. After getting comfortable with it there's just no reason for some of the comments here. VB isn't "easier" than C#, just different. If you're a bad VB programmer, switching to C# isn't going to make you a better one.
My opinion is that a lot of bias against VB stretches back to the day when it was not considered a "real" programming language. But it's grown up and turned into a capable language and if that's what the customer wants, there's no need to try to sell them on C#.
Re:Can .Net Provide a Vehicle for alternatives? (Score:3, Insightful)
I've written in both, the main advantage C# has is that it is less verbose but that doesn't make it better, it probably makes it more difficult for inexpierenced programm
Re:Got nothing better to do? Troll (Score:3, Insightful)
Yes, and my experience is that it takes them a long time learn, and they're not very good with it when they're done.
The reason VB developers wouldn't learn C# is probably a productivity issue, rather than not being able to learn the language
No, the reason VB programmers wouldn't learn C# is that they're generally not very good developers, and it takes them a long time to learn new languages.
C# is more like Jav
Re:Got nothing better to do? Troll (Score:5, Insightful)
"Every language does have it's place, but there are perceptions tha can raise and lower a language's value ON YOUR RESUME"
The perception itself does not raise or lower the actual value
Story:
Way back when, in the DARK days of DOS programming, and when most if not all of Microsoft's support was done on CompuServe, one of the forums was called "MSLANGS" - In there, among others, were the C form, and the PDS form (read that as Pro Compiled BASIC). Both generated OBJ files, for the identical linker (MASM used the same linker) - and in fact, if you wrote code that did NOT involve stings, and used the equivilent control structures, you got identical OBJ files. The big differences were pointers in C, and BSTRS in Basic. Now, as a LOT of business code then, as now, was string related, the string functions that were in basic allowed you to develop certain classes of application a LOT faster than the C guys. They would slag on us for "BASIC", and we'd smile, underbid them, and produce the work in less time. Yeah, the perceved value for a "BASIC" programmer was lower - but often the client didn't care what it was written in - only what the application did, how it performed, and how it was going to be maintained. So, which tool was more valuable? If I can underbid you by 10%, but do the job in 25% less time.... (hence, get more contracts...)
Languages are tools - pick the tool for the job.
Of course, sometimes part of the "Job" is your OWN personal development - then perceptions count for a lot
Back then, it was HARD for a BASIC programmer to get a job - VERY hard. It was niche - BIG time (IEEE-488 aka GPIB aka HPIB instrament control was one - the one I was in). Even if you had a CS degree, folks looked down at you. Then one day, Microsoft came out with VB 1.0. I ordered my copy that day. The world changed. Withing a year, the folks who KNEW BASIC (the old DOS stuff) were in demand, as we actually had a clue. I've never looked back. I've done some C, some light C++, enough MASM to have shipped a bunch of old DOS drivers to clients, and now C# and others.
My advise to anyone reading? Don't be a lanuage snob, but also, don't forget, there are language snobs out there, perceptions DO matter, and don't let yourself get boxed into a corner. Evolve or die
Re:Got nothing better to do? Troll (Score:3, Interesting)
Call me old fashioned, but when a line with two statements on it has a different meaning than two statements on seperate lines, it strikes me as odd.
Probably most of this is a result of people who seek out VB.net because it is 'easier' rather than inherent in the language, so it might be more
Which version of VB is it? (Score:5, Insightful)
Re:Which version of VB is it? (Score:5, Insightful)
This is the *huge* issue, that will make or break your decision.
If it's VB6, run for the hills. It's end-of-lifed.
VB.NET is a great place.
You'll be able to leverage all of the
You'll be able to mix-n-match C# code.
There is continuing investment in the language and tools. There's already a page dedicated to VB9 [microsoft.com] with some awesome features I wish were going to be in C#.
If you're betting on a Windows environment, VB.NET is a great place to be.
Your first choice should be "Are we going to bet on
If the answer is yes, VB.NET vs. C# vs. Managed C++ is a secondary call.
Re:Which version of VB is it? (Score:3, Insightful)
That has to be somewhere in the manual of permanent employment as one of the tricks of the trade... "introduce technology that no one else understands so that you're the only person who can maintain it". If the original poster's boss has any brain cells, he'll refuse to have any C# lying about unless he has more than 1 programmer capable of working with it.
Daniel
Re:Which version of VB is it? (Score:5, Funny)
It's not entirely useless; I'm using my three VB6 MS books as a stand for my monitor to get to the right height. The only downside is that I continuously have 'VB 666' staring at me in the face.
Re:Which version of VB is it? (Score:5, Insightful)
This is a critical point, and bears on the way the boss is making the decision. Professional programmers don't like VB because, as a language, it is not very good. But that doesn't mean the boss is being stupid. No. He's actually making the decision using a fairly reliable algorithm: repeat what has worked in the past.
The problem with this algorithm is that it can fail when the future is sufficiently different from the past. As in the platform being not supported anymore.
VB is not so much a bad language as an obsolete (and mediocre) one. But it isn't just a language -- it's an IDE and an operating environment with widgets and libraries and so forth. And in the other aspects that VB is relatively strong for some kinds of tasks. Visual Basic is Visual -- it really encourages you to think and work in terms of concrete visual objects. For a professional programmer, this is higly limiting, because a lot of problems you deal with aren't visual. Limiting isn't necessarily bad if the problem you're working on falls squarely in the middle of them.
You just don't do complex programming in VB. It's perfectly adequate for simple form based clients to a client/server style database backed applications that lack demanding scalability or support requirements. Most VB programs consist mostly of short event handler scripts around form components. The tight coupling of business logic to UI code is anethema to systems programmers. Clearly it is bad architecture, but the purpose of architecture is to reduce the cost of development and maintenance. In these kinds of applications, being able to get the application working quick enough outweighs any architectural drawbacks.
I think the sweet spot for you would be C# and Visual Studio. The way you lay out forms and such is the same as in VB 6, and these days learning how the bits is the real work on the learning curve, not the language. Forms in C# hava a Java/Swingish kind of MVC pattern, but it's really only one new design pattern you need to deal with. Once he's got the hang of it the boss can pretty much see a one to one correspondence between bits in the old VB app and a new C# app. You could go with VB.NET, but really for the kind of cmdbtn_click scripts of a typical VB app, there is no reason a VB6 programmer couldn't look at, understand, and maintain the same script in C# without having to swallow the whole C# enchilada.
And C# is a modern, well designed language. This means that if you have a piece of work that is sufficiently complex to worry about reuse, maintainability, scalability or other advanced requirements, you can address them properly. Many of the best practices and frameworks from Java have their counterparts in C#, such as O-R mapping, unit testing and so forth.
IN any case, you're in for tough sledding Dealing with a guy who has built a business where he does everything is difficult. These guys seldom can make the leap to creating a company that is bigger than they can handle personally. Even if they understand change is necessary, and that they can't do it themselves; even if they hire people to create change, they usually end up fighting change tooth and nail. Often they undermine the efforts of anybody to do anthing independently, such as book keeping or filing. Everybody is running a three legged race with the boss, and since he only has two legs, there's a lot of waiting around for him to catch up so he can toss all your recent work into the crapper.
Underneath this behavior is fear and beneath fear is insecurity and ego protection. Probably against all expectations, this guy has made a reasonable success so far; he has customers who send him enough money that there's more work than he can do himself. And since he didn't get where he is by saying no, he hired more people. But he'd probably be happier if it was just him. He may not know how to supervise people or even run a bu
Pay the piper, call the tune (Score:3, Insightful)
For the boss dude, the company and its product is his life and he is stuck with what happens to it. He hired you because, well, you could be off doing your own business and your own software package in whatever language you desire, but you decided to work for The Man, and for all you know and all the boss dude knows, you could be a life-long partner in the business or you could be here toda
Re:Which version of VB is it? (Score:3, Insightful)
Stay the hell away from managed C++ if you can avoid it. There is precious little reason to use C++ unless you intend to do something unsafe such as call Win32 or other unmanaged code so managed C++ is something of a misnomer. The only reason to use it in my opinion is if you have some legacy C++ that you need to abstract behind an object and expose into .NET land.
It's also worth pointing out that if ever the day arrives where Mono
Re:Which version of VB is it? (Score:4, Insightful)
In all fairness, this differs from the old VB runtime just how?
Currently there are 3 versions of the .NET Framework. v1.0, 1.1 and 2.0. I would assume any newer Windows installation at least comes with v1.1 by default, which most current .NET-applications depend on. Oh noes! I have to click "Windows update" and wait 30 seconds! My, oh my.
As for "refusing to install it". How zelous can you get? Do you refuse to install Sun's JVM as well? Yes, I see you think java ain't a real platform as well. Do you refuse to install perl or php when you write web-applications as well?
Now let me tell you about the real world: If an application does useful stuff, and uses a framework that cut development time to a tenth, that is not just a real application, but anyone remotely interested in costs will find that framework great. So will probably most realworld developers who care about getting stuff done without wasting their time on rewriting the same generic code 50 times per project.
Since it sounds like this is a product that will be used outside of a controlled environment (ie withing a specific company, you know what you are running the app on), then you are asking for a technical support nightmare.
"Install the .NET Framework version 2.0 available at Windows Update or download it from this link [microsoft.com].". Yeah, that was, like, you know, the worst of technical support nightmares.
I know this is slashdot, but I can't believe this zealous rubbish got mod'ed "Insightful" and not "Troll".
Give us a bone! (Score:5, Informative)
Picking the right tool really requires a better understanding of your project.
Beyond the general problem, what are your expectations for reliability/testability, schedule, maintainability, expandability, performance?
If the owner is the only one qualified to improve the product, Visual Basic might be a good choice.
I once worked for a company that had an extremely accurate satellite propagation program. The problem was it was written in GWBASIC and did not run in a text-only mode (EGA graphics required!). For fun, I tried to convert it to C, but gave up - pure spaghetti code. The author became the head of a 200-person engineering department -- best leave it in GWBASIC and let him support it.
Re:Give us a bone! (Score:5, Funny)
Re:Give us a bone! (Score:4, Funny)
Couldn't agree more! (Score:5, Funny)
And it's called hell.
Re:Couldn't agree more! (Score:4, Funny)
You can tell the difference?
Rethink your approach, perhaps (Score:5, Insightful)
There's a different point of view you need to seriously consider: who's signing your paycheck? It's not Microsoft, is it? I thought not.
Consider meeting your boss in the middle. It's possible your boss is set on VB6 because he can read it fluently. Perhaps you could convince him to port it to VB.net. VB.net might not be so different that it would scare him. The GUI isn't all that different. And the .net framework would allow you to gradually expose him to other languages (C# or C++/CLI.) And it would allow you the opportunity to use a language with better libraries than VB6.
Have you dug a bit to find out why he's so pro-VB6? Maybe he's biased against .net because it's an interpreted language (like Java)? Perhaps half of his client base is all still running Windows 95 on 90 MHz pentiums, and .net is not an option for them. Maybe he'd be OK with C or C++ compiled to native executables, as long as there are no .net requirements. Microsoft's latest version of C/C++ has a strong push towards safer coding with bounds-checked versions of all the standard library functions. That might be good enough for him.
Or maybe he just has only two or three long-term clients that are stuck on Windows 3.1, but they've been with him for 25 years so he feels he has to support them into the far future. Consider buying them a few cheapo PCs to run your software: $400 each for a few bottom-feeder Dells would go a long way with customer goodwill, and would allow the rest of you to move into the 21st century of tools. And a $1200 hardware investment is much less money than your time spent struggling with old tools.
If he built a successful business around a piece of software, the chances are good he's smart enough to listen to rational arguments. So don't be irrational by kicking in your heels and saying "no! no! no!" unless you really enjoy job hunting.
Re:Rethink your approach, perhaps (Score:2, Informative)
Just ignore most of the ad hominem remarks against VB6 here. I hate Microsoft as much as the next
Re:Rethink your approach, perhaps (Score:5, Insightful)
Better yet, given that he's built a succesful business by writing version 1 in VB and that you don't actually have any rational arguments, why not defer to his judgment? The worst that can happen is that the next time this question comes up, you'll have a useful opinion instead of just vague concern that VB isn't 1337 enough.
It does have it's place too (Score:5, Informative)
So General Motors, or at least some small division of it, hired their company to do a project and my roomate was assigned to it. He was kinda miffed though, because GM insisted it had to be done in VB. He talked to them and they acceded that the backend could be in PERL, but the client side UI had to be VB. Well he didn't really know anything about VB, he just disdained it as a "toy language"... That all changed on that project. He was amazed by it's flexability in doing Is and speed of development. He said that every time they totally changed the requirements of the client interface he could get a new one done in a couple hours.
In the end, he was certianly no VB-all-the-time convert, but he had a respect for the situations it was useful in.
Not knowing anyting about this project I can't say, but there are projects out there that something like VB is the best answer for.
Re:Rethink your approach, perhaps (Score:4, Interesting)
In summary: don't blame VB for shitty programs, blame the programmer. And if you'd rather write in something else, why should I care? I'll judge you on the results, not the language used to write it.
Re:Rethink your approach, perhaps (Score:4, Informative)
Aiiighghghghhhhh!!!! Why, why, why do people keep saying this?!
Java is a compiled language. The Java source you write gets turned into native machine code. It's just that the compilation happens at runtime, unlike with many other languages where it happens earlier. Same process, different time.
It's not like this is a new concept. For one thing, the documentation describing it has been up on the Java web site for years. For another thing, people on Slashdot have been saying it for years. And for another thing, LISP environments that do incremental compilation to machine code at runtime have been around for at least, what, 15 years? Some quick googling indicates that language environments that compile stuff to native machine code at runtime have been around since 1968.
And heck, it's not as if it's even all that high tech or complicated in certain ways. You don't need something as esoteric as the internals of a JVM to see machine code being generated at runtime. If you want to see it happen on something simple, go to your nearest Unix or Linux machine and type "tcpdump -d not port 53". Notice that it spits out machine code? Now try some different filter expressions like "not host 127.0.0.1" or "host 127.0.0.1 and tcp and port 25" and watch how the assembly code changes. Yes, that's right -- even tcpdump compiles code at runtime, at least it does so with the packet-matching code, which is where the speed is really needed.
So hopefully it's not too hard to comprehend now that modern JVMs do the same thing, and as far as I know, so does the .NET virtual machine.
Re:Rethink your approach, perhaps (OT) (Score:3, Informative)
That's actually some sort of bytecode. I've been hacking x86 assembly for 10 years now, and there's no way x86 has a "ldxb" instruction.
Re:Rethink your approach, perhaps (Score:3, Informative)
While I agree with most of your post, that's not actually true—tcpdump compiles to bytecode, which it then interprets much like a non-optimised JVM. To see this, run the same commands on the same version of tcpdump on different CPU architectures (I tried SPARC and i386): you’ll see the same instructions being generated (you can even check that the compiled bytes are the same, if you use the -dd option).
Re:Rethink your approach, perhaps (Score:3, Informative)
Actually I would say you're both right and you're both wrong.
Java is neither 100% compiled or 100% interpreted. Java is compiled in the sense that what is executed is not the original source code. The Java compiler has taken the code and produced a bytecode file that is closer to machine code than the original source and as a result executes far more efficiently than a purely interpreted language. Also, because what is interpreted is not the original source cod
Re:Rethink your approach, perhaps (Score:5, Informative)
VB was my second language and VB6 does vastly improve the VB experience, but there are several large problems: it doesn't support inheritance (only polymorphism); it is very difficult to use advanced features of the Windows API, it is very hard to debug and profile, and finally, it can lead to extremely unstable code.
The VB6 language supports a feature where you can implement an interface, similar to Java or C# interfaces, or C++ pure virtual functions. It does not, however, support a method to inherit methods from another class. Thus, you often find yourself writing reams of code to delegate to another class that has a common implementation of various functions. Furthermore, if an interface changes, all the classes that inherit that interface must also be changed. That can lead to a rather large maintenance headache. Furthermore, changing the interface often plays havoc with the IDE's parser, so it can no longer tell which methods on the class are inherited in the Intellisense functions.
More advanced features of the Windows API require you to copy and paste large bits of function and constant declarations into your code, and you have to jump through all kinds of hoops just to properly use the registry, system tray, or message handlers. I.e. if you want to catch a certain message sent to a window, you have to use SetWindowLong to override the message procedure of the window (you pass in the address of another procedure, which you acquire by calling "Address Of"). There is also all kinds of problems with passing pointers to structs, since you can't get a pointer in VB6. I.e. often, many window procedures require a struct with a pointer to another struct. There are hacks to get that, such as allocating a new memory buffer (using the LocalAlloc API), using CopyMemory to copy the VB struct into the memory location, then passing the pointer you got from the LocalAlloc call in as a struct member, and then using CopyMemory after the call to put the data into the VB6 struct. There are also undocumented functions to retrieve the address of variables, but there is, of course, no way to dereference a pointer, short of copying the data into a VB struct, or doing some fancy copying to change what an object points to (but that plays havoc with the reference counting).
Next, you've got the instability issues. Using *any* of these features leads to instability. Under normal circumstances, things work alright, but if you try to run the application in the IDE while you've got a custom message handler set up for a window, then the moment you hit "Stop" to end execution, the whole IDE crashes. The reason for this is that the VB6 IDE runs the app inside the IDE's process, so if your app causes a GPF or similar, the whole IDE goes with it. It also makes it a real pain for debugging, since setting breakpoints inside the window procedure often causes crashes.
Finally, it's very difficult to debug a VB application. If you've ever looked at the assembly output of the compiler, it's absolutely horrendous. Trying to step through it in WinDebug or something similar is just about impossible. The only way to debug it is with source code and full symbols, but even that is rather difficult sometimes. For example, most of the magic happens within the VB6 runtime (just about every VB statement is implemented as a call to the runtime; even assignment), so it's very difficult to follow what is really going on underneath the hood.
Those are my main problems with it. I also don't like many other things. For example, VB is really slow. Slower than
No argument really. (Score:5, Insightful)
Re:No argument really. (Score:3, Interesting)
Actually, I'm fairly sure you can find more VB programmers than C# programmers, and probably will be able to for the forseeable future. The problem is, a significant portion of them aren't real computer scientists, and they'll tend to write crappy stuff.
I'm not sure that line of attack would work well with the boss, though, who's a VB guy, probably not a computer
Depends on a lot of factors (Score:3, Informative)
On the other hand, it has trouble coping with large complex projects (One of my larger projects regularly crashes the VB IDE when I load it, for no particular reason, and sometimes the VB compiler spits out mysterious build failure errors for no particular reason), and it lacks a lot of important features you get out of better languages and tools. If performance is a concern, you'll also find that it has trouble scaling there (though it's at least tolerable, and if you're careful you can get pretty efficient code out of it). There are also some data models and algorithms that simply don't work well in VB due to the overhead and inefficiency of using COM IDispatch and reference counting for every object.
If you need to make a transition from VB, you might be able to manage to convert it over to VB.net, but I've never been able to do that successfully. I personally use C# for any project these days that I would have used VB6 for in the past. And if you don't really need to do much in the way of UI, C++ is a pretty solid option for almost anything else, even if it's tough for some VB coders to grasp.
One middle-ground option would be to rewrite chunks of the application using C++ or C# and wrap them in COM so that you can drop them into the existing VB application. I had pretty good success doing this with performance-critical parts of a few of my larger VB applications and didn't lose any of the benefits of doing my UI in VB in the process.
Re:Depends on a lot of factors (Score:4, Insightful)
what? (Score:5, Insightful)
The language is irrelevant to comp scientists (Score:4, Insightful)
Actually, the problem is whoever hires people who are qualified for task A to do task B.
This is a perfect example of the difference between a university-educated computer scientist, and a graduate of a 6-month "tech college" program. The community college drone has only been taught how to use one or two tools to perform common tasks, whereas the computer scientist is taught to truly understand the tools, as well as the thinking that went into them, how to use them to solve multiple abstract classes of problems (instead of just a few common, specific problems), and how to apply that knowledge to use tools they haven't seen yet.
A real computer scientist doesn't care what language they work in. A good employer should know that when they hire the 6-month grad at $18/hr, they're getting a code monkey that can do only what is explictly listed on their resume. They know that when they spend the extra money for a computer scientist with an actual degree, they expect that programmer to be much more capable, flexible, and adaptable. The fact that they've never programmed in VB before is nothing more than a minor roadblock. Send them to Borders/Indigo/Chapters with $50, tell them to pick up an O'Reilly or Knox book on VB, leave them alone for a couple days, and they should then be able to apply all their learning in the new language.
Re:The language is irrelevant to comp scientists (Score:3, Insightful)
I agree that a "real" computer scientist could easily learn a new language and it really might be just a minor roadblock. However, the language is certainly not irrelevant, and we really do care what language we work in. A craftsman needs the right tools. I wouldn't want to code in a language that
My biggest gripe... (Score:2)
Re:My biggest gripe... (Score:5, Informative)
I used to think so, too.
Try this. [microsoft.com]
Who's your buddy now? :-)
Re:My biggest gripe... (Score:2)
If I could mod you up or transfer all my karma points to you I would. Thanks.
Re:My biggest gripe... (Score:3, Funny)
Wha? (Score:3, Insightful)
OK, just to get this out of the way, the owner of the company hired you to re-write his program in Visual Basic, and you don't know Visual Basic? I mean, it's not like he hired you to simply re-write it in any language, he wanted you to re-write it in VB. And he obviously knows VB since he wrote the software in the first place. So, uh, WTF?
First, I have to assume you mean VB 6, since VB.net bears more resemblance to C# than anything else. If you're talking VB.net, don't worry about it. The syntax might be annoying, but it's a decent language. Anyway, as for the merits of VB, well, it's appearantly good enough for a large project, since you're looking at one right now that was good enough to start a company that can support 5-9 people. This company's appearantly been around a while; I hope nobody's writing new stuff in VB. So don't worry about whether it's good enough or not, it is.
The issue I would have with it is, it's being killed by Microsoft. There's nothing you can do about it. It may not work on new versions of Windows. Old versions of Windows won't be supported anymore. You'll run into security holes that won't be fixed, or try to interoperate with software that needs a newer version of Windows. Basically, you're going to get screwed, it's just a question of when. If your company has the time and money to do a rewrite, do it in a language that's going to be around for a while.
Normally of course, I'd call you nuts for doing a complete rewrite unless it's a pile of crap that's falling apart at the seams and the basic architecture is shit, but it's written in VB. Which has its merits, and maybe I'm wrong here, but I consider it more of a prototyping language than anything else. Just don't rewrite it in VB 6. Seriously, quit first, it won't do shit for your resume to have VB 6 on there, and it'll just cost the company a crapload of money for no good reason.
Why the hell did he hire you? (Score:2)
But, in fairness, if you have serious doubts about the platform the owner insists upon using, then this isn't the place for you to be working.
You're either onboard, or you owe it to your boss to leave the company.
One of the best assessments I've seen (Score:5, Informative)
Really, reading his argument in the context of having a bunch of C++ coders build a nice Windows app in 2006, I think I'd probably conclude that C# was the way to go, as opposed to VB. But keep in mind that C#.NET and VB.NET are more alike than they are different. For most apps, the arguments for managed code (VB or other) are very potent.
My take: If you and every single developer on your team can't instantly see and explain the differences between the 4 arguments to this function:
void foo(std::string a, std::string * b, std::string & c, std::string *& d)
stop now and use managed code of some kind.
If you all can, think really hard about why you want to spend your talent managing memory instead of doing things that'll really make your application shine. (There are reasons. They don't apply to most apps.)
Re:One of the best assessments I've seen (Score:2)
Re:One of the best assessments I've seen (Score:2)
Using C# is a far call from using VB, even if it is VB.NET.
I'll give you that it's a far call from VB 6. But what makes it a far call from VB.NET in your opinion? I like C# much better because the syntax is much more familiar to me, but the appropriate uses for each as well as the capabilities of each seem largely similar to me. Performance is identical. So what does C# buy someone whose mind hasn't been molded by 15 years of C/C++, apart from mono's c# implementation being more mature than its VB.NET imple
VisualBasic = the devil (Score:5, Funny)
C# and VB.NET are very similar, and C# has a much more standardized syntax style. It will take little time to teach someone C# that is familiar with Java or even C++, but it could take some time to acclimate that same programmer to VB's retarded syntax style. Any language with constructs like "If Not foo Is Nothing Then
JavaScript, C, C++, C#, Java, and even Perl have the same curly-brace blocks, statements end with a semicolon syntax style.
If your boss gives you the often used "anyone can learn visual basic in a day" line, give him the "anyone can learn Java or C# in a day also, and the talent pool for those languages is much larger" response.
Re:VisualBasic = the devil (Score:5, Insightful)
this is seriously one of the funniest things I've read on slashdot in the last week. For the canonical car analogy, it's like saying sheet metal has no place in modern automobiles.
normally... (Score:2)
I'm not sure what type of app you're aiming at, but C++ and Java come to mind as solid choices.
Easy answer (Score:2)
Re:Easy answer (Score:5, Funny)
Cross Platform? (Score:5, Insightful)
To that end: Python and C++ are generally good choices. They each have their place. I really like my C++, but rapid development is somewhat of a joke. It takes years and years to master and even after using it for close to 8 years on a daily basis I'm still amazed at what I don't know sometimes. However, you can do anything with C++. If you can think of something, there is already probably a library out there to do it. I don't recommend it to novices or people who want rapid development, however if you want a rock solid well performing system it really can't be beat.
If you're doing GUI stuff, you would have to take a VERY serious look at the combination of Python and Qt. Qt is the de facto cross platform toolkit. It has everything from GUI libraries to network libraries to regular expressions, xml parsers, you name it. It's very good. It's also very good with C++.
I don't know much about C#, but with Mono you at least have the possibility of it being cross platform. I'm not a big Java fan. After being a C++ guy for so many years it just seems like crap. It lacks the good things from C++ with all of the syntax overhead, and it lacks the flexibility of Python.
If you didn't guess I write almost everything it Python or C++. They are my dual golden hammers.
I do a lot of Scheme too, but I'd be an idiot to recommend that to you!
Perl is glorified shell. I wouldn't touch it except for the smallest most throw away programs, if even for that anymore. Still I know people who swear by it, mostly sysadmin types.
I've played with Ruby a bit. It has some definite strengths, but the library support, or lack thereof is a big minus. Syntactically it reeks of Perl and IMHO lacks the elegance of Python. Still it's got some really cool unique stuff.
Overall I would recommend Python, but like another post mentioned, what are you trying to accomplish? You should fit the tool to the task not the task to the tool.
Re:Cross Platform? (Score:2)
However, the folks at RealSoftware got greedy and let the quality of their past products go to their heads. All current versions of the software are written and compiled using RB itself... a move that has
Re:This post was brought to you (Score:3, Funny)
VB isn't _that_ bad (Score:2)
VB.Net is fine too. The biggest problem is that simple languages attract simple people.
Not too bad overall.... (Score:2)
http://www.amazon.com/gp/product/0130293636/104-33 75871-4590326?v=glance&n=283155 [amazon.com]
and then learning the essential stuff from Charles Petzold http://www.amazon.com/gp/product/0735617996/104-33 75871-4590326?v=glance [amazon.com]
reasons not to use VB (Score:5, Funny)
2. Geeks won't be impressed because it's so VB
3. Microsofties will explain how your language is "deprecated" unless it's VB.NET. Trust me, it's bad to be deprecated on.
4. Enterprise programmers will explain how C# (or Java) is better than VB.NET, has more constructs, etc.
5. (An elaboration of point #2.) To a programmer, "dim employees() as integer" just looks goofy.
6. You and your company will be a one-man profit center for Microsoft (their tools are priced so that they don't come cheap when you need to do real work). Here it's not so much big bad Microsoft that's a problem, but I hate being someone else's one-man profit center.
7. If it's Visual Basic 6, try to get a hold of Ted Pattison's (out of print) book on how to use Visual Basic with DCOM. It's a great book, but my takeaway was that it's easier and wiser just to say no. (I suspect this may have been Pattison's POV too).
What is better? (Score:2)
For one thing... (Score:2)
In my opinion, if you are re-writing, I would say do it in Java - then it will work on Mac and Linux and everything. But if you are determined to be Gates' whipping boy, at least do it in C#.
VB6 has its place... (Score:5, Informative)
They vanished after they tried to compete in the
I got an internship with Microsoft after spending most of my interview defending VB as a language choice -- this was pre-C#/.Net.
Some "facts" from above annoyed me, so I'm responding:
1) VB is only interpreted.
VB6 can be compiled to P-code, and will run interpreted. However, by default it's compiled to executable code. The only "penalty" for using VB6 when it comes to speed is really the memory footprint of the VB6 runtime DLLs.
2) VB6 is not suited to large products.
I'm aware of at least one company that based an entire website off VB6 apps. I'm sure they would be ASP.Net now, but at the time (VB4), that wasn't yet an option. So the web engine was actually a series of VB apps that were invoked to process the web request as ReadLine and Print commands.
3) VB6 -> VB.Net
(The person in question did only propose this as an idea.)
I would argue against this. There are certain elements only possible in VB6, and the switch to managed code is unfortunately not as seamless as MS would have liked. Hence the uproar when MS EOL'd VB6. VB.Net is great for managed code, and even has some features that C# lacks. I personally prefer C#, but I come from enough of a mixed background that I can handle what VB.Net code comes my way. While rewriting the application in VB.Net may be the proper thing to do, it certainly does not provide much in the line of benefits above and beyond rewriting the application in C#.
VB does have certain benefits to use. As a RAD environment, it is (or was
While I can't know why your manager wants to use VB, it's not such a terrible order.
If your manager only wants to preserve the look-and-feel of previous versions, the previous proposal of writing COM components in C++ for the high-performance portions and using VB for the front-end is certainly a very viable option, and one that I've used previously. In this manner, the weaknesses of VB6 can be circumvented while still leveraging existing components and possibly even code. At the far end of the advancement spectrum, even managed components can be exposed to COM clients -- Adam Nathan's wonderful ".Net and COM: The Complete Interoperability Guide" is probably the most complete book on the subject. If appropriate, you can write new code in C#, and expose it back to VB6.
If your manager wants to preserve the code base in VB6, you might want to determine why he wants to rewrite the application -- it's possible a better solution is just to rewrite portions of the code, depending on the scope of the changes he desires. The right tool for the right job -- VB is the right tool for some jobs, but shouldn't be presupposed to be the right tool for every job.
That being said, there are few things you can't do in VB -- although some of the solutions are probably not as simple as they may be in other languages. Keep in mind, however, that it is even possible to get assembly code linked into a VB6 application, if necessary. It just takes a little bit of creativity.
Re:VB6 has its place... (Score:3, Informative)
Try this:
- Write a very simply object in VB with just a few properties that can be set.
- Write the same object interface in C++.
- Write a test harness which instantiates and then releases 1 million of each type
- Compare the results.
C++ allocates and deallocates COM objects an order of magnitude faster. If you're working with lots of insta
Depends! (Score:4, Informative)
Here's my two-cents, by language/environment:
VB6
---
If you're writing business applications, VB6 will get you through. Manipulating very large datasets can be a bit of a challenge, and you're always going to have problems with user experience (due in large part to a complete lack of multithreading). Applications can be made that are *functional*, although your resultant UI will always seem dated.
VB.NET
------
This is an entirely different beast. You've got a much more powerful langauge on your hands, with as much power and expressivity as Java - it is quite straightforward to produce a modern, performant application with little muss or fuss.
My suggestion, if VB is an absolute must, would be to insist (as best you can) on VB.NET. Now, that being said, VB is not a magic bullet - VB/VB.NET/C#/Java, they are all languages designed to allow a programmer to express their thoughts, and it's quite easy to produce unworkable software with any of them. Do not allow yourself to fall into the 'C# is better than VB.NET' arguments, simply because they are completely non-sensical; the power of any
I've worked professionally in VB, VB.NET, Java, Perl (alot of Perl, in fact), C#, and C/C++, and I must say IMO the most expressive langauge is C++, hands down. I love Perl, and you can do an amazing amount of things with it, but the power and flexibility of C++ is unmatched in the list above. VB.NET/C#, however, can be excellent choices for presentation-centric applications (Windows Forms applications or Web Forms). In the past, I've worked on projects that combined the two; a C# GUI that interfaced with a C++ server component. It worked great.
Any
Short Story: If you're writing a business-focused application with limited or no multithreading needs, VB works; If you need a modern GUI with all the latest bells and whistled VB.NET/C# should be examined; If you need high-performance, minimal runtime requirements, and low-level system interaction, look somewhere else. Real-time equipment monitoring, for instance, is a task best left to C++. The rest can be done in VB or a
Have fun!
Bryan
==
Myriad of problems (Score:3, Informative)
Some good things to point out though:
VB is not an open standard,
VB is platform specific
VB is generally quite time consuming to maintain for large apps
VB is much slower than C++ for certain CPU intensive apps.
Possibly: The people expected to maintain the code are less well-versed in VB
If this is a small-enough, simple-enough, Windows-centric enough application, there's probably no good reason to do a total rewrite in a different language.
If, on the other hand, this app might have a customer base on a non-Windows platform, and if the program is likely to dramatically increase in size in the future, it might be worthwhile to think about changing it to a different language.
This original poster scares me (Score:5, Insightful)
The crucial ingredient in any project is the people you end up working with, not the language. I'm not a fan of VB, but if this kid doesn't have the experience of successfully completing a project in the real world, he should consider following the owner's experience -- and only worry about changing the underlying language once he has a couple of releases under his belt.
Sticking to VB is asking for strange bugs (Score:3, Insightful)
And if you really have to stick with VB, you have to impose strict coding rules, like requiring "OPTION EXPLICIT" on ALL code, be strict about variable naming and so on.
Better be so strict about the rules that you actually end up with C#.
Why does the software need to be rewritten? (Score:3, Interesting)
Suggest not rewriting the software and simply going through and improving where needed.
Technology sustainability (Score:3, Funny)
What I've seen has been mainly Access being used as a RAD to develop portfolio management systems, with VBA constituting the language the logic is developed in. Some observations:
1. Such applications when used over the medium to long run invariably become unmaintainable. The business changes, loan products change, organizational structure changes, new needs arise, servers are upgraded, etc. This we all know; there is no such thing as finished software. A VB application has the advantage of getting up and running fast, but as the code changes accumulate over the years, the code becomes unmaintainable; a change here b0rks fifteen things elsewhere and the developer (often one person) eventually gets to the stage where he just says "no, we can't do this". IF you're lucky, he tells you that it's because he needs to reqrite the app. If you're not, he attributes the limitation to the abstract god of technology.
2. The Access/VB development environment is indeed a VRAD (very RAD). You can go from zero to information system in almost no time with almost no resources (the typical scenario of one developer mentioned previously). TH downside is that when you have this few people working on the system, it can be underdocumented. Which means that when your magical one-man development team jets, it's going to be easier to rewrite the application from scratch (and when that crisis comes, it's often rewritten in Access/VBA again, since a system is needed, FAST). Oh my aching bones...
3. Mentioned elsewhere, but these MS products are EOL'ed periodically. No support. No bug fixes. No security fixes. One often overlooked consequence of this is that MS drives the techie labor market towards its current offerings; what this means is that you are not going to expect a VB-based product to last, since a few years down the road the Microsoft marketing machine has changed the paradigm and driven developers towards other technologies, limiting the availability of engineers to feed your monster.
4. When you're developing a system for business usage, you're going to want to have several things which more proefessional toolchains make more readily expose; things which, more likely than not you can accomplish nominally in VB albeit with a lot of workaounds and in many cases not very reliably and sub-optimally. Audit trails, transaction atomicity, multi-user functionality, etc.
I'll post more if I canthink of them. Good to have a reference of VB drawbacks, especially since I see it so often.
Problems with VB6 (Score:5, Informative)
2) COM components in VB don't keep the same GUID from time to time (depending on what changes you're making). This causes build problems because when the component's GUIDs change, you have to change all the other projects that reference them. This can be a huge timesink in development.
3) VB6 is unsupported and is a black box, which means no one else can support it either
List of problems from my ex-employer (Score:5, Informative)
> against VB because I'm not familiar enough with it.
I, as system programmer, for three years did ported number of VB applications to C/C++. Funny job for system programmer, don't you think?
The list of problems of my employer was:
1. Run-time libraries conflicts. VB applications affected worse of all by "DLL-Hell" probles of Windows: lots of functionality resides in ActiveX components developped by third parties. People usually quote ActiveX support as VB first advantage, but from POV of deployment and support it is hell.
2. Run-time libraries dependencies. Since VB is all into ActiveX, you might start using some component you haven't explicitely installed. Then when you ship the application to your customers you might find yourself in silly situation: half of them report everything is Ok, half - scream that nothing is working. Apparently, first half have the similar set of applications installed - and VB application finds the library missing from its own installation.
3. Internationalization. That was huge problem for my employer. We have had quite number of customers in Japan. M$ did internationalizion of VB in straight way: it didn't. In other words, VB as we have it in Europe/US and VB in Asia are two different VBs. Absolutely different. Since Japanese love VB, most of our customers had it installed. The situation looked so: if customer installs our application - other and her/his own applications stop working; if s/he reinstalls VB anew - our application stop working. Interpreter is the same, but run time libraries are very very different.
4. Upgradability. VB applications are one hell to maintain. We have had lots of reports that installation of our application made with VB4 was breaking VB5/VB6 installations. According to M$, the cure was to upgrade everyone to VB6. But VB6 introduced some problems so our custormers were split - half used VB5 and other half VB6.
To conclude. One can write good application in VB. But M$ doesn't make that very easy. The whole ActiveX thing is one hell to deploy and maintain.
problems with VB (Score:4, Insightful)
-to me, the syntax is OK
-the API, compared to Java, is really bad (no jdbc, no generics,
-the GUI is easy
-writing maintainable code is difficult. VB(.NET) is hard to style because of its IDE. Eclipse is magnitudes better.
Good and Bad Sides of VB (Score:5, Interesting)
Good Points about VB:
Bad Points of VB
Overall Thoughts
I have been programming in VB since Version 2, and right up to Version 6. I cut my teeth on programming Windows Applications using VB, and I have to admit it is one of my favorite development systems. I also program in C++. I use VB to prototype an application, the other guys and customers can comment of the look and feel of the software, and modifications are easy to make. Once everyone is happy with the App, it is then ported to C++.
VB.NET is not VB (google for Visual Fred) VB.Net is a completely different language to VB and it is not code compatible. Time will have to be taken to rewrite the parts of a VB app that don't work under VB.Net
VB is a fine system and well suited to RAD projects, DB projects, and client/server projects. However, if you are looking for a system that creates faster code, is more secure, and easier to maintain, then you'll need to start working with things like C/C++/Java/etc
There is only one REAL argument... (Score:4, Interesting)
First, VB.NET is everybit the language that C# and/or Java are (that is there is NOTHING that can be done in those languages that can not be done in VB.NET (Regular Expressions, Hashtables etc. and much more is available to programmers in VB.NET)
Second, if the original application was done in VB (6 or earlier) then there is no reason to believe that the language is no longer suited to the task, the only real question is "is the programmer up to the task?" Since VB and C# compile to MSIL (if both the VB code and the C# Code are "well written" then they will compile to the SAME MSIL (or near enough as to not matter...) the ONLY argument for one over the other is comfort/skill level of the programmer. This is not a trivial matter. I am far more productive in VB.NET because that is where I am comfortable, not because it is a better or worse language I can read/write VB much as I can [in my native language of] english. Where as I can read/write C# or Java about like my French, in which I am reasonably fluent, but I have to concentrate more on the translation. And thus we reach the ONLY real argument for you to make against VB, will you be more productive (and therefore cost your employer less) if you work in another language? If you believe this to be so, then you should already be able to quantify this.
Admittedly, There are far more "less skilled" programmers in the VB world than there are in the C#/Java realm. This is simply because people can learn to do "useful things" in VB (or VB.NET) far more easily than they can in C-based languages. The "entry threshold" to "being a VB 'programmer'" is lower. Still the high end abilities of the language are there, even if a number of programmers don't know how to use them, or use them correctly.
Anybody out there proclaiming that any language (other than C or assembler) is "better" then VB.NET is simply demonstrating their own ignorance of VB.
Coding defensively (Score:3, Insightful)
A quality program must be coded defensively, in other words it must assume that anything can fail at any time and that it must sensically deal with it. It must not make assumptions about external inputs. Unfortunately, few programs are coded to this level of quality, but they are the ones that you won't see security advisories about. Programs that are not coded defensively will, upon hitting a problem, exit with an error message that does not help you find out what that problem is, or continue doing something where it does not make sense to continue. Troubleshooting and maintaining defensively coded applications is simple - whereas with other applications a developer often just leaves the bug for eternity.
There is extremely little example code for VB that is coded defensively. If you disagree, please post a link to an example where code to open a file has a code path that is run specifically when the file can't be opened. In the meantime, google has 748000 hits for "80004005".
However, for your particular situation, this is largely moot. If you're already working with a specific developer, they will either code defensively or they won't, regardless of language.
Book recommendation (Score:3, Interesting)
IMHO, the new
Your question is a bit meaningless without saying if its VB6 or VB.NET. Although I've written lots of VB6 stuff in the past, I'd be reluctant to start something new with it. I jumped from VB6 to C# just because I knew C from long ago and prefer the { } syntax but, as others have said, the difference between VB.NET and C# is pretty much just syntax.
Wait, let me get this straight... (Score:5, Insightful)
I don't.
If you're going to be working on rewriting it, it needs to be rewritten in a language you have significant experience writing in. Period. For instance, if *I* were going to be rewriting it, the logical languages to choose would be Perl or maybe lisp, because those are the languages I know well enough to write good code. If he wanted it rewritten in VB, he needed to hire someone with VB experience.
VB *is* reasonably good for certain things (mostly, pure GUI work, e.g., an application that facilitates data entry), but only if the programmer doing the work is familiar with VB. I've seen applications written in VB by someone who didn't know the language well, and they were universally terrible in every respect (_including_ the UI). This is true in any language. When somebody is just learning the language, they aren't going to be comfortable with the language's features or conventions, and so they're going to write execrable code for several months until they learn those things. During that time, you don't want them writing something mission-critical in that language. It's bad juju.
My take on it - can't believe no one else has said (Score:4, Insightful)
>in VisualBasic. This scares me, but I honestly can't make a good argument against VB because I'm
>not familiar enough with it.
So if you were hired to do this job, wasn't it made plain up front that it was to be done in VB? If this scares you now, didn't it scare you then? Why did you take the job? If you're not very familiar with VB, why would someone hire you to re-write a program using VB?
Steve
VB is the best language, VB is the worst language (Score:5, Interesting)
VB, as a language, is the worst language I have used in the last 20 years.
VB as a development platform is the most productive system I have used in the last 20 years.
Hate the language, love the system. You will too.
I am program in VB(and other languages.) (Score:3, Interesting)
2) VB is no good for low level work
3) It is good at getting the job done
4) Why the hell does a programming language scare you? the day a language scares me is the day I look for a new line of work.
5) It is easier to maintain. This assumes that the programmer who wrote it wasn't a complete idiot...but that applies to any language.
6) VB.net compiles to byte code. Just like any
7) VB handles the memory for you. For business applications that need to be done, this is a good thing.
Re:Umm (Score:3)
Re:Basically. . . (Score:2)
Re:Basically. . . (Score:2)
On the other hand, VB6 seems to get sluggish when you have more than 100,000 or so strings in memory. Nearing that boundary, I've gotten performance increases by storing strings in a file and just remembering their addresses, even when there's plenty of free ram, which is crazy.
Re:3 reasons from personal experience (Score:4, Informative)
That's actually the main feature of Classic VB -- that it's really just a user-friendly wrapper around Windows COM. If you want MS Office automation or anything that ties in closely with other Windows apps, VB6 is still a very good choice.
Although I agree strongly with your assessment of VB server apps.
Re:3 reasons from personal experience (Score:4, Insightful)
In other words, you're a Java bigot that looks down upon those that don't agree with your choice of tools. It used to be C bigots that irritated me the most (the "if you can't do it in C it isn't worth doing" mindset), but now it seems that most of them have moved to C# and have finally realized the benefits of a decent GUI development system. A friend of mine once put it this way: "Welcome to VB you pompous assholes." VB6 and VB.Net have their place, and calling people that use them bozos won't win you any points (although you'll probably garner some karma from like-minded mods.) But the biggest argument to me isn't that VB6 is a black box (from an empirical standpoint it's about as thoroughly understood as it's possible for a black box to be, and
Re:3 reasons from personal experience (Score:3, Insightful)
I work with Perl, Java, C# regularly. A crappy coder can use C, C++, JAVA or whatever , he will still produce crappy code. I use these languages because I'm more familiar with C related languages.
Assuming that the guy is working on VB
Instead of wasting your time on syntax matter, better to focus on the application architecture.
I'm sure that half of the negative comment came from the simple reason that VB means virtual "BASIC". Most of
Re:3 reasons from personal experience (Score:3, Insightful)
Re:3 reasons from personal experience (Score:5, Insightful)
Because it sucks .
It is a language designed so that a genius can write libraries designed for the merely smart to use. How many geniuses do you have in your workgroup? Me, I'm lucky. But I'd really rather they work on real design than trying to remember how copy constructors interact with template instantiation.
I don't know C++, and I know that I don't know it. Somewhere around here I have a list of interview questions for people who put C++ on their resume. They're mostly from me reading C++ code and going "what the heck does that imply?"
Unsurprisingly, most candidates fail that section of the interview. And they fail even trivial stuff like "what's a virtual pointer all about?" They may be aces at writing O(n^3) algorithms with CString, but they have no clue what's going on under the surface.
To be fair, I do know some true C++ experts. Most of them would rather be writing Haskell.
Re:3 reasons from personal experience (Score:3, Insightful)
Of course they fail that portion of your interview questions - 'virtual pointers' don't exist. Virtual methods exist, pure virtual methods exist, pointers to virtual methods exist, but there's no such thing as a 'virtual pointer'.
'CString' is a Windo
C++ is not for dummies (Score:4, Insightful)
Now don't get me wrong, I work with C++ every day and I love it because of the sheer power it gives me. You can basically abstract away any management chores using smart pointers and other objects. And you can write the most obscenely decoupled functionality using traits classes and such. But put this same stuff in the hands of a VB coder, and you'll get C++ code using VB idiom. And that's NOT GOOD. VB coding idiom is not exception safe AND does not deal with memory management, so you'll have memory leaks all over the place, and even if they bother to put in the deletes in the proper places, you're one exception away from leaking a whole bunch of stuff. Teach them to use smart pointers to fix this? In an average C++ project "done right", you'll have to write a lot of smart pointers/auto objects yourself, and people who are used to VB are _not_ capable of writing proper smart pointers in C++. That requires reading and understanding all of Scott Meyers' books, and they won't do that. They'll think they grasp the language when they have their first MFC-generated dialog on-screen. It'll only get worse from there.