Printable View
C# and VB.Net as languages are far better than JavaScript. They aren't even in the same league. C# in particular is what I think JavaScript should have been. C# is very elegant and expressive while retaining the advantages of a statically typed language.Quote:
Originally Posted by dilettante
Christ, not this again :sick:Quote:
Originally Posted by dilettante
Ab-so-lutely.Quote:
Originally Posted by Niya
The ONLY thing going for JavaScript is that it's a client-side language. The only thing. It's also lightweight (but the reality is that no-one actually cares about that, as long as it just works). Having said that, that one thing is a hugely massive thing which keeps attracting developers.
It really is a horrible language to develop in, even though quite a few have 'mastered' that art of hammering screws. The 'plug-in' like functionality is what really took the whole thing off: I'd say most developers (sic) in JavaScript depend on plugins (aka. other people's work) for a significant portion of their JS programming.
You mean plug-ins like jQuery ?
My web app is 11,000 line of my own JavaScript. Calling about a dozen or so web methods (.Net) for all the variety of CRUD and other DB / system operations needed.
The web methods are the most static part of the whole operation.
My JavaScript code calls those web methods to build up the web page with what appears to be tabs and grids of data and whatever the user requests. All AJAX - page never re-loads. Not your typical IIS app.
The same web app is used by all my clients - tax collection in PA, municipal admin software in MA, labor unions, social workers.
Using jQuery is like using any other library - jQuery tricks out CSS identifiers in a really powerful way. I exploit that by doing things like putting a CSS class of "awc-xxxxxxx" on any DOM element which then causes it to auto-bind to some database record element of "xxxxxxx". That auto-bind type logic is all my own JS code.
jQuery gives you neat controls - datepickers, auto-complete lookups and such.
If I need a grid, why not use the powerful SlickGrid - great grid functionality and totally extensible. And since it's my own homegrown JS UI code and .Net web methods I can "store" the column info (heading text, DB mapping, UI tricks...) for the SlickGrid's in the SQL database itself.
When one client asks for graphs and charts why not use some nice library like jqPlot - instant cool HTML charts.
I get to write one "set of functions" in my JS app to turn a SlickGrid "data source" into a source liked by jqPlot and I've got charts for all my customers.
No reason to re-invent the wheel when this basic stuff is handled for you allowing you to focus on functionality for the end-user.
And all my clients benefit from that work - all getting the enhancements requested by everyone else.
Clients pay 15% annual maintenance. Giving them new functionality that's funded by other development work that I do for other clients is good business sense.
Been doing this since on my own as an ISV since 1986 - PDP/11 BASIC; VAX/11 BASIC, DIBOL, COBOL, ASSEMBLER; VB6; VB.Net; JS; C#; C++
Add in lots of HTML, some XAML, some WPF
Made telephone call-in bulletin board apps for high schools with VAX/11 BASIC and Dec/Talk machines in mid-1980's.
Made a VAX/11 BASIC report writer (like Crystal - but on green-screen dumb-terminals) in the 1990's - sold it dozens and dozens of times (you could charge a real lot for software apps in the 1990's - things have really changed).
Made pocket PC apps with ".Net compact framework" for Phys Ed teachers to administer President Fitness awards - in the field - in the mid-1990's- all VS and .Net.
Making Android apps with Eclipse/Java-whatever it is talking to those same .Net web methods that my JS app talks to (now that's code and platform re-use!).
It never makes any sense to me why people would want to lock themselves into a singleton relationship with some dev tool like VB6.
People should be concerned about building up their suite of knowledge - how to CRUD, how to UI, how to validate, how to FTP, how to AJAX.
It's the bag of tricks that makes a developer. Being able to use those tricks in lots of lots of languages and platforms and being able to research for best practice is a hat trick I would hire in a New York minute.
I don't have a particular problem with JS as a language.
I do think there's a lack of decent development tools though. I'd kill for a decent ide to ease me through it. I also don't like that it's not type safe though that's a criticism you can level at any scripting language and I know a lot of people actually prefer that. Finally, I don't like the way it swallows errors when I make a mistake in a web page - that can make debugging hell. The only one of those three that's a real big deal is the lack of an ide and I'm not sure you blame that on the language.
That said, I really haven't played with it for several years and it's likely my opinion is completely out of date.
Its dynamic type system makes it truly a chore to debug. Its not worth the advantages you get.
I have a habit of coding by creating snippets of code and running it through and checking watch windows and such. I've had that habit since the days I had to code on a paper devices (pre screen devices).
With that said I don't mind what I lose for strictness with JS over something like a VB.Net heavily typed language.
There are some truly great benefits that I've found as I've gotten into creating commercial products with JS. And to think that my heavily invested WINFORM customers have embraced the browser world - truly great stuff.
Mendhak predicted I would go "all browser" many years ago - he was certainly correct.
I also do this, perhaps not as consistently as you do but I do it regularly enough. Yes it helps yet I still find dynamic type systems to be a chore. You have to put so much more effort into debugging, even for snippets. When a piece of code doesn't do what you expect it to do in a strongly typed language like VB, at least by default you can eliminate certain possible causes. In JavaScript when you get funky behavior, and you can't say right there for certain what is causing it, you have to go more in depth. That means single stepping, checking variables, flow control etc. Having to make sure that you didn't change a dynamic variable's type during the execution of a piece of code is something extra you have to check for that wouldn't even be a concern in a strongly typed language. I hate that to be honest. I also hate hate hate the way classes work. Classes aren't strongly defined but rather defined at runtime. I don't know why anyone would think such a design was a good idea.Quote:
Originally Posted by szlamany
However, I get why some people might love JavaScript. You can write some truly elegant code in it. The dynamic type system in combination with first class functions can be used to create some amazing works of art. Its just the debugging I can't stand. To be fair though, I haven't worked that much in JavaScript. I played with it for a couple months a couple years back. I haven't touched it since.
@szlamany I love hearing about your projects. I do strictly web development but on the PHP/MySQL side. I have slowly been integrating more and more jquery into my applications, however most of my "modules" (if you will) that are in my portal systems are using the traditional page refresh.
I love to hate javascript. I tried out node.js once and I just did not care for it. I am just used to using javascript as a front end element rather than a backend element.
No way in hell I'd ever consider using JavaScript for any kind of back end development. Hell, I'd rather use VB6. JavaScript is good at what it does, which is to manipulate your browser but its really a terrible language if you plan to use it like a true programming language.Quote:
Originally Posted by dclamp
Another thing is that I find JavaScript doesn't lend itself well to modularization. Always ends of as bunch of files with a bunch of functions. This can very quickly grow to be unmanageable. I suppose one can use the Visual Studio IDE to mitigate this by utilizing folders and regions and such but the language itself doesn't provide what you need to properly organize code. Its like programming in C(not C++ which has classes).
Thanks!Quote:
Originally Posted by dclamp
FireBug shows the exact line of those hidden errors - just set a break at that spot and re-do the operation and you are right at it.Quote:
Originally Posted by FunkyDexter
My whole recent involvement in this thread was because of Node.JS being mentioned. The proponents of Node talk about having a single syntax across the stack - like that is a good reason to go with it. My backend remains .Net because that library/framework is so well laid out and programmatically accessible. That's enough of a reason to leave VB6 behind - talking to the API from VB6 required knowledge of that stack's particulars. And it's not like you have to be fluent in the API-speak. Just enough knowledge from posts around the internet and you are sub-classing your way around your VB6 with total disregard for proper practice. And god-forbid you subclass in the ide...Quote:
Originally Posted by dclamp
I agree with you right up to the end - "like a true programming language". That's a big statement.Quote:
Originally Posted by Niya
My backend turns CRUD calls into JSON that the JavaScript front end must then translated into DOM changes. I'd say that 90% of my UI code is in JS.
When I did my last UI - in VB6 - it was 100% VB6. I got a decade of use out of that app - served me well.
Based on how happy my customers are as I migrate them from VB6 to my new web-app, I've got another decade of happy clients.
You mentioned classes and functions and source organization.Quote:
Originally Posted by Niya
Look at this JS code:
Here I am setting a VARIABLE equal to a function. That's a class.
I have variables in that function - they are private.
I have private functions in that function...
Now those private functions end with a RETURN statement that GIVES back to the instance of this class a series of METHODS - LOAD:, CREATE:Code:var grid_maker = function () {
var gmOffset = -1;
var gmNameSeq = 0;
var windowOn = false;
var parentInfo = {};
var i_set_current = function (i) {
var intGO = g_objGMaker[gmOffset].parentInfo.baseGO;
g_objGrid[intGO].reader.gminfo.gmcurrent = i;
};
var i_set_showlist = function (b) {
var intGO = g_objGMaker[gmOffset].parentInfo.baseGO;
g_objGrid[intGO].reader.gminfo.needlist = b;
g_objGrid[intGO].reader.gminfo.checkneed = false;
};
var i_set_layout = function () {
var strName = "";
var wesRM = $('#acs-reader-message');
if (i_need_listselect()) {
$(g_objGMaker[gmOffset].gmProperties.strControl).hide();
$(g_objGMaker[gmOffset].gmProperties.strPanel).show();
$(g_objGMaker[gmOffset].gmProperties.strWindow).hide();
wesRM.html('List of filter setups');
$('#acs-filter-new').hide();
$('#acs-filter-refresh').hide();
$('#acs-filter-returnlist').hide();
When you code up JS like this you appreciate why the {} brackets and ; terminators are needed!Code:}
o.ready = true;
}
return {
load: function (i, o) {
var loadOffset = -1;
var foundFId = false;
for (var j = 0; j < g_objGMaker.length; j++) {
if ((g_objGMaker[j].fid != null) && (g_objGMaker[j].fid == o.fid)) {
foundFId = true;
break;
}
}
.
.
.
},
create: function (s) {
var sName = "";
.
.
.
}
};
};
When you need this class you make it like this
This allows me to organize my code just like any other higher level language. Basically it's all up to me how I use these concepts.Code:var gridworker = new grid_maker();
And don't let me start talking about CLOSURE! You all recently got lambda functions in .Net - that's a taste of how the JS world rocks.
Oh and thanks for mentioning SlickGrid and jqplot. I will probably end up using them in my application. I am pretty much developing my portal feature by feature as they are required. So we haven't needed graphing or grids, but I know they are going to want me to start plotting data for their year-end stats.
Dylan
My backend releases CRUD at times, but never Java.
I don't think closures originated in JavaScript. They exist in languages where functions are first class objects and I believe there are older languages(functional languages in particular) than JavaScript that implement closures.Quote:
Originally Posted by szlamany
It seems closures were first used in PAL.
ah yes - back on topic...Quote:
Originally Posted by Shaggy Hiker
It's the "why" closures are so cool that's meaningful.Quote:
Originally Posted by Niya
When you have a user stay on a static web page - no GET's for a new page load - you end up being FULLY asynchronous.
So it's a natural need to release variables into closure so that when the callback function eventually gets called you have references to work against.
Here I have a function that submits an AJAX call to the backend server. Notice that I pass in "objWebParam" and "sender". In the $.AJAX() call I pass in "instances" of new functions that will run in the event that this AJAX call returns from the server. The NEW FUNCTION calls have references to "objWebParam" and "sender" - they just stay in scope long enough to handle the eventual running of these function calls.
I don't have to worry about SCOPE or creating some mechanism to retain and pass values.
You should also notice that the argument to the $.AJAX() function call is an OBJECT of NAME / VALUE pairs. Some are easy NAMES and values. One value is a STRING. Some values are function being created. JS is a really loose language and that's powerful - be careful is all you have to be.Code:function submitAjax(strService, objWebParam, sender, fncFinished) {
var objSubmit = {};
mergeObjects(objSubmit, objWebParam);
clearWebParam(objSubmit);
var strWebParam = $.toJSON(objSubmit);
$.ajax({
type: "POST",
url: "WebService.asmx/" + strService,
dataType: "json",
data: strWebParam,
contentType: "application/json; charset=utf-8",
success: function(msg) {
fncFinished(msg, sender, "success", objWebParam);
},
failure: function(msg) {
fncFinished(msg, sender, "failure", objWebParam);
},
error: function(msg) {
fncFinished(msg, sender, "error", objWebParam);
}
});
}
You don't have to tell me....closures are the reason I can do stuff like this:-Quote:
Originally Posted by szlamany
vbnet Code:
The above is an extract from my pet project, Demon Arena. Its a creature definition. Its a list that is basically a short program that describes how the creature behaves. Notice that a lot of it is made up of EMCD calls which are subs in the base class. Thanks to lambdas, I can embed function calls right into the definition. Closures make it possible to refer to stats such a its speed, which is implemented as a property, from these lambda calls if I so desired. Lambdas and closures allowed me to develop this system which was quite impossible in VB6. So I know just how powerful lambdas and by extension, closures can truly be.
I wanted to do something like this in the VB6 version but that would have required me to represent each ECMD call as strings, create a mapping that maps the strings to the proper method call and it would require me to create a parser and lexical analyzer to parse parameters, do data validation and syntax checking. Trust me, this is no easy task. Parsers and lexical analyzers that work properly are no easy feat to write. It would have requires almost as much effort as the 2D engine itself. That was unacceptable, so I was stuck defining entities in a ad-hoc and inflexible way. Lambdas made it possible to design the system the way I wanted.
This was one of the projects by the way which showed me just how outdated are archaic VB6 really is when compared to C# and VB.Net. That is why it irks me when people try to paint VB6 and the second coming of Christ. These people really have no idea what they're talking about.
Good stuff - nice to see.Quote:
Originally Posted by Niya
I totally agree - MS has done a nice job of advancing the syntax of VB - incorporating all kinds of useful constructs and advanced techniques.Quote:
Originally Posted by Niya
That should be reason enough to leave a language like VB6.
The only reason I landed in JavaScript (from VB6) was ASP.Net - with those painful backend VB methods that try to emulate "some event model" - not sure which one!
Hidden in that mess is just JavaScript/AJAX with a lot of "maintain-state" bloat.
I did one client implementation with ASP.net and realized that I was coding each form and use-model nearly from scratch. Buried in HTML is code hooks - buried in code is HTML hooks - all painfully laid out in the most verbose blather.
I like a lot more code reuse for each client facing form. It's just a matter of economy of time.
Sooooo, what your saying is there is a new VB6 and it is called JavaScript ...
or something similar to that i didnt read everything so i may have just made it up :D
Well it must be true.... I JUST saw it on the internet. And everyone knows you can't put something on the internet if it isn't true.Quote:
Originally Posted by NeedSomeAnswers
-tg
Quote:
Originally Posted by NeedSomeAnswers
You didn't read eight pages of commentary?!?!?!?!
You lazy slacker!!!!
It's like reading a paragraph. Read the first post and last post on each page... it'll give you the gist! :wave:
http://visualstudio.uservoice.com/fo...-edition-to-al
Here's another good idea, since all previous are rejected. Let's vote!
That is such a ridiculous idea. That's like asking someone for a free bicycle when they're offering a free Audi!Quote:
Originally Posted by MikiSoft
If they can give an Audi for free, why not bicycle too?
Because they expect good sense to prevail. No one would expect someone to want a bicycle when they're being offered an Audi. That would be insane and I don't think they expect insanity to prevail.
And what if they had to dig up their old bicycles from some old basement no one's even sure where it is anymore. And and top of that they are being asked to refurbish the bikes. That's too much effort, they already have thr Audis here and waiting for you and you want them to go back and find their old dated stuff and waste time on that ? If it were me the answer would be a resounding "hell no!!!". I'd be like, "u nuts bro ?....u gettn an Audi and you want to ride bikez....u needz ur head checked son...."
It depends on a purpose. For the bicycles, they're handy and they will never go out of fashion, so many people still prefer to ride that instead to drive a car because it will be always easier to go through the traffic. And most important is that in order to use it, you'll need some BASIC knowledge - unlike for Audi and other cars which usage is all but simple, counting all unnecessary gadgets that come with them ;)Quote:
Originally Posted by Niya
I think that's probably the key point. MS know that what's being asked for isn't really VB6, it's VB6+. This petition may serve to disguise that behind an intermediary request but they also know that it'd be about a week before more petitions popped up asking for enhancements. They're simply not interested in engaging in that process. .Net is Microsoft's offering to developers now. VB6 is not and isn't going to be again no matter how many petitions get created on User Voice. You can either move on or accept that your developing in a dead language - your choice.Quote:
they are being asked to refurbish the bikes
BTW, it's perfectly possible to drive the Audi without any of the gadgets. Indeed, you can stick one foot out the door and push if you really want to. If you want .Net to be as simple as 6 then you simply ignore all the more advanced libraries. You don't have to use them.
VB.NET IDE will never be as simple as VB6.Quote:
Originally Posted by FunkyDexter
Audi? More like a Rube Goldberg garbage truck.
Fits and starts, freezes in its tracks, groans and wheezes like a rusted steam calliope, heavyweight fuel hog, repair parts quickly go out of stock forever so you need to constantly rebuild it on the fly. And when the Framework breaks it can't be repaired.
How to repair the .NET Framework 2.0 and 3.0 on Windows Vista applies to Vista and all later Windows versions. Short summary: "Here's some stuff you can try, but you'll probably have to reinstall Windows from scratch."
No but its not difficult to use in anyway its just different, and if your not prepared or not bothered to learn what those differences are then you will find it hard.Quote:
VB.NET IDE will never be as simple as VB6.
When i have to use VS6 to look at some bug in a VB6 program i find it horribly dated. It's like going back to Windows 2000.
I don't think you have tried to use .net since version 1.1 of something as this bares no resemblance to my experience.Quote:
Fits and starts, freezes in its tracks, groans and wheezes like a rusted steam calliope, heavyweight fuel hog, repair parts quickly go out of stock forever so you need to constantly rebuild it on the fly. And when the Framework breaks it can't be repaired.
.Net just works i have never ever had to repair the framework and i have never come across a customer who has either!
Also you have a lot more parts and tools then you ever did with VB6 and with many other languages.
I have a question: why should it be free? Would we still have these complaints if it was available for $600 (which, if I recall, was Retail price - but I think that was for Visual Studio 6).
So, all those people who want VB6, already have VB6, so why does it need to be available? For new programmers, they have much more powerful offerings which are no harder to learn.
It's like being offered an Audi but demanding a bicy.....oh, wait, we already did that analogy....
How about -Quote:
It's like being offered an Audi but demanding a bicy.....oh, wait, we already did that analogy....
Its like being offered a Lobster but demanding a Prawn
or
Its like being given a Picasso but demanding an Emin
or
Its like being taken on a trip to the Bahamas but demanding a holiday in Bognor Regis !!
as acceptable alternatives :D:bigyello:
I'm trying to hold back - really - argh....
Why would any company dedicate even 1% effort towards supporting a legacy system that has been retired for years??
And if you think it's possible - even for a minute - that the old VB6 code that MS has might not work perfectly on new devices and O/S's and who knows what. If you think that's possible then the 1% effort goes way up.
What would be the rationale that would allow this to be a project that anyone who has any business sense would ever entertain!?!?!
You are asking Ford to start selling Pinto's again - not new Pinto's - just old ones stored out back with maybe gas tanks that blow up!
If you want to drive a bike - fine - just get off the highway!
Same here. The irony here is that I've had these problems with VB6. ActiveX breaking all over the place with fits of cryptic errors like "Automation error". And that ****** package and deployment did a piss poor job of resolving dependencies. You always ended up making a batch files to register this and that. It took forever to add the missed dependencies to the wizard so writing a batch file was far less painful. I for one am glad I'm done with the mess called VB6. I've never had these troubles with .Net. NEVER! MS did a really great job with .Net.Quote:
Originally Posted by NeedSomeAnswers
Great. Now you just removed the tint from my rose-colored glasses.Quote:
Originally Posted by Niya
Yeah, I'd forgotten about the crappy hoops you had to jump through. One did eventually get good at it, but dependency management was a pain. I ended up writing a script to create the script for NSIS installer, to get all the correct files.
Are we talking about the same product ?Quote:
Originally Posted by dilettante
You had to become a man some time. :D :)Quote:
Originally Posted by SJWhiteley
Just a gentle reminder to everyone to keep this polite. This discussion is known to get... heated.:)
VS2013 is every bit as simple to use as VS6 was. You add new modules and forms to your project in exactly the same way (rclick on project and select add). You can add events in exactly the same way (double click on the element and use the drop downs to specify the event). You can access the code window in exactly the same way (double click on the form or right click and select View Code Window). In it's basic functionality it's all but identical. VS2013 certainly has a bunch of extra productivity tools you can use if you want but if you don't want to use them then just disregard them.Quote:
VB.NET IDE will never be as simple as VB6.
The languages differ but minimally. You've still got all you're old constructs. A loop's still a loop. A module's simply a static class. About the only thing that differs with any substance would be the control set which is more extensive and flexible in .Net. There may be some learning curve there but it's a wonderfully shallow one. Again, .Net framework 4.5 has a bunch of extra features that weren't in VB6 but if you don't want those feature just ignore them.
what this discussion???Quote:
Just a gentle reminder to everyone to keep this polite. This discussion is known to get... heated.
I don't believe it, only users with great common sense and erudition have posted in this thread!
There is a simple solution:Quote:
Originally Posted by FunkyDexter
When a thread about VB6 or a possible future VB comes up, start banning anybody who comes in and starts trolling about .Net as off topic, inappropriate, and inflammatory.
Nobody seriously expects Microsoft to revive the old product line so those "new VB6" threads like this one would just die pretty quickly. They only get started by a small minority with unrealistic hopes and dreams.
The very mention of VB6, which was replaced by MS with VB.Net, allows for any mention of .Net to be exactly on topic.Quote:
Originally Posted by dilettante
Was your "inappropriate and inflammatory" meant to be polite to the .Net folk?
VB6 hobbyists or those with apps to support might have hopes and dreams - realistic or not is outside my jurisdiction.
As senior programmers in our fields I believe it's up to us to help push people into modern venues - .Net, JS, Python - whatever.
I'm perfectly happy to start banning anyone who trolls on either side of the debate. It's perfectly possible for the discussion to be wide ranging and encompass all sorts of alternatives without descending into the unpleasantness we've seen in the past.Quote:
When a thread about VB6 or a possible future VB comes up, start banning anybody who comes in and starts trolling about .Net as off topic, inappropriate, and inflammatory.
I wouldn't want to ban mention of .Net in these threads because
1) the VB6 fans seem just as ready to bring it up as the VB.Net fans.
2) it is a viable alternative in the context of people's worries that VB6 is no longer actively supported and as such is a valid part of the discussion. It's certainly not the only alternative and you yourself have raised several others in the past. I may not always agree with your recommendations but I certainly appreciate the value of you being here to push us out of our comfort zones - that's a very important contribution and your voice has probably been more influential in me finally forcing myself to start actively moving away from desktop (not abandoning it, mind, just making sure the other arrows in my quiver are nice and sharp) than any other. Having you challenge the .Netters is valuable and having .Netters challenge the 6ers is valuable too, as long as the challenge, and the responses, are polite.
This kind of thinking is why so many innocent people were burned at the stake in times past. You're basically silencing the voices that challenge the prevailing world view. Putting your fingers in your ears isn't going to change the fact that science is not the devil's work anymore than it would change the fact that VB6 is a child's toy compared to VB.Net.Quote:
Originally Posted by dilettante
C'mon now, this is just silly. Anything you can do in VB.Net you can do in VB6, and vice-versa. The only question is the amount of work involved. Some tasks are easier in classic VB. Some are easier in VB.Net.Quote:
Originally Posted by Niya
I don't see why this is so hard. VB6 and VB.Net are different tools for different jobs. People need to get over the shared "VB" in their names. C and C++ and C# all have C in their names, but guess what? They're different tools, too! Each has pros and cons, and a good developer will pick the right tool for the job.
People can argue about the syntax and implementation differences between classic VB and VB.Net, but honestly, neither has produced particularly good publicly-available software. For me, that is the Achilles Hell of the "bring back VB6" contingent. No one can point to a piece of software and say, "this was written in VB6, and it's good enough to warrant the return of the language." Do that, and Microsoft might actually take the requests seriously. Whining and theoretical arguments are meaningless.
I think the same warning is in order for VB.Net users. If people aren't producing high-quality, publicly available software that uses the language, Microsoft will eventually drop it. And just as well; I'd honestly like to see them double-down on C#, rather than splitting their attention between it and VB.Net. But maybe that's just me.
If anything, us VB users (6 or .Net) should be far more concerned about the disappearance of Windows development as a whole. But maybe we are far enough along in our careers that only the young guys need worry about that... ;)
I'm not sure how far "far enough" might be. I retired from one career and found another in contract work. All but one of my regular sources of contracts has made significant moves, mostly to commodity Cloud providers on the server side and thinner clients like Chrome OS and mobile devices on that side. One of them is already 100% Microsoft free now after many years of being Microsoft-only.Quote:
Originally Posted by Tanner_H
Give it another five years and the wheel might turn back around again. But Microsoft is already working hard at their own transition plans and that five-years-out world might look a lot different from today. Right now WinRT and Azure are the hot technologies, tomorrow who can say?
None of that bodes well for the "stealth IT" coder writing desktop applications when he's really paid to answer the phone, deliver mail, clean fish, etc. There is a need and a market there but innovation in that area seems almost flat.
The only thing I've found may be easier in VB6 is writing shell extensions and even that is no longer an issue since version 4 of the CLR which permits side by side execution. Simple Winsock applications are also easier to write in VB6 because of the Winsock control. Winsock in .Net is closer to how the Winsock API is which is quite intimidating for people who are new at Winsock programming.Quote:
Originally Posted by Tanner_H
Aside from those two scenarios, I've found nothing else to be easier in VB6. .Net is especially strong when it comes to dealing with collections(sorting, aggregating, filtering etc) which VB6 was weak at. This accounts for much of the productivity boost I gained since moving to .Net since arrays and collections are such a fundamental part of even the most simple programs.
Another welcomed thing was not having to rely so heavily on the Windows API since so much of it is wrapped in the framework. Gone are the days where I would have to hunt for constants in C header files because the documentation for a particular API didn't provide the value. Gone are the days where I would have to endure frustration when my app mysteriously crashed because I made a mistake in declaring a particular API because of poor documentation or my own lapse in cognitive function. Don't get me wrong, there are times you still need the API in .Net but I've found that I need it far less. One particular example is file handling. That retarded Dir function in VB6 was so weak and useless that using the API was the only choice. I have modules upon modules with tonnes of API declarations and helper functions to make them VB friendly. I always had to add some of them to any non-trival project I was working on. The only consolation was that I only had to write and debug once and then I could re-use them as much as I needed.
I'm not too concerned about that. If this becomes so then I'll have to adapt. I've been adapting to such changes for more than a decade so you can be sure you won't see any "Bring back Windows" threads from me, as much as I love Windows.Quote:
Originally Posted by Tanner_H
Note though that I'm not hung up on the language itself as much as the libraries available for it and the IDE. Yes the language has been made better in .Net but for me, the real improvement came with the new and highly productive IDE and the massive framework which allows you to do almost anything right out the box.
And then...Quote:
Originally Posted by Tanner_H
So, if they are effectively interchangeable, what is VB6 used for that VB.NET isn't, and visa versa? From my experience, there's nothing easier in VB6 than there is in .NET (maybe the items mentioned, but the minor increase in complexity of socket programming is more than compensated for by the added versatility, capability and reduction in performance impact).Quote:
Originally Posted by Tanner_H
Regardless, VB6 is at a 'final version' (SP6a?) and will not change. Isn't that a good thing for developers [using VB6]? For those that wanted to continue to use VB, but wanted improvements, MS brought along VB into the .NET world, and maintained a forward upgrade cycle which didn't break anything - for over a decade.
I work with doctors who do charity work in 3rd-world countries. While a lot of my work is moving to mobile devices like iPhones, it used to be that doctors would carry a collection of diagnostic software on a USB drive, and simply plug it into whatever PC they have access to on-site. (This approach is still used in areas with crime problems, as a stolen USB drive is easier to replace than a stolen iPhone or laptop.)Quote:
Originally Posted by SJWhiteley
Anyway, there are no guarantees about these target PCs. XP is common, a lot of times they don't have Internet access, or they haven't been updated beyond the initial OS install. Doctors can't waste time playing tech support, so they need software that can be plugged into a PC like that and run without any effort or configuration on their part.
VB6 is ideal for this. Its projects run on anything from XP to Windows 10 without needing configuration or additional run-time dependencies, and because my focus is on medical imaging software, I have to produce code that does things like real-time Retinex adjustments on a video feed from a pill camera. There are only so many programming languages that a) can run without dependencies or special run-time configuration, and b) provide native-compiled performance.
So you're right: VB6's stability, predictability, and lack of run-time dependencies is exactly why I use it on some projects. (I'm not campaigning for a new VB6, in case that wasn't clear.)
Developers seem to forget that there are use-cases for all programming languages. If there weren't, the languages would disappear. Just because VB.Net is a good fit for one person's work doesn't mean it's a good fit for everyone. Same goes for the VB6 guys who think VB6 is the solution to everything. People waste an inordinate amount of energy evangelizing various programming tools.
I have something special for the .Netters worth reading: http://en.wikipedia.org/wiki/TradElect
On the other side: "VB6 is still the product to beat in performance." - Paul Yuknewicz
;)
Actually these requirements make C/C++ ideal for this. Static linking, which the C++ compiler can do, can eliminate the need to install any dependency. And pointers make for writing image processing code somewhat more elegantly than VB6. Plus, VB6's arrays have the extra overhead of being SAFEARRAYs instead of direct references into virtual memory so the code will always perform better when written in C, however with release build optimizations you can gain a close match to the performance of a C/C++ implementation. VB6's greatest advantage over C and C++ is that you can churn out apps much faster. You have to do too much plumbing with C/C++.Quote:
Originally Posted by Tanner_H
My only point in this mess of an argument is that VB.Net is far better than VB6. VB6 was good in its hey-day but its been overshadowed by VB.Net. Your point about needing software to run on XP systems without any hassle and its native performance are a couple of only a very few sensible reasons mentioned that VB6 is preferable to VB.Net. Your requirements are very specific so its understandable but the vast majority of reasons usually stated in threads like this are garbage.
This quote is taken out of context. See the original source (from 2009) here.Quote:
Originally Posted by MikiSoft
Paul made the comment in reference to the VB6 IDE, not to compiled VB6 projects. The VB6 IDE is indeed very low-resource, and on modern hardware it provides excellent compile performance.
That said, the compiler is much less sophisticated than recent .NET iterations, and obviously the IDE is not nearly as powerful or as user-friendly as modern versions of Visual Studio. So it is what it is.
tl;dr - don't trot out this quote to defend VB6 projects. It's referencing the VB6 IDE, only.
Is there a point here somewhere ? What does TradElect have to do with what we're talking about ?Quote:
Originally Posted by MikiSoft
Whatever, we were talking also about the IDE here.Quote:
Originally Posted by Tanner_H
It's based on .Net and it was a big failure, they had to switch to Linux after 4 years of developing that project and after two years of service until it failed miserably and caused economic damage. It was developed by Microsoft and Accenture. Enough said?Quote:
Originally Posted by Niya
Read....Nuff said.Quote:
Originally Posted by MikiSoft
Not when the UI requirements are considered. A complex multi-featured UI that spans all those Windows OS versions is incredibly difficult to do with something like MFC, or you once again get into the problem of shipping additional libraries for something like Qt.Quote:
Originally Posted by Niya
And you misunderstand on performance: obviously I could write faster image processing code by hand-tuning C/C++ implementations. (And for really performance-critical stuff, this is the case.) But the development cost is not generally worth it, especially with charity work, where the most important factor is very high reliability while keeping costs as low as possible.
(C# or VB.Net wouldn't solve any of the performance issues, either. You'll always end up at C/C++ or ASM if performance is crucial.)
I don't disagree. But if we're being honest, VB.Net has a very small niche of use-cases too. (Basically, VB6 guys who can't be convinced to give up VB syntax for C#.)Quote:
My only point in this mess of an argument is that VB.Net is far better than VB6. VB6 was good in its hey-day but its been overshadowed by VB.Net. Your point about needing software to run on XP systems without any hassle and its native performance are a couple of only a very few sensible reasons mentioned that VB6 is preferable to VB.Net. Your requirements are very specific so its understandable but the vast majority of reasons usually stated in threads like this are garbage.
I see VB.Net and VB6 in pretty much the same light: not recommended for newcomers, and useful only to people who are maintaining existing codebases or who have extremely specific use-cases. This is what makes disagreements between the two groups ironic, IMO.
No, not whatever. You keep using this quote without understanding it. VB6 does not magically produce faster code than modern versions of Visual Studio. Repeating this quote without understanding it makes conscientious VB6 users - like me - look like idiots. I don't appreciate it.Quote:
Originally Posted by MikiSoft
If you want to be taken seriously, don't use obviously false information to make your point. You aren't helping the VB6 cause by doing this.
So does this mean VB6 users should also switch to Linux?Quote:
Originally Posted by MikiSoft