- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
You can't be too forward with disaster. You kinda have to play hard to get; make subtle hints that let disaster know you're interested. Then, see how disaster reacts and proceed from there.
Admin
Quadruple panic mode: data is sent to a dot matrix printer guarded by a crocodile infested moat?
Admin
Quintuple panic mode: The computer blinks the text "OH FUCK US" in big red letters. Then, it actually cries.
Also, by panic mode 15 (at least), some goats are gonna need to be sacrificed.
Admin
"VB application ...needs to be rock solid"
And pretty much the whole thing was downhill from here...
Admin
I plead the fith!
Admin
"Sadly, the developers behind this system are really nice and, to be honest, have been successful (so far as corporate is concerned) every year."
All hail generateRandomDataToFoolCorporate().
Of course that function also failed and the intern just invented the data.
Admin
The WTF is the fact that real database: Microsoft Access, doesn't have quotes around "real".
Admin
Y U Trollin? :P
But honestly... Can somebody answer me this...
I normally don't develop in VB, but honestly, if we were talking about the differences of c# vs vb.net, I never have to PInvoke anything anyways, a few minor differences in supported keywords (using statement, etc), and woopdie doo... what's the biggest difference between the two of them?
I don't believe there is a big difference. At all. Except that VB.NET syntax is ugly as hell. It's almost as hot as C# when you put the paper bag over VB.NET.............
Admin
See, NPR listeners, your spring drive dollars help everyone. Not only do your contributions help keep great programming like "Car Talk" on the air, you also help support local businesses that write software like this. So lines are open, please call now. We have a daily pledge package goal of $20k, and with each membership at the bronze level and above, you get a free tote bag and a travel coffee mug. At the gold level and above, a signed copy of Peter Sagal's latest book!
Admin
That's the problem with the usual corporate "if it ain't broke, don't fix it attitude" -- things can be completely broken, yet they appear not to be. I'm oh so happy to work in a place where we do things right -- maybe after a few iterations, think extreme programming, but they do come out right in the end...
Admin
VB has a bad reputation for enterprise level software, but coded well, it can be rock solid.
What I saw, as a C programmer "forced into the VB world in the 90s, was a slew of horrible programming practices implemented by first time coders.
I did like the quip regarding using Access as a real database though :)
Admin
You should see the code though, it really, really hurts me.
Admin
Well... Given that the OP is talking about a five-year time span and 'upgrading' to MS Access, I'd give it even odds that the app is actually VB5 or 6, and not VB.NET. That said...
Do you have all your switches set properly? Option Strict is on, VB6 compatibility is off? Then there's very little difference apart from the syntax, and the MSIL produced by a C# app and a VB.NET app will be almost indistinguishable.
(Almost. C# does some things more efficiently than VB.NET, and VB.NET's system hooks trade some inefficiencies for ease of access to Win32 APIs...)
OTOH, if Option Strict is off, or VB6 compatibility is on, then forget it - the MSIL produced by the C# compiler is far more efficient that that produced by VB.NET.
Admin
Admin
Admin
Oh dear. "For no apparent reason" suggests that there were a number of stored procedures that weren't being used and which should simply be deleted. Looking at the rest of what you wrote you meant something more along the lines of "Stored Procedures!?! [rolling eyes] Why on earth are you using those things?"
Stored Procedures improve performance, maintenance and security. Rather than removing most of the stored procedures, why not simply fix the issues that were causing the deadlocks. You know what those reasons are, they're in the trace, but I'm betting they were caused by bad or missing indexes, dates and numbers being stored in Char fields, missing locking hints and bad WHERE clauses.
Admin
And thanks to the title of this article, I have the Molly Hatchet song in my head.
For the record, this is a good thing.
Admin
I'm currently being forced to write some stuff in VB.NET. Truth is, I really, really hate VB.
However, as the previous poster said, VB.NET is essentially C#. Also, with Visual Studio 2005, the IDE writes 99% of the code for you so I NEVER have to type the following abominations: End If, Next, End While, etc. I'm sooooooooo glad for that because otherwise, I'd go insane.
I do still have to type Dim blah As Integer which is just as bad (if not worse) though :(
Admin
All things I was unaware of, yet it makes sense that this would be the case. I'm not a big fan of prior VB (I've even worked on some lovely offshoot of VB3 for old school handhelds and... it's the devil)
Have you ever run in to performance problems where switches are set appropriately so as not to take in to account legacy compatability, where the performance problem was primarily a cause of the language itself and NOT poor coding practices?
You mention VB.NET's system hooks.. Any examples you can think of where performance in accessing win32 api would hurt enough that C# would be a wiser choice? Thanks for the info!
Admin
more irish girl in the comic comments
Admin
It's actually a flaming moat filled with fire retardant crocodiles.
"Crikey! Look at that asbestos alligator, roight there!"
Admin
I hadda go ovah to the dot maytrix printah. It was SOOOO dangerous! Crocys swimmin this way and that in the moat. Then I saw him! The BIGGEST crocy evah! He was SOOOO dangerous!
Admin
Admin
Indeed, I was going on the assumption that due to the timetable laid out and the "greenness" of the original developers that it was a VB6-or-earlier app. But yeah, it is sort of annoying how when someone says "VB" you don't know if it's VB.NET, VB6, VBScript, etc.
Admin
That's sad, I could probably write something that did that in less than a week using php, xajax, mysql, and apache.
It wouldn't be pretty by any means, but really what do you need? 2 tables? first, middle, last, address, city, state, zip, pledge_amount, uid
users: uid, username password.
Admin
You're being generous there - VB.NET is essentially C# with training wheels and those helmets that retarded children wear.
Bah, I went on a tear on my Blog, I won't repeat it here http://www.schnapple.com/2006_06_25_archive.html
But yeah I too am on a side project right now where the dude insisted on me doing it in VB2005. I charge him by the hour so if he wants to pay more since it will take longer, that's his prerogative.
Admin
Forgot to mention 3 other important columns. A credit card type, expire date, and cc number.
Admin
So what happens in double secret panic mode?
Admin
DEFCON 5 PANIC MODE: The monitor explodes, sending glass shards into the face of the person looking at it, cutting all the information into the skin on their face.
You don't want to know what happens on the 6th level, although I'm pretty sure someone here will say.
Admin
I think this comment was featured to stop people from reposting the seemingly obligatory (read annoying) comments. And that would stop other people from writing back, "VB is actually blah blah blah." Which would give a pre-emptive SHHH to the very tired debate, "Well C# is better than VB because the MSIL blah blah blah." It doesn't seem to be working, though.
Remember the "C tic-tac-toe" incident? Lesson learned, I imagine.
Admin
Barf 4Eva:
All things being equal, probably not. Programming practices make a lot of difference. How often are you calling them? Every layer of abstraction introduces a little more lag into response time, as well as the chance for badly written code (because the abstraction keeps you from having to understand what you're doing).By way of example, being able to access My.Computer.FileSystem may be faster to code - but it'll be slower than just going right to an I/O stream directly, or whatever you ultimately need to do. Each '.' operator you use is another layer of method calls that need to be executed before you actually get down to business. And since the whole 'My' class structure is built around static methods, a lot more crap is going to be loaded into memory before you need it. Hell, a lot more crap is going to be loaded than you actually need...
Each release of VB.NET seems like it has reintroduced many of the concepts that made it so easy to write the same kind of bad (or lazy) code that gave VB a bad rap in the first place. IMO, C# forces you to have a better understanding of your platform, and to be more aware of your resource use.
Admin
Personally I think you are being as elitist as you think everyone else is being. Here's my take on things, and it is short because I don't need a lot of explanation to it. It is simple.
I'm a .Net developer, not a VB.net or C# developer, a .Net developer. What language am I faster in? The language I am currently working in. When I change languages there is an acclimation period but then I speed up. Each language requires different habits and I simply have to change them. Vb.Net and C# in themselves are neither faster to code in then the other, it's all about the developers comfort level.
So you code faster in C#, do so. Don't blame VB.net for being slower, recognize that it is your lack of comfort with that syntax. Someone else will be just the opposite and be just as correct as you are.
Admin
No, if you reach quadruple panic mode, the developer is placed on double-secret probation.
Admin
Not to ridicule the poster, but I don't know how many times I've heard some student or new programmer respond to a discussion of a problem-filed app by saying, "Hey, I could write a program to solve that problem in a week." From a simple statement of the problem -- "record gifts from donors", "count the number of votes for each candidate", etc -- it might sound like an easy problem that could be quickly solved. But real life is rarely that easy.
Like, a few weeks ago I was working on converting a customer address list and sales information from an old system to a new system. How hard could it be?, you might wonder. An address is an address, a payment is a payment, etc, right? Just read the date, reshuffle the format, and you're done. Except ... except for all the tedious details. Like in the old system returns were recorded as a new transaction, while in the new system they are attached to the original sale. The new system uses a different format stock number, and we had to generate that from available information in the old system. In the old system sales of products from certain suppliers were all under a single "vendor code", but in the new system we have different vendor codes for different divisions of the same company, and we had to figure out which division it was by various characteristics of the product. Etc etc.
The difference is that in school, the instructor typically creates a problem with no special cases. He'll say, for example, "write a program to read in these sales records and calculate total sales by division". Then all the records have the same format, all the data is valid and consistent, etc. Maybe he creates one or two special cases to throw at the students. But he isn't going to bog the students down in all the complexities that typically arise in the real world. Normally that's a good thing, because he wants to create a problem that can be solved in a week or two, make sure that the student learns how to use hash tables or SQL group-by clauses or whatever the current lesson is, and move on.
But some students seem to come out of school assuming that all problems in the real world are as clean and neat as their textbook problems, and that a programmer who takes two months to write a "simple total-the-sales program" must be a real incompetent.
Admin
VB can be a great development tool... especially for simplistic DB oriented apps such as this. This actually is akin to racism. For instance, one would say "I hate black people", when in fact they really want to say "I hate the typical black culture". See, not every black person acts like an inner city thug. In the case of VB, most VB developers learned using VB, with no real computer science training whatsoever... so most of what you see made in VB is garbage. You hate the VB "culture", not the language/environment itself.
Admin
I love that one!
Admin
Well, I was aiming more for facetious than elitist but yeah, it did come across that way.
Most of my side projects are short-term gigs where in the time it would take me to get back up to speed on VB's quirks actually add to the project. I'm actually trying to save my clients money by staying with what I know better but hey, it's their money. And truth be told they often want it, needlessly, in VB for the same reason I want it, needlessly, in C# - language snobbery.
That all being said, it's essentially true that VB.NET is an evolution of a programming language that was designed for idiots. Seriously - they wanted inept people to make Windows programs so that Windows would sell (yes, I know it was also on DOS for a time). VB prior to VB.NET had this "glass ceiling" above which things were impossible. So you're left with VB.NET which annoys C-based developers to no end because of its asinine syntax and annoys VB6 developers to no end because it's too different. And at the same time is constantly playing catch-up to C# in terms of features and IDE usability.
Language interoperability is designed to make it easier to staff projects - instead, it's wound up making developers have to needlessly learn close-but-not-quite languages and has made clients lock into particular languages even though they don't need to. Oh, and J# and COBOL.NET and the 50 other languages never took off anyway so it doesn't really matter or work anyway.
Admin
Do we send donors a tote bag or some other token gift? If they have a choice -- and surely they have at least "yes I want the tote bag or no I don't" -- then we have to record their selection.
Do we send them a membership card? If a married couple makes a donation, do they get two membership cards or one? If two, is each in their own name or do both say "Mr & Mrs Jones" or "Fred and Mary Jones" or what?
Surely we send some sort of confirmation letter. Where does the text of that letter come from? Does it vary between donors or is it always the same?
Does this system have to interface to our general accounting software? How is that done?
What reports do we produce? Surely someone wants to know how much we raised, probably with breakdowns based on some characteristics of the donor. What characteristics are those? How do we collect and record that information?
I believe you could produce a piece of unusable junk that resembled a solution to this problem in a week. So could I. But a quality product? No. It would surely take at least several weeks just to interview the users and get the basic requirements together. I was about to write "nail down the requirements", but that would take even longer, because in real life it isn't until you show the users version 1 that they suddenly remember all the additional little details that they forgot to mention earlier.
Usually at this point they express amazement that the ignorant programmer didn't realize that OF COURSE there are special rules for donors from California and Nebraska and any county in Massachusetts with a population of more than 5000 because of special laws in those states. And, oh, we have donors who prefer to remain anonymous, if we enter a bunch of donations with a name of "Anonymous" your program won't assume those are all the same person and add them together, will it? Etc.
Admin
So, I think what most people are saying is that they could get the basics of this app up and running in a less-brittle way in a small amount of time but that's not the point - the point is that the client wouldn't pay for it.
Admin
No, it suggests that they were implemented without any clear design behind them - sure, stored procs can be handy, but just tossing some in the app doesn't make any sort of sense.
Admin
DEFCON 5 denotes normal peacetime operations. It is the state of lowest military activity.
Admin
6th panic level, the application actually crashes, generates a large crash dump file, and automatically restarts. The data has to be extracted from the dump file post-mortem.
Admin
Admin
Silly human! VB doesn't do crashdump - just the first part.
Admin
Stupid edge cases!
Admin
And a secret page do download the whole thing to a secret account on gmail. Or so. Or another hole. TJX learned it the hard way that you don't want to keep CC numbers around.
Admin
Admin
6th panic mode generates nuclear explosion.. and there is no need in any data or processing of any kind -) also there is no 7th panic mode, as nothing is needed after 6th
Admin
Admin
Yes it does, it's just got the god-awful syntax to do it with.