What if there was a NEW vb6

Quote:

---

Originally Posted by szlamany

I just recently took a 15 year old VB6 report writer engine using the PRINTER object and converted it to .Net using a PDF creator library running as a web service.

---

The very same thing is available for VB6-Users in appropriate Classes (or COM-libs),
which can also be run serverside (behind classic *.asp-Pages for example, which support COM).

If you have an interest in a example, how to use VB6-Drawing-Code which worked
against the VB6-Printer-Object, *unchanged* - to produce a PDF-ByteArray directly
(without using any PDF-Printer-Drivers - and completely InMemory) from the very same
Drawing-Routines - I can provide one.

Quote:

---

Originally Posted by szlamany

I prefer being in a browser now - with a clean standard JavaScript library (like jQuery).
I am more satisfied with the product I deliver as are my clients.

---

But that has nothing to do with VB6 not being a language which stands out
(in the realm of Desktop-Apps which is the only remaining "great strength" of
the MS-OS-platforms).

WebApps which make use of jQuery and other js-Frameworks aren't "classically
developed Desktop-Apps" anymore (and they have quite some restrictions,
compared to the "real-thing" ... the time ADOBE-InDesign- or AutoCad-users
will work in the Browser (with the same performance), will be the time where
WebApps "have taken over". But a few years (if not decades) we will still have
to wait for something like that to happen.

Quote:

---

Originally Posted by szlamany

I just started a 3 year project to convert over a decade of VB6 LOB to browser/iis web methods.
The client chose this method because us the decade of SQL data that I am going to keep stable.

I can share my web services with an Android app I have - another huge selling point for my customers.

I can't imagine how I could do any of this with VB6...

---

The very same thing is possible with VB6 (which can produce COM-libs, which can
be run serverside in native-performance by the IIS).

In another posting of yours (some month' ago), you mentioned that your serverside
Code is basically reduced to "talking to the DB" (getting serialized resultsets - mostly
as JSON) back to the clientside (the WebBrowser).

Care to share, about how many lines of (serverside) .NET-code we talk about here?

Olaf

Quote:

---

Originally Posted by Shaggy Hiker

...................
I don't know which path to Windows was more common, so if you want to believe that VB was what made Windows, I can't prove it either right or wrong. I will point out that there IS an alternative view that makes sense.

---

It’s working like religions do.
As more strong the religion is , as many new believers gets.
As many the new believers are , as more stronger the religion becomes.

Till the schism.

Quote:

---

Originally Posted by Schmidt

Care to share, about how many lines of (serverside) .NET-code we talk about here?
Olaf

---

I would assume that you have a point to that, so I'll tell you that I did something like that, as well, but the server side code is trivial. JSON comes in as a Dictionary(of string, object) (actually, it can be turned into such a thing with a single line, but it's actually a string, of course). The amount of code to put that into a datatable is roughly half a dozen lines per field, all of which is validation code (because, in my case, the field may or may not be present, and may take on one of two forms), and the code to put the datatable into the DB is about five lines.

This may be partially due to the fact that the client side program is entirely JS and is intended to run on mobile that is not connected to the internet, so uploads happen only when a connection is established. This probably simplifies the server side code considerably, but it could be simplified further. Had I designed it a bit differently, it would be one line per field to get it into the datatable, plus two lines per record of overhead, then the same five lines to put the datatable into the DB.

Is that a helpful description?

Quote:

---

Originally Posted by Shaggy Hiker

I would assume that you have a point to that, so I'll tell you that I did something like that, as well, but the server side code is trivial...

---

Yep, that was exactly my point.

Due to the ever evolving js-Frameworks, the "serverside layer" we have to develop,
is basically degenerating to a handful of lines of (mostly DB-engine addressing) code
(no matter what the serverside language is, be that PHP, Python, .NET-based languages
or plain and simple VBScript in classic *.asp).

At work I currently develop with OpenUI5 (a generously licensed js-Framework from SAP,
which allows declarative development).
This stuff is so powerful, we can even define clientside validation declaratively already in
the XML-Views, so roundtrips for serverside Validations are completely avoided - what
the server finally gets is an already validated JSON-result from the XML-defined Form,
which only needs (after JSON-deserializing into an Object) one line per JSON-Field to
move the Data over into an ADO-Rs, which is then finally stored in the serverside SQL-Server.
In case the JSON-FieldNames match the DB-FieldNames exactly, this is a generic task for a
whole lot of the simpler Forms.

To "build-up" an initial Form in the Browser, we have to select basically only two Strings from the
DB at the serverside (delivered in one roundtrip) - the initial "JSON-Model" - and the matching
"bound XML-View" for that Model - these two Strings are enough for the Browser, to generate
the GUI for the User (with the help of the OpenUI5-js-Classes).

To generate these two Strings, we use a VB6-App to conveniently define the Form-Fields
and their Binding-Descriptions against the matching (JSON)-Model-Fields.
A finished Form-Definition is then uploaded to the DB (directly from the VB6-based
Designer-App) with a simple Insert for these two String-Fields over the http-5.1-Object.

Olaf

Quote:

---

Originally Posted by Schmidt

The very same thing is available for VB6-Users

---

The CRUD interaction code has always been the same - since I coded on PDP-11's in 1980. Trivial? What isn't trivial?

If you have any experience writing app's you already know how to fill the data from the CRUD into the display. Hopefully not line by line!

My first FillScreen function 35 years ago isn't a whole lot different then the JavaScript loop I have now that takes each JSON element and finds a corresponding HTML element with a matching CSS name.

My backend code is the same at all my implementations - and as you imagined it's mostly CRUD-to-JSON-and-back logic. There is more though - I have to talk to AD to authenticate (.Net has that namespace) - I have to talk to DocumentFormat.OpenXml to make spreadsheets - another .Net namespace. Could I get to all this from VB6? Would I need to talk to that poorly documented API? I'm sure you could argue that doing it in VB6 would be a cake walk for someone such as yourself.

I'm using IIS for a couple of reasons. First my customers are all MS sites. More so though - I had experience pushing the limits of traditional postback-style ASP.Net. The obtuse-event model of ASP.Net and the bloated page state retention - not so easy to make a rich web app. I have never used classic ASP - not sure how far you could have pushed that VB6-backed product.

Without those constraints I probably would have gone with a non-MS web server and never posted in this thread about VB6 and .Net.

I've been re-inventing my apps and my coding life over and over again - I relish the next platform. I get to go back to prior clients and show them their old apps with a new skin.

We are programmers aren't we? We make our living writing code.

Would you commiserate with a carpenter - a deck builder let's say - who refuses to use Trex? He so loves that wood - can only put a nail through wood. Can't even imagine how people could work with that new plastic product...

You just mentioned that you worked with some SAP stuff. That's miles away from VB6 right? Seems you have a varied life - why the VB6 cheerleading?

btw - the .Net PDF class makes the pdf in memory - no print driver.

My father may have helped design your pdp-11....who's your daddy?

Seriously though, I think what you are both saying is right: When developing for the web, the fat server design seems unwarranted already, and will likely become more so. In my case, the server couldn't do anything because the client was entirely disconnected. That model is in its infancy (and may remain there as connectivity becomes so common, especially if Google floods the air with WIFI drones), but it still works fairly well. I still believe that JS and the web platform is still in the early high-growth stage such that if we were to come back and read these posts in ten years we would be finding them quaint.

The backend could become pretty insignificant, and the language used to write it even less so. If that is the case then we would also expect that companies like MS would be trying to make it even simpler (and creating big black boxes in the process, but they'd be simple to set up, ideally). Those simplified backends would probably be .NET from MS, Java from some others, and possibly even Node.js (though I really feel that JS is unevolved at this time and is liable to be replaced).

Quote:

---

Originally Posted by szlamany

I have to talk to AD to authenticate (.Net has that namespace) -

---

There's also COM-Support (ADSI) for talking to AD services:
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Quote:

---

Originally Posted by szlamany

I have to talk to DocumentFormat.OpenXml to make spreadsheets - another .Net namespace.

---

Same thing - COMponents for use in VB6 (or *.asp) are available for stuff like that too - e.g. here:
http://helpcentral.componentone.com/...8.html#1470703

In case it's just simple "unformatted DB-Record-Exports" I'd perhaps use ADO-Drivers directly.
There's also VB6-Classes available in Source, which can generate formatted *.xls-Output.

Didn't need that so far (from serverside code) - depends on the requirements, what I'd choose.

Quote:

---

Originally Posted by szlamany

Could I get to all this from VB6? Would I need to talk to that poorly documented API?

---

Don't know what you talk about here with "poorly documented API" (it's the second time already)
(surely not the little VB6-Runtime)?

Quote:

---

Originally Posted by szlamany

I have never used classic ASP - not sure how far you could have pushed that VB6-backed product.

---

Classic asp is not a "VB6-backed product" - it's VBScript and JScript (or Perl)-support over
the IIS at the Web-serverside (along with the ability to instantiate all kind of COM-libraries
within that script - also with specific IIS-COM-interfaces handed into the Script-context,
which represent the serverside (usable in your own COM-Dlls even early-bound as Server-,
Session-, Request- and Response-Objects). Serverside-Debugging is available too,
when you delegate back into a running IDE-session of your VB6-Dll-Project.

Quote:

---

Originally Posted by szlamany

I've been re-inventing my apps and my coding life over and over again - I relish the next platform.
I get to go back to prior clients and show them their old apps with a new skin.
We are programmers aren't we? We make our living writing code.

---

What does this have to do with VB6 - or .NET - or any other language or tool?

Quote:

---

Originally Posted by szlamany

You just mentioned that you worked with some SAP stuff.
That's miles away from VB6 right? Seems you have a varied life - why the VB6 cheerleading?

---

I'm not cheerleading anything - I'm just correcting misconceptions (sometimes misinformation)
about VB6 (because due to continued usage, I know a lot about it <shrug>).
And that (as a professional developer) I'm using other tools and languages as well,
shouldn't surprise anybody.

Note, that in my posts I'm not bad-mouthing .NET in any way - I have no problem
with people using it.

I just have a problem when people are telling me that I'm doing something wrong,
when I prefer to still use the VB6-compiler (and COM-libs) to produce Desktop-Apps
(Desktop-GUIs) for the Windows-platform (even for new projects).

Especially when they recommend to use ".NET instead" (what a narrow view).
There'd be other alternatives to switch to (if I'd care to choose one) - but
I still see no technical reasons to do so "just yet".

Olaf

AppJs, Electron (Atom Shell), and similar schemes get around the severe limitations of fatty, gristly, clunky, ajaxy web pages as rich clients. They do this by embedding the Chromium rendering engine along with Node.js or Io.js into a runtime that bypasses the use of HTTP as the glue between them. This moves the "server" right into the client.

The result is yet another way to write high performance, cross platform, stand alone, desktop applications.

Example: Microsoft leveraged this when they made Visual Studio Code, a cross-platform IDE. See Microsoft Launches Visual Studio Code, A Free Cross-Platform Code Editor For OS X, Linux And Windows if you forgot about this announcement last Spring at Build. Sadly, it isn't a RAD tool for desktop development itself, sticking to "dark world" text-bound technologies (JavaScript, TypeScript, ASP.Net 5, etc.). But that's just the market they chose to target with their first venture.

Of course these schemes suffer from the same problem, yecch, ptui: JavaScript.

Love it or hate it (or put a funny face on top of it using a preprocessor language like TypeScript)... JavaScript engines have gotten pretty fast and it is becoming almost unavoidable.

@dil - what have you ever written in JavaScript?

Plenty. I even taught JavaScript back in the early 20-oughts. We had some of these web secretaries that got hired on and they found that their skills weren't quite up to snuff, so they went to a paid 5-day JavaScript class. When they flunked out I was tasked with getting them up to speed so they could retake the commercial class and pass the second time around.

Sad, sad, people out there playing at web secretarying. Of course hiring managers are often clueeless and hire these no-hopers anyway. Then everyone else has to baby these problem children along year after year after year. Some get good, some eventually get gone.

One went on to another job, claiming the title of "Office Developer" though his job was just as a secretary again. Cobbling together some macros and templates hardly makes you any kind of "developer."

Quote:

---

Classic asp is not a "VB6-backed product" - it's VBScript and JScript (or Perl)-support over
the IIS at the Web-serverside (along with the ability to instantiate all kind of COM-libraries
within that script - also with specific IIS-COM-interfaces handed into the Script-context,
which represent the serverside (usable in your own COM-Dlls even early-bound as Server-,
Session-, Request- and Response-Objects). Serverside-Debugging is available too,
when you delegate back into a running IDE-session of your VB6-Dll-Project.

---

Having worked with Classic Asp no-one will ever convince me that it is a good way to create web applications

Quote:

---

Originally Posted by Schmidt

I just have a problem when people are telling me that I'm doing something wrong,
when I prefer to still use the VB6-compiler (and COM-libs) to produce Desktop-Apps
(Desktop-GUIs) for the Windows-platform (even for new projects).

Especially when they recommend to use ".NET instead" (what a narrow view).
There'd be other alternatives to switch to (if I'd care to choose one) - but
I still see no technical reasons to do so "just yet".

Olaf

---

You have no idea how much I want to thank you about that .

There were moments , I had the feeling that I was alone out there, starting a new project in VB6.

Thanks again.

Quote:

---

Originally Posted by JackB

You have no idea how much I want to thank you about that .

There were moments , I had the feeling that I was alone out there, starting a new project in VB6.

Thanks again.

---

Just because someone else 'out there' does the same as you doesn't mean it's the correct thing to do.

Blacksmithing, or being a farrier, is a worthwhile job - very satisfying - but you aren't going to be making a living doing it, as it's a saturated niche market. People don't buy horses to get from A to B.

If you are in the business of providing solutions to a customer you are doing them a grave disservice by using VB6 to provide said solution.

I don't think using VB6 (either the whole suite or just the compiler) is crazy as long as you've understood the limitations and risks and as long as you own the decision. I'd apply that same criteria of craziness to the use of any language (or any tool, for that matter). It behoves us to do some research around the alternatives, then make a choice and live by it.

I think some of the frustration many people feel toward VB6 fans has nothing to do with the fact that they continue to use VB6 (franky, who cares - if it works for you then more strength to your arm) but rather that many of them don't want to accept the responsibility for making that choice. So many of the campaigns and comments we see around the topic are couched in terms of Microsoft having some moral responsibility to continue development on it. Campaigning for MS to put time and resources into a project which they've repeatedly told you they will not be pursuing and then holding them up as the villain when they continue to remain utterly consistent is really just passive aggression played out large. They've made their position perfectly clear and have been entirely consistent in doing so.

VB6 was an excellent tool for developing DeskTop tools (probably the best IMO). I personally think .Net is better but that's just my opinion. I've deliberately been pushing myself into Web development lately because I do think desk top development is going to become more and more redundant as the capabilities of web technologies increase. I've chosen MVC as the platform for that shift and I'm aware I'm behind the curve but I've always found that there's a nice sweetspot behind the curve where one can continue to be profitable without the discomfort that comes with being right out in front. I progress through technologies but I do so at a fairly slow rate.

I make choices to learn new techs and am happy to live with the consequences of them.

Quote:

---

Originally Posted by SJWhiteley

If you are in the business of providing solutions to a customer you are doing them a grave disservice by using VB6 to provide said solution.

---

This is absolute nonsense. Compared to ANY .net language, it is A LOT lighter, A LOT faster, and A LOT easier to maintain.
It is also powerful enough to use the so called "modern features", if not alone, with the help of thousands of well designed tools available out there, some of them absolutely free.

Quote:

---

Originally Posted by SJWhiteley

If you are in the business of providing solutions to a customer you are doing them a grave disservice by using VB6 to provide said solution.

---

Let me totally disagree with that.

Our clients don’t see our IDEs. They see some things like stability , performance , easiness, consistency. And they are smart enough to notice the lack of errors, crushes , failures , inconveniences, big costs (when they are lucky).

That is the “package” the client is paying for.

I run my own business the last 19 years, having write custom code for more than 100 clients, used more than 20 languages. So far , only in six (6) cases clients asked to be written in a specific language , and they paid for the source code also.

There are cases (and all of us know many examples) that vb6 is not a good option, not even an option for more and more cases nowadays.

The last custom project I got from a NEW client, was a sub system , with a web server and 5-6 (maybe more) clients (that they have to work offline too) , so his stuff could get new orders from his clients.
The client was leaded (by another company) to the solution with windows server , windows tablets that had to be purchased and a new custom app in V*.NET.

I went there just to fix some issues with their internet .Had a chat with the client and he told me the problem and asked my opinion. I answered him the next day , that no new HW had to be purchased (except a second HDD for the server). Just a small app on the existed server , a minimal web page and a small app for the phones . It could be ready for fist tests in 2 weeks and be finished in 4 weeks.

The sub system was ready last June. Client knows nothing about vb6, HTML, CSS, Javascript , PHP, Python Apache. It knows that it works. It knows that his stuff gets his client’s orders and send them to him almost immediately. At the 15% of the cost the others asked for. Don’t mention that they wanted 3 months to deliver the app.

So , go and tell him that I didn’t provide a good service , or I did him a grave disservice.

Do you place any value in the fact that MS has discontinued support? I see a value problem with that.

Quote:

---

Originally Posted by szlamany

Do you place any value in the fact that MS has discontinued support? I see a value problem with that.

---

That might be a problem for who works with VB6 IDE, but not for applications developed with it.
Anyway, even in the case the support for native/COM applications is dropped (what doesn't seem to be the case), VB6 applications still have the option to be run inside W.I.N.E. wherever Linux can be installed, even in these "old" boxes with XP or Win9x.

Quote:

---

Originally Posted by Carlos Rocha

This is absolute nonsense. Compared to ANY .net language, it is A LOT lighter, A LOT faster, and A LOT easier to maintain.
It is also powerful enough to use the so called "modern features", if not alone, with the help of thousands of well designed tools available out there, some of them absolutely free.

---

It is pretty light, but it is not faster. I saw people make that statement a while back and it didn't match my experiences, so I went looking for comparisons. There are a few out there, and they are all simplistic (which is how they would have to be, or else you are really evaluating the implementation, not the language). The results showed .NET to be faster in more cases than they showed VB6 to be faster, but there was some of each. Interestingly, math appears to be considerably faster in .NET than it was in VB6. I find this interesting because math in .NET is not as fast as it could be.

As for maintainability, that has more to do with the developer than the language. VB.NET is OO, VB6 is not. The argument against VB6 would be spaghetti code. The argument against VB.NET (and ANY OO language) would be death by OO. Both are methodologies, and both can be badly abused in a way that makes the resulting code unmaintainable. If you do that, it's your own fault. If you don't do that, then you are doing it right.

There are also lots of tools out there for both platforms, some of them absolutely free. So what? Some of the more useful ones are not absolutely free, and nor is the IDE for VB6.

Quote:

---

Originally Posted by NeedSomeAnswers

Having worked with Classic Asp no-one will ever convince me that it is a good way to create web applications

---

In the discussion further above, we agreed (I thought), that the serverside part
of a Web-Application becomes (much) more light these days, due to more and
more capable js-Frameworks, which do nearly everything already at the clientside
(a lot of functionality pre-encapsulated in js-Classes, which run in the Browser).
So, "comfort whilst developing things in a serverside language" is not that
critical anymore.

The serverside now being reduced to basically "Authentication-, FileSystem- and DB-stuff",
which is easy enough with any of the current serverside environments.

There was a phase, where "pure HTML+CSS" solutions were favoured at the clientside
(js only sparsely used, even frowned upon) - much more things done at the server-end -
whilst "producing the next page, based on the state sent from the previous page".

That approach is not what we find in modern WebApps today.
Modern js-frameworks work with "binding-approaches" (mostly to JSON-Blobs,
which form the Data-Classes in a clientside Model) - and the Views they are
bound to, are also pre-encapsulated (consisting of templates which describe
the used Widgets in such a View - their Properties bearing "static Binding-Infos").

So, a Web-App is not being developed as a "sequence of linked pages" so much anymore,
but mostly coming as a Single-Page-App, which refreshes parts of its "panel-areas"
dynamically, with new (per ajax requested) "View- and Model-Blobs and -Templates".

Modal and non-modal Popup-Dialogues, Grids, Trees, and the whole bunch of other
"templatable Controls" - everything's there and handled dynamically at the
clientside, often not needing a roundtrip over the server, the "dynamics" these
days mostly coming from "reactions of a bound property of a Widget in a View" -
to state-changes in the JSON-Model (a whole lot of those State-Changes not
requiring a roundtrip).

The era, where "HTML-snippets were cobbled together at the server-side dynamically,
depending on state which just came in over http" is over. This kind of state-reflection
is all done at the clientside now, where "HTML-renderers" are part of the Base-Class
in any js-Widget-stack.

So, modern WebApps define themselves over the clientside js-Framework one decides to saddle-on,
and much less over what environment or language might be used at the server-end,
to "massage the JSON" in the incoming ajax-requests.

Olaf

Quote:

---

Originally Posted by szlamany

Do you place any value in the fact that MS has discontinued support? I see a value problem with that.

---

MS does not support my clients. I do support them. If I can’t fulfill their needs , one way or another, someone else will.

MS supposed to support it’s clients. Means us.
But it’s been a long time (about 15 years) , so we have learned to live without their support.

Let me give you a very simplistic example.
vb6 does not support saving *.jpg files. But I bet , all of us support this in our apps. So our clients have to know nohing about this little “secret”.

@Shaggy,

Quote:

---

It is pretty light, but it is not faster. I saw people make that statement a while back and it didn't match my experiences, so I went looking for comparisons. There are a few out there, and they are all simplistic (which is how they would have to be, or else you are really evaluating the implementation, not the language).

---

Well, if you want to compare performance you must use full apps, not only small parts of them. I use .NET controls myself, and the time to load them compared to VB6 are 10 or more times bigger. Once loaded I feel no difference too, but the resources used by .NET controls are incredibly big (memory used and disk access). The load time counts for comparison, too.

IMHO, VB6 is OO. Class Modules, User Controls, Intrinsic Controls, External Components, all are Objects, and you can deal with them as "black boxes", with only properties and methods.
The IDE I use daily is not VB6, but CA-Visual Objects (VO). It's a beautiful OO language developed in early 90s, with inheritance, encapsulation, polymorphism, etc. and in fact I feel no big difference when working with VB6. From VO I can use VB6 objects as they where VO Objects. I can inherit them (sub-classing) and add/change functionality.

VB6 is not OO. It does have some OO features, as you kind of mentioned (though modules are not OO, and don't really exist as such in .NET, since modules in .NET are quietly converted into classes with all shared members...plus some compiler sugar to hide the fact). The term OO used to have a strict definition, but it became "cool", and so it was stuck onto any program or language that had anything it could call an object. In strictest OO, you have nothing but objects (even C++ was not quite clean in this regard, but .NET is).

On the other hand, you mention polymorphism, encapsulation, and inheritance. I didn't remember any of that when I was writing in VB6, so I went looking for it. Here is an interesting link from MS:

https://msdn.microsoft.com/en-us/lib...(v=vs.90).aspx

Note the last line, which states:

Quote:

---

Visual Basic 6.0 does not support implementation inheritance.

---

Here's another one from MS:

https://msdn.microsoft.com/en-us/lib...(v=VS.60).aspx

So, MS disagrees with you about their language, so what are you talking about?

As for speed, you said that VB6 is a lot faster, and now you are saying that you don't see a difference at runtime other than some time taken to load something. I can't say that I have seen any difference in launch speed for programs, either, but then again, not only have I never had an apples to apples comparison of load speeds in any of the programs I have written in both languages, I don't believe I ever saw such a comparison in the links I found. I did go looking for more comparisons, but performance comparisons appear to be harder to find than they were before. The ones I found were not talking about load speed, nor were they even talking about interface in any way, they only talked about algorythm execution speeds.

Having said that, I would expect that load times should be a bit slower than VB6 simply because VB6 is lighter. For example, I have a HEAVY resource-intensive app written in .NET. On my laptop, load times are kind of slow (LOADS of work happens during the launch, so the startup time resembles lots of games you see, though this is not a game). However, on a Surface 2 Pro the launch time is really fast. The systems are comparable as far as RAM, CPU, and so forth, so the difference in speed is probably due to the speed of accessing the solid state drive on the Surface vs the standard HD on the laptop. Performance once loaded is all you could ask for on either one, though.

fwiw

Quote:

---

Object-Oriented

Is JavaScript object-oriented? It has objects which can contain data and methods that act upon that data. Objects can contain other objects. It does not have classes, but it does have constructors which do what classes do, including acting as containers for class variables and methods. It does not have class-oriented inheritance, but it does have prototype-oriented inheritance.

The two main ways of building up object systems are by inheritance (is-a) and by aggregation (has-a). JavaScript does both, but its dynamic nature allows it to excel at aggregation.

Some argue that JavaScript is not truly object oriented because it does not provide information hiding. That is, objects cannot have private variables and private methods: All members are public.

But it turns out that JavaScript objects can have private variables and private methods. (Click here now to find out how.) Of course, few understand this because JavaScript is the world's most misunderstood programming language.

Some argue that JavaScript is not truly object oriented because it does not provide inheritance. But it turns out that JavaScript supports not only classical inheritance, but other code reuse patterns as well.

---

http://www.crockford.com/javascript/javascript.html

btw - I asked about the value related to not having MS support and got a lot of how you all are either dealing with or ignoring that lack of support.

I only asked if you saw value - I should have indicated it was a yes or no question.

Quote:

---

Originally Posted by Shaggy Hiker

... you mention polymorphism, encapsulation, and inheritance. I didn't remember any of that when I was writing in VB6, ...

---

Aside from (implementation-)inheritance, everything of the above is there in VB6.
You were (at the time of switching) just not "up to speed" in VB6 - as so many others here,
who extrapolate the impression of "what they themselves were capable of in VB6, a decade ago",
to the language itself (which they never truly had time to master).

As for OOP (which I don't condemn, only thinking "it's overrated") - below is a citation from:
http://pivotallabs.com/all-evidence-...eing-bullshit/

Quote:

---

Inheritance vs composition

Object-oriented programming is an exceptionally bad idea which could only have originated in California — Edsger W. Dijkstra

Inheritance is one of the primary mechanisms for sharing code in an an OO language. But this idea is so problematic that even the keenest advocates of OO discourage this pattern. Inheritance forces you to define the taxonomy and structure of your application in advance, with all it’s connections and intricacies. This structure is resistant to change which is one of the primary problems software developers face every day. It also fails to model some pretty fundamental concepts.

---

I don't agree fully with all the points he makes, but the article contains quite a list of nice links to this seemingly never ending debate.

Quote:

---

Originally Posted by Shaggy Hiker

... I have a HEAVY resource-intensive app written in .NET. On my laptop, load times are kind of slow ...

---

That's perhaps why Carlos wrote: "...The load time counts for comparison, too..." ;)

Besides, it's my experience as well - e.g. with "SourceTree" (a GitHub-Client for Windows, written in .NET) -
horrible Load-Times - diffing a few dozen changed Files, to finally present a selectable list of the changes
takes sometimes half a minute - not a great "user-experience".

Same thing with the sluggishly behaving "Management Studio for MS-SQLServer" -
the earlier (C++ and COM) versions of that Application behaved a whole lot snappier.
(I guess there's a reason, why they now paddle back to the "native-code-paradigm").

Olaf

Quote:

---

Originally Posted by Schmidt

In the discussion further above, we agreed (I thought), that the serverside part
of a Web-Application becomes (much) more light these days, ...
Olaf

---

I kind of did not agree - I said it was always light.

One of the things a web server backend and a web browser client does is further clarify the client-server nature of where code belongs.

Since I have a robust rich web app there is a ton more info getting pushed from the backend so the JavaScript can better validate locally.

And to further that the robust client side filter can actually "pre-filter" on the server so less data is returned - that's actually a more complicated CRUD layer then I've previously had.

@Shaggy,

VB6 IS Object Oriented because it works with Objects, even if Microsoft says it doesn't. It could be better, tho, but this is the whole point of this thread.
A VB6 Class Module, for example, is the definition of a class that you can use to create objects of that type.
You can still "encapsulate" to some extent, as in

Code:

---

Private _Name as string

Public Property Set Name(ByVal NewName as String)
  _Name = "My name is " & Name & ", but I used to be " & _Name
End Property

Private Sub _DoSomething
  ...
End Sub

Public Sub DoSomething
  ... ' some type of protection
  Call _Dosomething
End Sub

---

Pure OO? what is that? is it even useful? do I need an object to make a simple MyString = "Hello World"?
"Pure" inheritance and "pure" encapsulation in VB6 would be a must, but again, this is the point of this thread.

Quote:

---

Originally Posted by szlamany

Do you place any value in the fact that MS has discontinued support? I see a value problem with that.

---

Well, since you want a short answer - I don't.

Olaf

Quote:

---

Originally Posted by Schmidt

Well, since you want a short answer - I don't.

Olaf

---

Do you think that customers might - if they knew that two vendors had similar reputations - difference being either VB6 or any.Net language internals?

Quote:

---

Originally Posted by szlamany

Do you think that customers might - if they knew that two vendors had similar reputations - difference being either VB6 or any.Net language internals?

---

Customers might have a different opinion - but then - the Apps we offer them are composed
of many C/C++ implemented COMponents - VB6 (for the most part) only being the glue-layer
which binds them in a GUI - compiled it will all end up finally in a native 32Bit-PE-Binary
which contains only resources and x86-instructions.

Also keep in mind, that VB6-Apps will require (beside these C/C++ COMponents),
only the VB6-runtime (which is also a C/C++ implemented Binary) - and a clear
support-statement was made by MS - even for the "last Windows ever - Win10",
that this Runtime is shipped and supported by them also in their latest OS.

So what should my customers worry about exactly?
- that C/C++ compiled COMponents will not work anymore, or ...
- that MS was lying in stating that the VB6-runtime "will just work",
. even in the latest incarnation of the Win-OS?

I don't see at all, what your argumentation is trying to prove or not prove...
Are you just trying to "vindicate a decision you made"? ... As already said,
there's no need to - I'm quite fine with anybody who's not using VB6 -
just don't try to tell me, that I'm doing something wrong in choosing certain
tools which have obvious advantages over others.

Olaf

I'm not trying to vindicate anything - I still have customers using my VB6 apps.

Most of my customers consider the hardware / OS / database and ultimately what client tools they use. What version of Office to support? How long can we live with MS SQL 2005 (not long!). Maybe it's just the enterprise nature of the apps I sell - or the old-school IT departments that run these places.

It's a feather in my cap to offer a non-VB6 solution to my current VB6 clients. Granted part of that is the age-old "you wrote something in Basic?!?!?" that I've lived with for 30 years.

Quote:

---

Originally Posted by Carlos Rocha

@Shaggy,

VB6 IS Object Oriented because it works with Objects, even if Microsoft says it doesn't.

---

MS does NOT say that it doesn't work with objects. I always knew that there were things in VB6 called objects, and wasn't questioning that. I was questioning certain terms, so I went looking for those. It was inheritance that MS said didn't exist in VB6. The second link was to an article discussing how to get around that by implementing a form of inheritance.

Quote:

---

Pure OO? what is that? is it even useful? do I need an object to make a simple MyString = "Hello World"?
"Pure" inheritance and "pure" encapsulation in VB6 would be a must, but again, this is the point of this thread.

---

Pure OO is fairly meaningless. Inheritance and runtime polymorphism has limitted value, and certainly shouldn't be used for something as trivial as a Hello World application. In fact it should be used sparingly, but where it makes sense, then it should be used. In the last 12 years with .NET, and several more in C++, I have found only a handful of places where it was a good idea, but when it was a good idea it was a VERY good idea.

Still, that changes the point. This all came into the discussion because you said it was more maintainable. If it is done right, the amount of OO that VB includes is maintainable, but if done wrong, it's a total mess. There's nothing about the language that makes it more maintainable. OO was largely introduced to try to discourage the bad practices that VB6 (and C, by the way) encouraged. Global variables are easier than encapsulation, so people would reach for them because it was easier, but that would make it less maintainable. That's why I said that the maintenance problem with VB6 was spaghetti code. On the other hand, people can go overboard with OO and try to turn everything into a map of objects with interrelated dependencies. That's why I said that the maintenance problem with .NET was death by OO. I don't think you can have THAT maintenance problem with .NET because VB6 isn't sufficiently OO to allow it. You also can't get the same spaghetti code in .NET because .NET is too OO to allow it. It adheres to the SmallTalk standard (the original language for OO snobs) in that you can't have a variable that is not encapsulated in a class.

http://www.smashcompany.com/technolo...which-must-end

What do you think about this (very long) article?

Quote:

---

Originally Posted by Schmidt

Aside from (implementation-)inheritance, everything of the above is there in VB6.
You were (at the time of switching) just not "up to speed" in VB6 - as so many others here,
who extrapolate the impression of "what they themselves were capable of in VB6, a decade ago",
to the language itself (which they never truly had time to master).

Olaf

---

You can't bring yourself to have a civil discussion can you. What was that? Condescending? Check. Snide? Check. Devoid of information? Check. That was an internet post.

Instead of saying or showing how MS was wrong about those features not being present, you brushed them off with the unsupported first sentence, then spent the rest of the time being snide. What you could have done is explained how runtime polymorphism in VB6 is implemented using interfaces. Polymorphism is implemented, after a fashion, using interfaces. The underlying mechanism is pretty much how it was originally done in C++ back around the time of the original ANSI standardization process. If that was too much, you could have provided a link. Here's a good one:

https://msdn.microsoft.com/en-us/lib...(v=VS.60).aspx

If you disagree with someone, you can certainly choose to be offensive. After all, that's the internet way, but it's not going to change any minds or inform people. In fact, people will tend to discount the rest of what you say regardless of whether or not it has merit.

(Now that I think about it, I do remember encapsulation, because I used it a fair amount, so I shouldn't have included it in the list)

Quote:

---

Originally Posted by Shaggy Hiker

OO was largely introduced to try to discourage the bad practices that VB6 (and C, by the way) encouraged. Global variables are easier than encapsulation, so people would reach for them because it was easier, but that would make it less maintainable. That's why I said that the maintenance problem with VB6 was spaghetti code. On the other hand, people can go overboard with OO and try to turn everything into a map of objects with interrelated dependencies. That's why I said that the maintenance problem with .NET was death by OO. I don't think you can have THAT maintenance problem with .NET because VB6 isn't sufficiently OO to allow it. You also can't get the same spaghetti code in .NET because .NET is too OO to allow it. It adheres to the SmallTalk standard (the original language for OO snobs) in that you can't have a variable that is not encapsulated in a class.

---

All of the above is really confusing...

1) We *don't* need inheritance in VB6, to create really deep Object-Hierarchies, with dozens of
Class-Types and Interfaces which cross-reference each other...

So one can create the same unmaintainable "Object-spaghetti" which you claimed was only
possible in .NET.

2) You have static Classes in .NET (which are basically the same as VB6-Modules) - and
you can define Value-Type-Variables globally, as well as global Arrays etc. - and you can
write "plain globally reachable procedures" if you want to.

So one can create the same "procedural spaghetti" also in .NET.

As for C - this language is quite flexible - and you can surely define Class-like Structs
(which contain Methods) - and treat these like Objects in your Code.

There's C-Frameworks like glib for example which support working Class-based in C
(including refcounting, pretty much like in COM) - or sometimes even simple *.h-Files
might suffice, containing Makro-Definitions which rely on the C-Preprocessor, which support a
C-Developer to work with such light-weight Object- or ClassStruct-Support more conveniently.

So basically the same things which are possible with VB6, are also possible with C -
and are also possible with .NET.

We can make a mess with our Obects and Classes - and we can make a mess out of procedural Code.

And of course the opposite is also true.
I've seen well-written, well-maintainable C-Code (e.g. in the SQLite-CodeBase) - and I've seen really bad one.
I've seen well-written procedural Code in VB6 - and well-written Class- and ObjectCode there too
And the same goes for .NET of course.

For all of them holds true, that you need to understand your tool well - learn about proper structuring
and encapsulation for the procedural-, as well as the OOish paradigm ... and which one to apply when...
Learn about interfaces and good API-design for the Binaries and Helper-libs you create (for) yourself.

But that's nothing inherent in a given tool - that simply depends on ones progress on a learning-curve
(and an existing interest to indeed climb it at all).

Olaf

Quote:

---

Originally Posted by MikiSoft

http://www.smashcompany.com/technolo...which-must-end

What do you think about this (very long) article?

---

I think it's typical. Pretty much everybody has opinions, and he's one of them, he just used more words to convey it. Parts were bizarre or arguably wrong, but since the thing is so utterly massive it's hard to say anything about it as a whole. Any criticism of just a part would be dismissed as nitpicking, while any criticism of the whole would take too long for anybody other than a diehard fanatic to bother with. In the end, though, he goes at length into how many vague and fluid the definitions of OO are, and the fact that there are other languages that implement all those features (but for some reason are not considered OO, and thus are not tarred with the same brush), yet he states definitively that OO must die. Well....if it's so fluid, and all the features are found in the languages he likes, what is it that he is saying must die?

Frankly, it all seems like a continuum of opinions, to me, and he's just one on the spectrum. Off to one end, to be sure, but it isn't a dichotomy, just a continuum, so there's a range with no obvious mode. In such a situation, it's as Shakespeare described: All sound and fury, signifying nothing.

One point he made quite corrrectly: Nobody has ever come up with a silver bullet. OO was supposed to cure something so people saw it as a silver bullet. It wasn't, nor was anything else. No practice, language, or individual guarantees the success of a project, but everybody is still seeking such a guarantee.

Quote:

---

Originally Posted by Shaggy Hiker

You can't bring yourself to have a civil discussion can you.

---

Shaggy, that was not condescending - it was (judging from what you wrote earlier, and
also from what I replied to just now) the simple truth (in my opinion of course).

Do you have any clue, how it feels to be forced to *constantly* clean up behind all
those half-informed opinions about VB6?

From my point of view - it's the VB6-users who deserve an apology for condescending
behaviour from your end (throwing out one wrong statement after another).

Let's make a simple test of logic here:

If you *know* that inheritance is "frowned upon" even in languages which support it,
and when that thing is the only one which is missing in VB6 - why on earth do you
ride around on that argument at all?

Why do you claim, that VB6 is "more prone to produce spaghetti-code", when
inheritance (as the only thing missing) is "barely or not used" in .NET?

How can a barely or not used thing be responsible for the (allegedly) better maintainable
code-base one can write in "full OO-languages"?

Olaf

In the end, imo, any of the pointed possible OO approaches should only be "facilities", leaving to the developer the option to use them or not.
In my loved VO, objects/classes can live together with procedural code. In fact, the base class of any hierarchy is always build using procedural code, and sometimes it's "cheaper" to use a global function than a method.

Quote:

---

If you *know* that inheritance is "frowned upon" even in languages which support it,
and when that thing is the only one which is missing in VB6 - why on earth do you
ride around on that argument at all?

---

Inheritance is not frowned upon by anyone that actually understands the Inheritance vs Composition debate. Composition provides greater flexibility and more maintainability in highly complex inheritance structures where objects require different combinations of behaviours for different functions. However, inheritance can provide better enforcement of behaviours and simpler code in a reasonably simple inheritance structure. An inherited structure can also be reasonably easily re-engineered into a composition structure if the structure starts to become more complex.

The "favour composition" principle comes from the fact that an application is more likely to become more complex over time than it is to become more simple over time. Favouring composition means that you're addressing that potential complexity early, which is good, but is also a potential violation of the YAGNI principle. If your developing for behaviours that you're probably going to add to over time then composition is a better choice. But if you're reasonably confident that the set of behaviours is going to remain largely static and simple then inheritance provides a better solution. Like most everything else, you should pick the right tool for the right job.

It should be noted that "inheritance" in terms of the inheritance vs composition debate refers to implementation inheritance, not interface inheritance. Interface inheritance really falls under composition in this debate (or more accurately, it refers to a technique required to implement composition). As such the lack on implementation inheritance in VB6 is a weakness. It's not a particularly big weakness (and I do think Shaggy may be overstating it a bit) as composition can fill the gap but, none the less, implementation inheritance would have provide a better solution in alot of scenarios.

For me the non-OOness of VB6 can't really be nailed to a single, killer weakness. Rather it's a bunch of small weakness, each of which can be worked around if you want to. No implementation inheritance, no parametised constructors and so on. I certainly wouldn't leap from there to saying that VB6 is a bad language but it is, like any other, an imperfect one.



edit> I'm trying to remember whether VB6 provided method polymorphism. I.e. allowing two methods to have the same name but different parameter signiatures. I think it didn't but it's been a long time and I might be confusing it with another language I used to work in called KCML (a proprietary language that was designed to be like VB but missed out alot of useful stuff)