|
You just happened to pick my first procedural language and IMHO was the best programming language under DOS for its time!
Ant.
|
|
|
|
|
Try DataPoint's "Databus" language for a real piece of work. I especially liked version 1.0 which took 1 full hour or more to compile.
|
|
|
|
|
Brainfuck rules the world 
scio me nihil scire
My OpenSource(zlib/libpng License) Engine:
http://sourceforge.net/projects/rendertech
Its incurable, its a Pentium division failure.
|
|
|
|
|
Dude, that is not cool. Stop ripping on VB programmers! 
But in the end, it's all just database access right? And that stuff is just plain boring.
|
|
|
|
|
As much as this was meant as a joke, I believe it is nonetheless very true. The reason is that there is a class of programmers (bad programmers) that usually haven't spent the time to learn something more structured. They tend to only learn enough to get their job done -- not enough to learn how to do it well. Historically, what language has been the easiest to learn and the easiest to program without much structure? BASIC (and then Visual Basic). Thus bad programmers tend to gravitate toward VB. And this is what I usually end up seeing (and I am sure many programmers see as well).
Before you start screaming at me, let me reassure people that I am NOT saying that VB programmers are necessarily bad programmers -- I have seen many very gifted VB programmers. It's just that VB tends to attract the lazy programmers (i.e. bad programmers).
- Kevin Hall
(A person who still believes that VB is useful for the right jobs)
|
|
|
|
|
I think VB.Net is the first real VB programming language...;)
|
|
|
|
|
Hey, that's a cheap shot. The Microsoft BASIC in ROM on the original IBM PC, limited though it was, still had it's uses. I've no doubt each version of VB had their uses also. It might be useful to teach more VB programmers what those uses are, and what they are not! 
This goes for VB.NET also...
But in the end, it's all just database access right? And that stuff is just plain boring.
|
|
|
|
|
It's the first version of VB to have an okay development environment and the first version to be a good OOP language. But why use it when you have C#?
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
right. and why using VB.net when C# has a better (and shorter) syntax?!
|
|
|
|
|
VB does not make bad software, bad programmers make bad software! Generally a lot of bad VB code goes out because of it's reputation for RAD. You never get to finish anything, because the GUI goes together so fast, clients think thats it! They want to use it straight away and don't want to wait for proper testing.
With C++ you can't make mistakes because it's gonna fold. With VB it's easy to let something slide because it doesn't fall over as easily. So it ALLOWS bad programming, but it doesn't encourage it.
I was doing things in VB5 and VB6 that people thought you shouldn't be able to do including writing GUI controls and hooking into windows message queues and doing my own interception.
With VB.Net it truely doesn't matter any more. I download C# projects off codeproject and convert them to VB quite easily. I think it's time people stopped being childish about languages and just accepted that we all have the experience and skills we have.
There seems to be a tendancy for programmers to be constantly playing one-upmanship. I'm better than you etc. The same principles apply across most languages and if you think you're better than someone else then offer advice, don't take the p$&% and regress to the playground.
|
|
|
|
|
FruitBatInShades wrote:
The same principles apply across most languages and if you think you're better than someone else then offer advice, don't take the p$&% and regress to the playground.
The problem here is, some people don't take advice such as "go back to school and learn to program" at all well...
But in the end, it's all just database access right? And that stuff is just plain boring.
|
|
|
|
|
Shog9 wrote:
"go back to school and learn to program"
Hence proving my point 
|
|
|
|
|
All that has been said in this thread is true. However, after spending a year in information security, I can tell you that even in the hands of an expert VB programmer, Visual Basic in any form is not built for secure transaction programming; it's too easily cracked. Most good VB programmers use VB's strengths, which is generally in interacting with SQL Server data and easily building server generated GUI's, but write client-to-server and server-to-client code in more secure languages like Java, JSP, C#, or C++ and use VB on the server. I think much of the issue here is that VB is easy to learn, and as a result, bad programmers can pass themselves off as experts with bad VB code. In my experience as a coder, if I can keep VB code working on the server and not interacting with the client, I get the benefits of VB without the security issues in a Microsoft SQL Server environment. However, recently, I have been using more C# since I get the same benefits in one language. It all depends on the business needs and requirements and the architecture of a business system. Those generally determine which language or languages I will use to get the best and most secure performance. 
Big Orange
|
|
|
|
|
VB is not a bad language. It does eveything every other language can do. The things that make it bad as an environment for building useful applications are:
0. the VB6 environment crashes, loosing code at times (for no reason) (it is repeatable too)
1. it seems to make those who no nothing about programming think they do (I am not saying all who program in VB do not know what they are doing; I am only refering to those who know nothing, you know who you are
2. the lure of 3rd party controls, and their lisensing can make diestribution a nightmare
3. ever try to debug a large VB application? well, let's just say you don't want to go there, the environment is horrible
4. the VB environment can't make up its mind on CLSID's, so, everybody on your dev team better have exactly the same configuration, or when your project goes production, your code is going up in flames
5. code limitiation as to how much you can put in a file (we have hit this many times; and no, we are not putting to much code in a single method or class; remember, your comments and whitespace count too)
And, I could go on, and on, and on, and on.... However that is not the point. The point is that in a production environment, I want something that makes my job easier from start to finish, not just at the start.
As far as VB.Net goes, I see that it fixes the short comings mentioned above. In almost every aspect, it is the same as C#, or other languages. So, why not use C#. Why promote 50 diferent languages? Why not unite to a single unified method? For all purpposes I have seen, there are only subtle differences in keywords and syntax.
|
|
|
|
|
Frisky wrote:
It does eveything every other language can do.
Uh, no it doesn't. A good VB programmer may well be able to match (say) a good C++ programmer in a given assignment. But just as there are things that are easier to accomplish in VB, there are things that are more difficult to do in VB than in certain other languages, and there are things which are flat out not possible using straight VB.
Frisky wrote:
For all purpposes I have seen, there are only subtle differences in keywords and syntax.
I strongly suspect that (apart from some of the C-like syntax) C# is what Microsoft would have liked to make VB.NET, had they not had VB<=6 programmers to placate. As you noted, there are precious few differences between the two, especially compared to (say) COBOL.NET, or even Managed C++!
But in the end, it's all just database access right? And that stuff is just plain boring.
|
|
|
|
|
Shog,
Yes, you are correct, there are things that are very complicated in VB alone. I am really a C++ programmer, and I know I tend to forget the number of times I would drop into a C++ DLL from VB. However, I cannot think of too many things (there are a few) that are not possible in VB. However, the few things I can think of are not of much use in corporate applications.
I also agree that the reason for VB.Net is because of corporate pressure to maintain support for the language. In addition, I think there is some pride in VB. I remember attending a very expensive Microsoft VB 10 year Birthday Party. Still have the tee shirt.
However, Managed C++ and C# offer a unique blend. C# makes creating simple applications quick, safe, and easy. C++ allows you, with very similar syntax, to do anything. I always like to say, C++ offers the performance and abilities of assembly language with all the ease and safety of assembly language programming. 
I cannot speak on COBOL.Net. I know Cobol from back in the 70's. The thought today turns my stomach to the point where I cannot even get a full sentance out. 
|
|
|
|
|
> It does everything every other language can do.
How about template programming or template meta-programming? What about inline assembly? What about built-in "design by contract" methodology (Eiffel)? What about cross-platform compatibility? What about ... (and the list goes on) ...?
|
|
|
|
|
Good point. But, not what I meant.
What I mean is that from the constructs of computer science (finite automata) it contains the same language features built into most (if not all) languages. For example, looping (for/next, do/while, while/do), selection (if, switch/case), etc.
If you drill into the finer points of each language, each has its strengths and weaknesses. I am making a more general comparison. Some of the features you mention come with huge pitfalls. For example, why use C++ to write inline assembly? Why not write assembly? If the function calls for that kind of performance, I want a tool that supports that type of development. What about macro substitution? I cannot begin to tell you the number of times I have seen programmers shoot theirself in the foot with a macro in C or C++.
I fully agree that C++ templates, and Eiffel "design by contract", etc. are wonderful features. Personally, I love to build objects using mix-in classes. This works best using multiple inheritence. Interfaces are great, but I don't want to have to build every interface from scratch.
|
|
|
|
|
Well... I have to admit that it does its job.
I just REALLY wish it had strong typing, and a better (c-like) variable scoping, but since I started writing PHP code, which doesn't have these features too, I really think it's better as a base language (I'm not talking about libraries here, in ASP they really don't exist).
Of course I'd like to have brackets instead of ugly if ... then ... end if blocks, but that's just syntax, and after a bit you get used to it.
VBScript it's not so bad after all, especially compared to PHP
Please, don't flame me if this was a full-VB only poll 
Luca Leonardo Scorcia
http://zip.to/kojak (only in Italian)
|
|
|
|
|
Luca Leonardo Scorcia wrote:
VBScript it's not so bad after all, especially compared to PHP
Apples and Oranges, Luca
Personally, i'm much fonder of PHP than of "classic" ASP (VBScript). Even though VBScript is somewhat more flexible (or at least was the last time i checked), PHP focused on one thing - creating web apps - and did it well. After all, no-one's gonna be writing the next OS or heavy-duty CAD program in either VBS or PHP.
Now, JavaScript - there's a language!
But in the end, it's all just database access right? And that stuff is just plain boring.
|
|
|
|
|
I voted 'Horrible', but I need to clarify.
My programming background is BASIC up to 1996, then Ada, C and C++ at University (among others) until 2001, and now mainly C, C++, VB6 and VB.NET (oh, and T-SQL). I only learned VB6 last year.
I'll admit to coming from a server-based background. My boss wrote a server in VB6 about four years ago, and we're hitting the wall. Well, I'm hitting my head against a wall.
From this perspective, I have the following criticisms of the VB 6 language and runtime: it's very hard to write any kind of concurrency, you can't write an application with no GUI (and hence, writing a service, while possible, is almost insane), has terrible support for TCP communications, and file I/O is also poor.
With regard to files, I've discovered that the Dir() function just doesn't work properly if you're deleting the files as you go.
The VB6 environment isn't conducive to large-scale codebases. There's no way to find references to a particular variable or method. You must handle each and every compile error one at a time - you can't get a list of all errors. You can't easily use an alternate editor. You can't jump to a particular line if you know which line you need.
Most of these annoyances have been fixed in VB.NET, of course. The thing that still irritates me is the line continuation operator, and the fact that you can't do end-line comments if you use it. The new VB.NET array initialisation syntax is useful (and means that we've been able to move from a manually coded to a state table form of implementing state machines).
|
|
|
|
|
I had to use VB for over a year, because I was being forced to write Word makros. This is my experience with VB:
- Went home with a headache every day, because to my poor eyes the code seems to flicker even on a good screen. All those upper case letters, no brackets, no "==", no shortcuts like "++",...
- The syntax to import functions from DLLs is horribly long
- Event procedures are identified by their names!
- People say, in VB you can write applications very fast. I don't know what they mean. Typing long words and reading code with nearly no brackets is definitely not fast.
That's why I don't like VB. I have already used it, I'm not a snob, and I don't need to grow up for this statements
|
|
|
|
|
Corinna John wrote:
- People say, in VB you can write applications very fast. I don't know what they mean. Typing long words and reading code with nearly no brackets is definitely not fast.
Point and click programmers say that. The apps look good, but they don't do anything
--
Seraphim Shock. Gold for your ears.
|
|
|
|
|
out of my own pocket, for a copy of VB 1.0 in July 1990 (or was it 1991?). Either way, it was within a month of the language being released.
I remember liking the language. I'd been working in C and trying to learn Windows programming and VB helped me get over the initial learning curve.
I think it was sometime in 1991 that I made the plunge into c++ (Zortech's excellent compiler). Then along came Access 1.0 - my introduction to Relational Databases.
Sicne then I concentrated on c and c++, though I've written real applications in VB (and written VBX's in C++) for real applications (where real is defined as used by paying customers to run business functions).
I think the problem with VB is the problem of RAD. It's really easy to define a database, create a VB form, drop a databound control onto it and get some records displayed. This makes anyone capable of following a cookbook capable of creating a basic BASIC application. Wow! That was easy! Hey everyone, look at me, I'm a programmer.
In the process they've failed to notice that design is required.
Now let's see it from the managers perspective. This guy using VB can create a pretty front end really fast. And the pretty front end is all the manager or the client sees. They don't know about database concurrency or paging or memory management. The problem is that the guy who got into programming because of the ease of RAD is unlikely to understand the issues of resource contention, let alone the issues of design. It works for a 1000 record database so why should it not work for a million records?
I've had to work with people who didn't believe it was necessary to understand the underlying machine and who were baffled when they hit a wall. I've worked with people who didn't feel a design was necessary up front, and were baffled when the customer balked.
In the first case, since they didn't understand the machine, they didn't understand the walls and how to step around them. And in the second case, it was easy for them so that was the obvious way. Unfortunately the real world doesn't work that way.
Hmmm I've wandered a bit from the point I think my point is that VB doesn't encourage rigour of thought.
Rob Manderson
http://www.mindprobes.net
Paul Watson wrote:What sense would you most dislike loosing?
Ian Darling replied.
Telepathy
Then I'd no longer be able to find out everyones dirty little secrets The Lounge, December 4 2003
|
|
|
|
|
I've used VB for DOS (well not actually used, I loaded, the removed it), I felt it better to stick with QuickC for Windows.
I am that is
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
