I suppose this could be used to train the next generation of Visual Basic morons, but it certainly isn't going to be useful for the next generation of programmers.
VB is intended for rapid application development, from what I've heard.
I am not sure RAD promotes scaling well. You're trying to work fast, not necessarily well.
The whole CLR thing has opened things up for VB significantly... for example, you can finally work in multiple threads now. But I expect the CLR provides its own limitations, and I think there's just something fugly about requiring a monstrous library to do anything.
But then, I suppose you could say that it's ridiculous to force someone to have a monstrous operating system for the few things you want to do with it.
Which kind of comes back the the major philosophical differences between Microsoft and POSIX.
So if you are willing to grok -their way- and make your application fit their model, then you will get the benefits. If you don't like their way, or if you can't make your application fit.. then it will suck. Or you will have to find a different system. As far as BASIC itself.. well, nobody can say anymore that you can't write real software in higher level languages compiled to bytecode... They took the line numbers out of BASIC and put in labels, and that made it a hell of a lot easier... Then my memory is hazy but I think they added some kind of function call capability with parameter passing and a return capability better than a gosub?? So at that point, with library capability and I think also binding to other languages you are basically (no pun intended) not that different from a lot of higher level languages floating around these days.
I don't see what's wrong with VB now that it's hosted on CLR. On CLR it has all the same capabilities (no more and no less; ignoring syntactic sugar or lack thereof) as any other CLR language. CLR is basically Java but implemented better, and the only reason I'm still using Java is that it's not a Microsoft product and it has more open source momentum behind it.
The CLR just feels byzantine to me. It's easier to use than COM, but the way that it works feels... like over-engineering.
That said, I've used the CLR for a couple of simple projects, and found it far easier to program GUIs in C++ using the CLR than otherwise, at least on a Windows operating system.
Unfortunately, you seemed forced to link to the C++ runtime dlls instead of being able to link statically... and for me that's kind of annoying, because you then have to ensure you include those DLLs in your setup.
This said, what I hate more about VB than anything else is the effort it takes to build a proper setup for almost anything significant written in classic VB (I haven't had to deal with CLR VB yet in this context, so I don't yet know if it's as bad there as classic VB). You have to track down all the DLLs that provide the various COM objects you're using. And you might have to track down the DLLs that your COM object dependencies depend upon, too. In C++, much of the time, you can find out what your dependencies are by using DepWalker. You can't do this with COM. It's just a freakish nightmare.
I lost a half-day to that kind of nonsense yesterday. When I built the setup for this stupid VB GUI, I asked what it depended on, and got no answer. As it turned out, we were missing several dependencies... all stuff I had to track down for a customer who was anxious to have it all resolved before today.
It was a fucking nightmare... all because of having to figure out those stupid COM dependencies.
I'm guessing the whole CLR thing handles this better, by giving you a better idea of what you need through the manifest. I hope so.
We solve the last 10% problem by doing it in C++, wrapping it in COM, and making it work for VB.
I think there is value in learning from the bottom up. Learn how the
machine thinks, then work your way up towards stuff like that.
That's why we will always have jobs, because we know and understand things your average java programmer never will.
language. ( I can only imaging what types of "Useful" programs the morons
would write if Microsoft marketed Visual LOGO....
IBM sells this. It's called BPEL or something like that.
You drag and drop circles and squares and decisions and databases into a window. Click GO and it generates an amazing amount of j2ee code and resources, and you can even debug the pictures.
It's truly horrid.
But yeah, it makes doing what it does best easy and therest impossible, but if it's impossibly in ruby, you don't use ruby.
Don't hash the password. Run the whole session over SSL.
He caqn't afford an SSL certificate
Sun Jan 11 2009 15:09:13 EST from Nite*Star@uncnsrd
Also, can't afford a unique-IP-based SSL server.... (do you need a unique IP?)
I'm not sure what you intend to say here.
You do not have to purchase a certificate from one of the generally-known certification authorities to make use of an SSL-enabled HTTP server. An HTTP server does not need a 'unique-IP-based' address, regardless of whether or not it's supporting SSL or plaintext (in that the same HTTP server may be configured to serve many different domains).
Could you clarify what you intend to say?
Could you clarify what you intend to say?
I will, as soon as I find out from this person what he's talking about .... :)