WizBang...EXCELLENT POST :thumb::thumb::wave:
Printable View
WizBang...EXCELLENT POST :thumb::thumb::wave:
Some of us have been using VB6 years before .NET came out, and if you notice, most of "Us .Net guru's" only reply to post's here.. Just because we no longer create new projects with it, does not mean we don't know how to use it ;)..Quote:
Originally Posted by George1111
Some of us also still maintain a few old projects in VB6 that was not worthwhile updating to .NET.. I'm currently busy on one such update project, and have been busy with it for the last 8 months, FULL TIME.....
Yea WizBangQuote:
Originally Posted by WizBang
This sounds similar to what I wanted to suggest in an early post.
But this was in post#17 and then we have begun to discuss VB related to VB.net, which might have brought us a bit away from the originators needs.Quote:
Originally Posted by JonnyPoet
But IMHO all this may have given him a really good 'total view' about that theme. :D
__________________
I new that Gremlin :p
Could I go so far as to say you still have a soft spot for "your old love" (VB6)
Thanks for hanging around the forum - your contributions are most helpful !:)
To get this thread more on track with the actual topic, one difference between VB6 and .net is the practicality of distribution in various markets. For instance, the average home user isn't going to be on the "bleeding edge" with either software or hardware. In my experience, small companies generally aren't either. In addition, with software for the home user, there are still considerations such as download size/speed. So if a user doesn't have the .net runtime files, asking them to go through what for them is confusing and painful, just isn't usually going to happen.
Personally, I don't know of any home users who have the .net runtime or Vista. Not that I go around asking everyone I meet what they have, but by far it seems as long as the system isn't giving them headaches, they don't generally look forward to messing with it. In fact they typically dread the idea, and usually get newer stuff only when something breaks. Then they ask a buddy to do it because they don't know how, and can't afford to buy all new stuff or pay a shop to fix what they have.
So, the market you intend to reach has a LOT to do with which programming languages to consider. If the target systems are varied (such as home users), you'll have a wider market potential by keeping dependencies to the sort which more of those users are likely to already have.
In the corporate environment however, many if not all the systems are often upgraded at the same time. Plus they're usually (and wisely so) basically identical. In this scenario, you know precisely what the target machines look like. You'll probably be developing the software on one of those systems too, so when it runs on the dev machine, deployment glitches should ideally be minimal. Also, the install/upgrade is handled by competent people (including yourself), so you aren't dealing with clueless end users in order to get everything running. It is quite common for this type of software to be running on networks, working with large databases, etc. As I understand it, that's not as easy to do in some languages as it is in VB6 or .net, and I'm sure those who know both can describe the basic advantages one might have over the other.
My experience is almost 100% the opposite.Quote:
Originally Posted by WizBang
EVERY person (that I know) with XP, and some type of internet connection (even 56KB dialup) has the .NET framework installed.
Now, I will freely admit that my experience is biased because ot my US location, and the fact that I am more frequently in urban/suburban areas...
If someone at a party asks me ANY type of (Windows/PC related ) computer question, my first question back to them is "When was the last time you ran Windows Update (why dont you have it as automatic?) and selected all recommended updates?". If the answer is anything less recent than 2 weeks, my response is "GO do a Windows Update...come back and ask your question again when you have done this".
I do know a few people (<0.1%) who have PC's running some version of Windows with absolutely no connectivity, and absolutely no need to update anything.
Quote:
Originally Posted by WizBang
Thanks for your tip :)
I do not reccommend to anyone that they set the windows update to automatic. I have saw far to many issues over the years with updated software not working properly and/or breaking other things that were working just fine before the update. Many times the update in question has no benifit to the user and really can be a risky thing with no upside.Quote:
Originally Posted by TheCPUWizard
I would say that some people who have auto update turned off just are not aware of it but most have it off on purpose and many for good reason. I strongly recommend that anyone who knows what they are looking at look at the updates before they allow them to be installed and backup if any are questionable before allowing the update to occur.
As for the .net runtimes, more and more computers have those on them as manyu newer versions of various software products require the .net runtimes to work but there are still a lot of systems without the runtime and a lot more without a specific version.
The bottom line is "If it isn't broke don't fix it."
Exactly...and is a rcommented or critical update comes out it means that it is ALREADY BROKEN,, and needs to be fixed!!!Quote:
Originally Posted by DataMiser
For the users (<20% in my experience) who have the knowledge to make an investigation into each item, and draw the proper conclusions; then automatic download, with manual install makes sense.
For users who have a "critical" need, their machines should be managed by someone who does know what they are doing. There are many companies that perform this service (updates then get pushed by SMS or equiv).
Really? If the users computer works as expected then it is not actually broken. Sure there was a problem corrected somewhere in the os or one of the many bundled programs many of which are not used by most users and no matter how many updates you install there will still be 1000s of problems in the OS.Quote:
Originally Posted by TheCPUWizard
The point is, does the system work as needed? If so what is the need to repair a working system? Is it worth the risk of your system not working or our favorite software not working.
Automatic download is ok if you have a high speed connection as long as you clean up behind it. Otherwise I would reccommend notify only and any updates that are none critical to your usage of the system I would wait for the service pack. This serves two purposes. One the bugs in the updates have usually been fixed [not always] and two it saves a lot of disk space and registry entries as well as time and makes the system preform better overall.Quote:
For the users (<20% in my experience) who have the knowledge to make an investigation into each item, and draw the proper conclusions; then automatic download, with manual install makes sense.
Agreed, but updates should never be applied on a users pc just because they are available.Quote:
For users who have a "critical" need, their machines should be managed by someone who does know what they are doing. There are many companies that perform this service (updates then get pushed by SMS or equiv).
On the other hand on a developers test pc all updates should be installed for testing purposes.
Hmmm.. All Ok. But arn't we all together a bit far away from the origibal theme :D.
Hi BadNews01
I was wondering what your programming experience is..
Its all very well to tell you what to do, but it is relevant to know "what do you know about programming ?"
If you have limited knowedge and experience, how do you hope to re-engineer an application ?
eg, Because you can speak English, it doesn't mean you can write a novel.
Because you may understand the basics of a programming language, be it VB6, VB.Net, C# or whatever, it doesn't mean you will successfully build a major application.
The fact that you are asking what language is best to use suggests you haven't reached the beginning of your programming career yet.
Are you planning to go to "programming school" of some kind or were you hoping to muddle your way through a language like VB.Net which everyone seems to be pushing you towards.
Let me tell you, you dont "muddle your way" through .Net languages - VB6 perhaps, but certainly NOT .Net languages.
If your management have a mind to re-engineer an application, then I suggest they employ someone with a few years .Net experience. Then you get your boss to get the person to teach you and become your mentor - only this way will you
1) Learn about programming
2) Learn about system design
3 )Learn about a language like VB.Net (or C#)
You ain't going to do it alone - and while we at CodeGuru love to help with projects, we normally don't undertake major re-engineering work
Best of luck
One important note, is that just because m$ wants VB programmers to abandon VB6, doesn't mean .net is all that's left. There are currently a bunch of VB-like ones out there, with plenty of support that isn't expected to dry up any time soon. Some of these have been designed to easily import VB project files too. Some can create standalone and/or cross-platform applications. Some are even free and/or open source.
Here are just a few:
RealBasic
LibertyBasic
KBasic
Just Basic
CoolBasic
There's also Delphi, which has been around for quite some time.
I've tried at least one of those in the past, and found it too hard to work with. It wouldn't run my vb6 apps without major modifications, and then wouldn't be cross-platform without more work. I'll work with MONO if I need to port to other OS's. At least it's compatible with most Net apps, from what I've heard.
TBH.. Yes I do still have a soft spot for VB6. I haven't done much in it for almost a year now, but i still use a few app's i wrote in VB6, and have not even thought about 'Updating' them to .NET... (mostly the Hex editor listed in my sig) ..Quote:
Originally Posted by George1111
However with the current project i'm busy with i've learn't so much about .NET that i think i could rewrite the Hex editor to be much better that the VB6 one, with half the code..
Back on topic.. The best way i've found to learn a new language is to jump in and start coding, using everything you have to get info on syntax.. (CG, MSDN) ..
But... start small ... simple "Hello world" apps can teach you allot...
Gremmy..
I second that!Quote:
Originally Posted by HanneSThEGreaT
You would figure that such a presice thing as programming computers over decades, would be less than haphazard.
I'd have to agree that short term monetary gains only fuel the fire.
I think another thing is important here.
Just because the field has had patterns since the 60/70'(space program), doesn't always mean the patterns will continue to unfold in the exact same way. We could reach a point of saturation(i think we already have), where no one person can be a master, let alone keep up with the newest fad. Jack of all trades, but master of none. Spread as thin as butter.
I dont see it as haphazard at all. Changes in hardware capabilities completely change the focus of software development. Changes in economy and business goals also change this.Quote:
Originally Posted by TT(n)
Consider society in the 1700's. The "best" travel speed was about 10 miles per hour, with a range of about 100 miles in a day. Now consider modrn times where 500 miles per hour is practical and you can easily go 10,000 miles in a day.
This is only a factor of 100. A cheap modern computer is 6,000 times fastr than machines of only 30 years ago.
This is 100 times the rate of change in technology as the rate of change in travel. If you had proposed some of the common situations in todays world in the 1700's, you would probably have been confined to an asylum....
Very rarely is montary gain by the originators of change the primary goal. The total savings is the driving forc.Quote:
I'd have to agree that short term monetary gains only fuel the fire.
Not sure about your intent here...."Design Patterns" did not exist back then (I started programming in 1972) for software development. Even in digital electronics they were extremely rare. When describing something it was usually done by a long detailed explanation specific to that task, or by a reference to a previous project. If an engineer (software or hardware) from another company was brought in, the "learning curve" to become knowledgeable was much higher than it is today.Quote:
I think another thing is important here.
Just because the field has had patterns since the 60/70'(space program), doesn't always mean the patterns will continue to unfold in the exact same way.
I well remember writing "books" of documentation, where today I could convey the same information in a few sentances.
That is definately true. As I frequently state, it requires 15-20 hours of my week (over and above "normal" work) just to stay current. In some cases "current" simply means: I know something exists, I know the intendd purpose, I know where to find more information, and (ideally) I know someone who really undersands it.Quote:
We could reach a point of saturation(i think we already have), where no one person can be a master, let alone keep up with the newest fad. Jack of all trades, but master of none. Spread as thin as butter.
I absolutely agree. Early on, I would start a project just for fun, knowing I'd inevitably learn some things along the way. It was always worth it, even if it never got finished. Usually those projects were simple games, like Tic-Tac-Toe or something like that.Quote:
Originally Posted by GremlinSA
But this "ad-hoc" approach has risks. When interviewing "entry-level" candidates I can (with about 80% accuracy) determine if they learned the language from an organized course of study (book-carefully followed or classroom) or via experimentation alone.Quote:
Originally Posted by WizBang
It is very easy to write an "incorrect" or "wrong" program that does product the expected results. The approach once learned, can be very difficult to correct - often bacuse the person does not even realize that their approach is flawed.
On the other hand, books and classrooms have a tendency toward a sort of cookie-cutter effect - the student only learns what was taught, the way the teacher taught it. I believe that those with aptitude for a given thing will at some point diverge from the norm, and that's when they truly excel. Nobody ever breaks new ground when following textbook examples. Coloring within the lines tends to produce a predictable picture.Quote:
Originally Posted by TheCPUWizard
Sure, there are programming practices which most of us would probably agree are "wrong". But I'd say there are far more which boil down to better or worse, rather than incorrect.
As we all know, thinking outside the box has its rewards. That's basically how new things happen. How new technology comes about. Someone has to ask "what if".
It seems similar to the problem of creating AI. That is, how to get the computer to "think new thoughts", when all it knows is what was programmed into it.
EDIT: Just realized which forum this is in, so much of the post does not apply here at the detailed level (ie the use of STL), however the general points remain valid - so I have chosen not to delete it...
The very RARE ones will excell, the majority wo "diverge" will not make it past an employement interview.Quote:
Originally Posted by WizBang
Consider a tic-tac-toe game (with "auto-play" can be written in the minimum amount of (executable) CODE with a simple "char [19683]", 1 loop, and 1 conditional.
But is this the version you would submit on an exam or interview to show your knowledge of programming??
I have interviewed about 500 people in the last 10 years for C++ positions (it is one of the services my company offers to clients). These positions range from entry-level (<2 yrs experience) to senior (7+ years). The top "disqualifying" items.
1) Usage of a VC++ 6.0 non-compliant construct (or any "obsolete" approach)
2) Usage of char[], and char * instead of std::string
3) Usage of raw arrays instead of STL container
4) Usage of custom code rather than STL algorithm
5) Failure to utilize accepted Design Patterns (especially, Singeton, Observer, Visitor, Factory, Builder and Command)
#1 will stop an interview COLD.
#2-#3 are likely to immediately eliminate a candidate from consideration at any level
#4-#5 may be tolerated for an entry-level position.
@TheCPUWizard:
I wouldn't expect otherwise from you, since you emphasized books and classrooms. You hire as you see fit.
I never planned on working for someone else anyway, so I guess my stance is to be expected also :)
In some ways, this could help bring us back to the topic at hand. The language you choose may very well depend on how you plan to market your skills. If you plan to work for someone else, and/or with a team of people, writing apps for internal/corporate use, then .net might be more suitable. If your aim is writing apps to sell to home users, then, of the two languages in this discussion, I'd say VB6 is the more suitable one.
And that brings up yet another difference between VB6 and .net - decompiling. As of this moment, I've yet to see any proof that a .net app is as secure as that written in VB6. Google continues to turn up ways to decompile a .net app right back to usable source code. But that's a huge topic of discussion, which was left open in this thread.
AS A STARTING POINT..I also post regularly how a 4 year college degree (in the USA) is unlikely to get you a job upon graduationQuote:
Originally Posted by WizBang
It is not about who I hire. It is about how major financial institutions, industrial firms, and MAJOR software companies hire.Quote:
You hire as you see fit.
Very true, but with some key points:Quote:
I never planned on working for someone else anyway, so I guess my stance is to be expected also :)
In some ways, this could help bring us back to the topic at hand. The language you choose may very well depend on how you plan to market your skills.
1) I have worked for myself for the past 25 years [excepting for a 2 year break]. But to grow a company, the individual (except in extremely rare circumastance) must grow into a team, then into groups of teams, then....
2) MANY companies will not buy software products that do not conform to standards. (Approx 1/3 of my income over the past 3 years has been in helping client companies REMOVE software from their environment that is non-conformant. This has included the removal of any out of support technology, as well as any staff members who were not competent in the new technologies)
Programming practices are not necessarily related to what an app does, or how it may appear to the user. But it is true that an app shouldn't interact with the file system or something in an inappropriate way.
I'm sure this is what you're referring to, and not whether the programmer used For...Next or Do...Loop.
So these are two separate issue - compliance with a system and its standards, and conformity with expected coding practices.
Separate, but related...What I was referring to would include:Quote:
Originally Posted by WizBang
1) Giving a class specification to 3 different developers/teams and getting back drop in replacements that could be used interchangably.
2) Being able to "shuffle" the three implementations among the teams and they code maintain/update one that was written by another team as easily as their own (at a statistical level say within 5%)
3) Being UNABLE to identify which developer wrote the code simply by looking at the code [Looking as Source Control Checking or Comments is cheating]
4) Being able to hire a person, and have them be immediately able to sit down and understand the functioning of the code, without them having to spend time figuring out (deciphering) implementation details. [Learning the business requirements is another
5) [regarding obsolete items] Not having to support more environments than required. If I can meet all of my needs using 1 or 2 "environments", then the cost savings over having to maintain 6 or 7 can be extremely significant (for example having to manage via SMS updates for 3 different versions of the runtime costs more than dealing with just one. So If I can keep all of my code based on 2.0 of .NET then I save money by not having to process 1.x or 3.x updates with the attendant testing and support. At some point it becomes efficient to move ALL my 2.0 code to 3.5. Of course there will be a "bubble" where I have to support 2.0 and 3.5, but hopefully that is measured in weeks or months, not fiscal quarters or years.
I can see what you mean, and how and when it applies. It just doesn't appear to apply much if at all to independent developers. I would also expect there to be differences in concepts/practices/techniques between teams which handle different kinds of programming. So for instance, a graphics programmer wouldn't likely be able to sit down with some code for a business accounting app, dive right in and be instantly up to speed and comfortable.
So if one wants to work with a team, it's not just a matter of being schooled in all the same concepts and techniques and such. It's also deciding on an area to concentrate on, be it database, graphics, or whatever. There would also be sub-categories, because for instance, knowing DirectX isn't going to help so much with OpenGL.
So before deciding what language to learn, I think it's important to know what kind of market will be the primary focus. It may turn out that neither VB6 or .net is particularly ideal, such as with graphics intensive games. Knowing what sort of programming you really want to do might not be easy at this early stage. I guess I'd start with areas of interest - like what kinds of programs make you wish you knew how to make them.