What if there was a NEW vb6

[NeedSomeAnswers]

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

This is one hell of a long thread now so while i cant remember the post but i do agree.

So, "comfort whilst developing things in a serverside language" is not that
critical anymore.

I disagree, when i develop web apps the whole stack of technology i am using matters to me

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,

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.

I have paraphrased you above just to make what you were saying clearer Olaf, as while you obviously have lost of knowledge you do sometimes go into more detail then i think is needed imho

Again i don't disagree with what your saying here but regardless of that for me Classic ASP is a different product to VB6 and an Inferior one.

VB6 does what it does well, or at least it can do if in the right hands

Classic ASP was designed when the Web was a different place and imho as a tool is far outstripped by ASP.Net and many other web languages like PHP, ColdFusion, Python, even for the backend stuff of web apps.

VB Script is just not great to use in the Web and if you are just going to solely use JavaScript then why use it at all?

I Personally use a mix of ASP.Net ( c#), JavaScript, JQuery and Json, HTML5 and CSS3 for my web apps and as a technology set they all work really nicely together

[Schmidt]

... when i develop web apps the whole stack of technology i am using matters to me
...
... for me Classic ASP is a different product to VB6 and an Inferior one.

See, that is exactly the kind of "uninformed comparative-statement", many experienced
VB6-Users (or for that matter, "classic-asp developers") will take offense with...

You said, that you have "worked with *.asp - and that you found it lacking"...

I have a few problems with that, because I've worked (and still am working) with it, too -
and do not find it lacking anything.

And when I now will point out, that this discrepancy in perception, is perhaps due
to a difference in the "level of understanding the technology" (because you perhaps
switched to something different - too early in your career) - will you now blame me
for my "condescending attitude", or will you accept my replies with a bit more grace?
(since I've worked with the tool in question more intensively - over more than a decade now).

For example, the line below will be all you will ever need to place in a serverside *.asp-Script,
with regards to "working with the technology at the Scripting-Level":

<%CreateObject("ComLib.SomeClass").Handle Application, Server, Session, Request, Response, Error%>

You will not need to touch or upload any other *.asp File ever again for the serverside part of your
Web-Application - all the rest can be handled in the "COM-Universe", the above line delegates to.

This means, that the serverside handling of requests, becomes fully and conveniently debuggable -
e.g. in the VB6-IDE which then supports Edit&Continue along with Intellisense for your serverside Code
(which will later be compiled into a native Dll, which gets placed at the serverside).

So, if you really would have been already aware of that, whilst "working with asp", your above
statements would have never been written.

Things like the above happen with a disturbingly high frequency in this thread...

So, what about "not posting blanket statements about certain topics, in areas where your
knowledge might have gotten a bit rusty over time"?

In my opinion this is not an impolite plea I make - on the other hand I'd consider it
polite behaviour when such "judging statements" would either be omitted completely
in a public Forum - or at least be enhanced about a qualifier as e.g.

"It's a long time since I worked with classic-asp - and I used it only for a short time,
so YMMV - but..."

I Personally use a mix of ASP.Net ( c#), JavaScript, JQuery and Json, HTML5 and CSS3
for my web apps and as a technology set they all work really nicely together

And as the above list shows, the block of: "JavaScript, JQuery and Json, HTML5 and CSS3"
is the largest one - all being MS-independent technologies.
(and you were not specifying the concretely used js-GUI-Framework, which is a critical part
these days, which determines "the way everything else will interact in the end".

There's dozens of those js-GUI-frameworks one can choose from - each one coming with
a slightly different philosophy one has to get familiar with first, to be able to work efficiently.

Olaf

[Schmidt]

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, ...

Thanks for acknowledging at least, that VB6 (which fully supports composition) is:
- "addressing potential complexity early, which is good" ... especailly since ...
- "an application is more likely to become more complex over time"
Thereby favouring the pattern, which makes especially the large and complex Apps
better maintainable for the developer.


And as for your "VB6 not supporting parameterised constructors"...

That's true (at Class-Level) - but implementation-wise not really requiring more coding-efforts,
since there's Factory-patterns which are commonly considered a good thing to use -
and which would then allow to construct new instances (with a Parameter-Set) quite nicely.

I'm trying to remember whether VB6 provided method polymorphism.
I.e. allowing two methods to have the same name but different parameter signiatures.

It doesn't allow that, but there's other things which can be used instead,
to make a certain method behave more flexible...
I've always found:
- Optional Params with Default-Values,
- ParamArrays, which make a Method "open at the end"
- and ByRef Variant-Parameters
entirely sufficient to implement even complex Interfaces.

And of course there is (listed under caveats in: https://en.wikipedia.org/wiki/Function_overloading):

If a method is designed with an excessive number of overloads, it may be difficult for developers to discern which overload is being called simply by reading the code...

So, why not give the darn things dedicated and proper names in the first place?
as e.g. in a Drawing-Class:
- SetClipByCoords(x1, y1, x2, y2)
- SetClipByRect(Rct As Rect)

Due to the same MethodName-Prefixing, an Intellisense-Dropdown will list these two
entries below each other - no studying of the Method-Parameter-List will be necessary,
to choose the right one for the given input-case.

Olaf

[Gruff]

I'm trying to remember whether VB6 provided method polymorphism. I.e. allowing two methods to have the same name but different parameter signiatures.

As far as I know VB6 does not support polymorphism as you describe it.
It does have optional parameters and parameter arrays which with some thought can allow you to create a single method that can serve multiple purposes.

The method code can get very complex depending on what you are trying to achieve.

For this simple reason I typically prefer the polymorphic approach

Note that in addition to polymorphism VB.NET still has those features.

edit>
Olaf: You bring up a good point about using dedicated procedure names in VB6, however that does flatten out and increase the number of procedure names to remember.

[FunkyDexter]

Olaf, you're entire post serves to demonstrate exactly what I said:-
"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"

Ultimately, just about any language can be used to achieve just about any goal. The measure of the quality of a language is how easily it allows you to do so.

[Schmidt]

Olaf: You bring up a good point about using dedicated procedure names in VB6, however that does flatten out and increase the number of procedure names to remember.

I take it, that our two postings overlapped a bit - but note that I also mentioned
(in addition to Optional Params and ParamArrays) a third mechanism -> the ByRef Variants,
which are quite fast performing (only handing Pointers to the original Values over into the callee -
not copying any Data) - and which are not available in .NET.

As for "flattening out" (when using dedicated Method-Naming)... and then "not being able to remember"...
That's what I thought Intellisense was for - you only need to remember the first few Chars
of such a "function-set" whilst beginning to type (as e.g. 'SetClip...') - and you're there -
all fitting into the Space of the Intellisense-DropDown-list (even if there'd be more than 2 of them).

Besides (having implemented quite a bunch of Classes and Interfaces in COM-libraries) - I never
had a case, where *more* than 2 or 3 Methods with the same Prefix were needed - and those cases
where 2 or 3 Methods with the same Prefix exist in a Class, are extremely rare (due to the already
mentioned "other flexibility-mechanisms" which can be applied in VB6).

I think that this is one of those points, you "feel are needed" (because of the strict typing .NET requires,
the "everything is an Object"-paradigm, as well as the very deep Hierarchy of the .NET Class-Library) -
then often forgetting about the other mechanisms which are available as an alternative in different environments.

Olaf

[Gruff]

I've Forgotten nothing.
I've used all the features you described in vb6 for over a decade.
I still use them sometimes in VB.NET. It is not a matter of "feeling".
I know I am more organized with the newer tools.

If you can work without them then good for you.

[Sitten Spynne]

This kind of argument makes me sad. I cut my teeth on VB .NET back in 2003 and I've had my share of arguments over VB6. I've hurt people's feelings and called them dinosaurs. Here's what I think 12 years later.

I feel like VB is a perfectly good language in all flavors. So VB6 isn't as object-oriented as VB .NET. That only means you use different patterns when designing your architecture. Clean code looks similar in all languages, and follows similar practices. That we're still bickering over this some 10 years later is what the "problem" with VB is to me: the community.

VB attracted a ton of novices, because it was a heck of a lot easier to pick up than C. Novices don't write good code. They don't know better. Bad code in C tends to fail spectacularly. Bad code in VB limps along, creating a fascinating maintenance project for someone later. This is a good thing, though! Accessible languages mean more people get their problems solved. The novices are the problem, but they don't know better. How do we elevate them to write better code?

In every other community, the answer is "Train them as early as possible." Ruby and Python advocate writing isolated classes, short functions, and lots of tests from the start. JavaScript gurus point to a book detailing the worst pitfalls and how to never fall in them. C# generated so much software engineering discussion it replaced Java as the de facto example language.

In 10 years of participating in programming forums, the VB community is the only one that's attacked me for suggesting refactorings along with solutions. I've tried explaining fundamental concepts to people struggling with a mess of ugly event handling logic, only to have someone swoop in with "Just add Application.DoEvents() until it works". The community doesn't come back in and point out that's a band-aid, it's the accepted answer. Suggest a person move some logic into a separate class so its tricky edge cases can be tested and even the forum experts treat you as if you've got a contagious skin disease. It's not fun feeling like the things that I'd be mocked for avoiding anywhere else are what make me seem foolish here.

To me that is the VB stigma. The community supports the notion that software architecture is a topic that is complex and best approached when one feels some undefined level of project complexity is reached. The reality of software development is most architecture represents good habits that must be learned and practiced as soon as possible, because once a project is "complex" it's far too late to think of how it should be organized. VB forums and articles usually focus on a cookbook style, making no assumptions about project architectures and favoring brief, minimum-line solutions. This alone is not a bad thing, it cuts cruft from examples. But many newbies in other languages are taught that what VB developers see as "architectural cruft" is "the thing that keeps my project organized." I can't help but feel like this makes far too many "expert beginners" who go on to train other VB developers to reach some imagined ceiling and stop aspiring to go further.

So what probably started as FUD created by C developers worried for their jobs has turned into the VB community presenting itself as exactly the FUD those developers spread. The only joke here is that C has become far more irrelevant than VB in terms of modern client design. I wish I saw more community effort to elevate all VB developers to aspire to be more than just a "hobbyist", and focus on good decisions more than whether a solution is fast and appears functional.

I'm tired of the VB6 vs. .NET discussion, especially the side that implies all VB6 code written everywhere is bad. A lot of times I feel like it comes down to "because VB6 is older than me". C is probably older than you, and you're never going to write anything as good as what Carmack did for DOOM. There's fewer flaws in the space shuttle's code after decades of service than you probably write in a day. If you think the language has more to do with clean code than the developer, I'm going to wager you wouldn't survive one of my code reviews.

I want to see VB developers arguing over ideas like test-first design. I want to see rowdy arguments over which IoC containers play best with which unit test frameworks. I want to see near fistfights over time-honored debates like composition vs. inheritance. This is like seeing two champion martial artists go at it and everyone can learn from watching their techniques. It isn't funny that on the VB end the fights are about whether calling CreateGraphics() in a Paint event handler is "good enough", that's an issue that was settled before .NET released. In the real fight analogy, this is paying two street beggars to whack each other with wiffle bats until one passes out. The people who pay the highest price are the ones that think they found easy money.

On topic...

I don't think we need a new VB because I think we already have several contenders that aren't being considered because they don't have the VB syntax. People seem to pick up Python and Ruby and C# and do amazing things in very short amounts of time. Apple's Swift is looking really nice in its 2.0 form, and may be the VB version of Objective C. I don't really think the syntax was what made VB so inviting, I feel like it was concepts like abstraction of pointers and its pseudo-OO environment. Something that performs those abstractions /while/ nudging the programmer towards good architectural decisions would be the ideal new VB. While I'm making my list to Santa, it should run equally well on iOS/Android/Windows/Mac because we have to face that today's world is a multiplatform world, though some will argue the web might eat native clients. I'm still a little skeptical of that. But I keep being dang wrong.

[szlamany]

Really well said!

[Schmidt]

Olaf, you're entire post serves to demonstrate exactly what I said:-
"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"

Well, since "overboarding OOness" can be considered a weakness as well,
I'd prefer the following, more generic statement instead:
"Any language has small weaknesses, depending on the context and scenario it is used in -
most of them easy to workaround, some of them requiring another tool though".

Ultimately, just about any language can be used to achieve just about any goal.
The measure of the quality of a language is how easily it allows you to do so.

And in this regard, I consider VB6 as entirely up to the competition, when it comes
to Desktop-Apps for the Windows-Platform.

And before anybody feels the need to disagree with me (because he remembers
how he struggled with certain things in VB6, as a Programming-Novice (1 or 2
decades ago) - why don't we simply try our best, to achieve a certain concrete goal -
and later compare notes?

For example I have a nice idea for the next Contest in the appropriate Forum ...
dday9, are you listening?
This time getting a bit "more serious" (whilst still remaining in the "doable in a smaller amount of time"-realm).

Why not try to cover most of the points which make up an (e.g. LAN-wide used) multiuser-capable Application?
(more targetting, what most people do in their daily work with VB -> MultiUser-LOB-Apps)...

Here a sketchup for the idea of a "Bible-Search-Service" - available to a lot of LAN-Clients:

Requirements for the ServerPart:
S1. ReadOnly access to the FileSystem (Service works completely InMemory, no Temp-Files allowed)
S2. Read in an about 5MB-File, which contains the Bible-Text (which is structured in a Books>Chapters>Verses-Hierarchy)
S3. Do whatever you want with that Text-Content to prepare it for fast Google-like Searches, but keep it in Memory

S3.1. Since Verses are the final Level which define a Paragraph, the found results matching a given SearchString:
S3.1.1. should be returned as a "Verse-Snippet" that contains the matching Word(part), along with VerseNr, ChapterNr, BookNr
S3.1.2. the Request should contain a Parameter which (optionally) limits the amount of the found and returned Verse-Infos

S4. ensure concurrent access for multiple Clients (over Sockets)
S5. to ease install-requirements, a "true Windows-Service" is not needed - a simple BibleServer.exe sufficient
S6. to perform the final tests on a single machine, the Server should listen on the loopback (127.0.0.1)

The Bible-Text-File in question would be the free downloadable "King James Version"
from Project Gutenberg -> Bible12.txt, available also as a Zip in the following Folder:
http://www.gutenberg.org/files/30/old/

So, this Serverpart should allow .NETers to make good use of e.g. WCF, LINQ and Threading...
For fast Word-Searches (in case you want to use alternatives to LINQ) you might consider also:
Lucene.NET: https://lucenenet.apache.org/
hOOt: http://www.codeproject.com/Articles/...-search-engine
SQLite: https://www.sqlite.org/fts3.html

Requirements for the ClientPart:
C1. Provide a GUI over two relative simple Dialogue-Forms:

C1.1. a Main-Form to enter search-strings freely (over a TextBox) and:
C1.1.1. live-updates a List- or Grid-Control with the found Verse-Snippets which match the SearchString
C1.1.1.1. each List-Entry shall contain Renderings for:
C1.1.1.1.1. a nice Icon - and to the right of the Icon, two Text-Lines, one of them rendered as a Caption with:
C1.1.1.1.2. BookNr, BookName, ChapterNr, VerseNr in a first line of text (in bold) ... and below that in a second line
C1.1.1.1.3. the found "surrounding snippet" in a single line of text, with the matching words colored
... e.g. one of the results for "Noah": [...of Noah: Noah was a just man and perfect in his generations, and Noah walked...]
C1.1.2. a List-Click on a Verse-Snippet-Entry will update a larger, second TextBox below, which shows the full Verse-Text
C1.1.3. above this second "Full-Verse-TextBox" should be a Label, which shows: BookNr, BookName, ChapterNr, VerseNr
C1.1.4. beside this Label should be a Control, which allows to scroll Verses up and down, relative from the current Verse

C1.2. a Performance-Test-Form that starts up as a "Tool-Window", aTop and along with the Main-Form and which:
C1.2.1. offers 8 CheckBoxes to switch on/off clientside WorkerThreads which stress the Server with Requests in an endless loop
C1.2.2. each CheckBox reports the currently achieved Requests/sec from its WorkerThread in its Caption, along with 4 Results:
C1.2.2.1. these 4 Result-Values are the found match-counts for 4 different SearchStrings:
C1.2.2.1.1. [noah] (should come out with a match-count of 46)
C1.2.2.1.2. [(noah god) OR (noah -god)] with the exact same count as above (46) since: noah = (noah AND god) OR (noah AND NOT god)
C1.2.2.1.3. [noah ark] a simple AND combination which should come out with a match-count of 12
C1.2.2.1.4. ["let us do evil"] ... a quoted phrase, which is searched as a whole (coming out with Count 1)
C1.2.2.2. each thread has to perform these 4 different search-requests in separate roundtrips over the serverside (no bundling)
C1.2.2.3. since the 4 strings remain constant in this stress-test, no caching is allowed at the server (to measure true performance)
C1.2.3. the total results for Requests/sec each "Thread-CheckBox" reports, shall be sumed up and reported in the Forms Caption

C2. Connect directly over the loopback-interface to the Server at App-Startup - no Login-Screen needed, "free Scripture for all"


So, the Client-Part contains a little "GUI-challenge" (with the Text-Formatting-requirements in the List-Entries) -
it contains Threading-requirements for the Stress-Test-Form (all stuff which normally favours the .NET environment)-
and if that's still too simple to "mimick" a typical GUI-scenario in a LOB-App, we could optionally include also
an Undo/Redo-scenario (to allow back/forward-navigation over already typed Search-Strings and their Results) -
but that only, when the GUI-part would need some more "weight" in your opinion...

Wouldn't that be a nice challenge (since it not really favours any "special features" of VB6 -
it's IMO more the other way around)...
Just testing the waters here for a Contest which addresses more the "LOBster-professionals"
than the "Gamers" or "Math-artists" (as was mostly the case in the last contests).

Looking at the results would certainly help to point participants of these always re-occuring
discussions about "which language is more efficient", to something with a bit "more beef in it".

Olaf

[Tanner_H]

This kind of argument makes me sad. I cut my teeth on VB .NET back in 2003 and I've had my share of arguments over VB6. I've hurt people's feelings and called them dinosaurs. Here's what I think 12 years later.

...lots of awesome stuff...

Bravo. This is a fantastic post.

[Schmidt]

...Clean code looks similar in all languages, and follows similar practices.
That we're still bickering over this some 10 years later is what the "problem" with VB is to me: the community.

"Truer words were never spoken" - and all that...

This is a good thing, though! Accessible languages mean more people get their problems solved.
The novices are the problem, but they don't know better. How do we elevate them to write better code?

You mean, other than pulling your hair out?

Not sure, how "active" you were inside the VB-community to accomplish just that...
From my point of view the results are surely not what one likes them to be - but other than:
"keep trying", there's not much one can do (all in hope that some stuff "keeps sticking").

The problem is IMO not really solvable - because a high(er) "learning-curve-climbing-speed"
will be seen only, when the Novices do their programming "all day long" (8 hours per day) -
though that's not a given because (most) of the remaining VB-Community-Members are
Hobbyists with a completely different day-to-day-job - or self-taught + self-employed.

Members of that latter group sometimes *do* program all day long, so that's at least
something to saddle on - but many of them never really learned the "general basics"
(having studied entirely different things at a younger age, which had nothing to do with
software-development, algorithms, patterns, general design and testing).

The "VB-pyramid" (with regards to "achieved learning-curve-altitudes") is overproportionally
broad at the base - with a decent middle - and an very narrow Top.

That "pyramid" is much more "linear at the edges" with communities around different
languages, which have a higher "entry-hurdle".

The overall-impression in News-Forums for VB a 10-15 years ago, was somewhat better,
because - albeit the pyramid had roughly the same shape - the amount of "Top-Coders"
was (in absolute numbers) much higher, and thus the number of postings in a good quality
at top-level was too (there were more C++ guys, who used VC6 for the "heavy lifting" -
and VB6 to glue it all together in a GUI).

Olaf

[szlamany]

I assumed that lots of the VB6 crowd was self taught - hasn't that been a point in these past few posts?

Was VB6 taught in colleges 20 years ago?

[Schmidt]

I assumed that lots of the VB6 crowd was self taught - hasn't that been a point in these past few posts?

In case you replied to my previous post - I didn't state anything to the contrary.

Was VB6 taught in colleges 20 years ago?

Don't know - at the Uni where I was studying 'Electronics', we had C
(in the Classes which focused on MicroController-Programming) -
and Pascal (in Classes which focused on "general informatics").

Just a few years later, they switched the "general language" from Pascal to Java.

When I wrote in my previous post:

...many of them [referring to the self-taught VB-Users] never really learned
the "general basics" [of software-enineering or more commonly: 'informatics']
(having studied entirely different things at a younger age, which had nothing to do with
software-development, algorithms, patterns, general design and testing).

...it wasn't meant "deprecative" or something - just an attempt to explain, why
the VB-community "is what it is" - and why it's sometimes difficult to explain
something, when those "4-5 years of stress with the basic-stuff" were missing
from somebodies base-education (which often has been an entirely different one).

Developers in the C/C++, Java, <put most non-VB-languages here>-Camp *do*
have that specialized background in a much higher percentage, to build upon.

Olaf

[JackB]

So lets talk about C or FORTRAN.

[Schmidt]

So lets talk about C or FORTRAN.

What's the context your statement refers to... (citation)?

The thread is currently at a point, where Sytten Spinne raised the question:
The novices are the problem, but they don't know better. How do we elevate them to write better code?

Followed by:
In every other community, the answer is "Train them as early as possible." Ruby and Python advocate writing isolated classes, short functions,...

And in my replies to that, I tried to point out, that I think this is asking the impossible - because
"VB-Novices" in most cases do *not* come in the "get them young - and train them early"-category,
there is (or better was) a lot of "lateral movement" to the language (in most cases by people who already
"work(ed) for a living in different areas", many of them getting their feet wet with Makros in VBA, to
automate their daily task - some of them with a hang for it then stepping over to VB-Classic or VB.NET -
in that age then mostly "stable enough" to bear with the ridiculing of the VB-language from different camps.

There's the occasional teenager shining up, who's asking how to write this or that, usually in the
context of simpler game-scenarios. Even if all of them decide to follow through with a career
in software-development, they will be convinced quite fast IMO when they become twens
(either by their teachers, or by their fellow-students), that VB is "totally uncool - and soo last week".

How to remedy that perception (making VB more "cool") would be one of the most important things
to puzzle out first, to *keep* "young ones" attracted to the language (when they start their
studies in earnest).

VB once was considered kind of cool, because of its RAD-concept (as already said, swaying
even C++ coders in the early age of "gold-digging", where timing was important to get your
own Windows-App out fast, in the 90ies).

That it is not cool anymore is due to the fact that MS has "officially abandoned it" - but also
because nearly any possible ShareWare-App for the Desktop is "already there" (usually "for free"
in the meantime, no "gold-digging-climate" for Win-Desktop-Apps anymore - remaining niches
to still "land a ShareWare-Hit" are tough to find - especially for NewComers).

Then there's the new Mobile- and Web-Apps trend which especially the young ones flock to -
and VB doesn't play any role in this sector.

To increase the attractivity of the language (at least on the Desktop) I'm with Tanner,
who mentioned a few months ago, that the VB-community has to learn to work together,
to learn how to use GitHub or BitBucket,to learn how to apply the right OpenSource-licenses
to attractive Applications who deserve a "well-done" from other participants in the OpenSource-
Universe.

But that means, that classic Desktop-Apps will live to see a "renaissance" somehow -
or that a new VB-compiler will see the light of day, which aims at a broader spectrum
of target-platforms.

Olaf

[Niya]

I think the probl........ummm.......never mind......

Ran out of things to say. Maybe someone can tell me where the little boy's room is. Anyone ?

[JackB]

What's the context your statement refers to... (citation)?

To all of them that , with their tireless efforts and objective criticism , helped me realize the truth. How bad vb6 is. That helped me realise that I’m a short of an unreliable scum , using a such bad tool, providing bad services to my customers.

Considering that
1. is unsupported
2. was not taught to universities 2-3 years before its release
3. NASA can’t use it to fully program the next trip
4. vb6 users use it because (OBVIOUSLY) they are “low level” in mind, unable to use anything else
, makes me feel guilty already!

I want to change. I want to be a better person. Using only tools that I’ve been taught at university, as a first step. So it comes C and FORTRAN (for me).

[Tanner_H]

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

Sorry to bounce backward in the thread a bit, but I thought this was an interesting question. For any platform other than Windows I would say, "yes, absolutely it's a value problem," but IMO desktop Windows is the exception to this.

One of my biggest frustrations in developing for Windows is that Microsoft deprecates APIs in a totally haphazard fashion. It's not just a VB6 problem, either. It affects their whole development stack.

Easy example: GDI+ was deprecated after Vista released. But the entire System.Drawing namespace relies on it. Instead of fixing System.Drawing, Microsoft haphazardly releases parallel implementations (e.g. Graphics.DrawString vs TextRenderer.DrawText), which seem similar but are actually completely different under the hood. Of course, many parts of System.Drawing don't have "non-deprecated" replacements, so you have no choice but to stick with GDI+ despite its current state.

So deprecated support (which would be the correct term IMO, since VB6 does have an active support statement from Microsoft) is one of those things you just have to live with when developing for Windows, because Microsoft can't make up its mind about what support to continue and what support to drop, even in .NET. Trying to avoid things that are deprecated or even discontinued just isn't practical, unless you use a toolchain completely separate from .NET (e.g. "pure" C++ and as few direct WAPI interactions as possible).

[szlamany]

Sorry to bounce backward in the thread a bit, but I thought this was an interesting question. For any platform other than Windows I would say, "yes, absolutely it's a value problem," but IMO desktop Windows is the exception to this.

One of my biggest frustrations in developing for Windows is that Microsoft deprecates APIs in a totally haphazard fashion. It's not just a VB6 problem, either. It affects their whole development stack.

Easy example: GDI+ was deprecated after Vista released. But the entire System.Drawing namespace relies on it. Instead of fixing System.Drawing, Microsoft haphazardly releases parallel implementations (e.g. Graphics.DrawString vs TextRenderer.DrawText), which seem similar but are actually completely different under the hood. Of course, many parts of System.Drawing don't have "non-deprecated" replacements, so you have no choice but to stick with GDI+ despite its current state.

So deprecated support (which would be the correct term IMO, since VB6 does have an active support statement from Microsoft) is one of those things you just have to live with when developing for Windows, because Microsoft can't make up its mind about what support to continue and what support to drop, even in .NET. Trying to avoid things that are deprecated or even discontinued just isn't practical, unless you use a toolchain completely separate from .NET (e.g. "pure" C++ and as few direct WAPI interactions as possible).

I totally agree with you!

I've had apps on PocketPc's that took months to develop that simply went away. I've done VB6 Winforms, VB.NET Winforms, ASP.Net Webforms - even have a prototype app in WPF!

At least I wrote the WPF one in C# - trying to shed the BASIC target I wear on my back!

But seriously you are dead right on the shifting sands that abound here.

My customers are large-server-network'd 100's if not 1000+ users. When I started migrating them from their mini-computers to server/PC's back in late 1990's I felt that .Net was too new and instead chose VB6.

I'm not sure what would make me go back to VB6 now (to be on point to the thread)

At any rate - this is all part of why I'm recently browser-front-end - although still VB.Net backend - I like BASIC, see no reason to get into some PHP stack I know nothing about - the .Net framework is so powerful.

VB attracted a ton of novices, because it was a heck of a lot easier to pick up than C. Novices don't write good code. They don't know better. Bad code in C tends to fail spectacularly. Bad code in VB limps along, creating a fascinating maintenance project for someone later. This is a good thing, though! Accessible languages mean more people get their problems solved. The novices are the problem, but they don't know better. How do we elevate them to write better code?

Other industries have certifications - the programming world fights back at that. I would say that only 30% of the coders I've had in my shop were really worth it - 30% totally useless and the middle were just that - the middle.

it should run equally well on iOS/Android/Windows/Mac because we have to face that today's world is a multiplatform world, though some will argue the web might eat native clients. I'm still a little skeptical of that. But I keep being dang wrong.

Last time I evaluated using a browser on a 7 inch android tablet I ended up coding a native client tool - had to learn a whole new Java-like world (can only compare strings with a "ASDF".equalsIgnoreCase("omg") method?).

[Schmidt]

To all of them that , with their tireless efforts and objective criticism , helped me realize the truth. How bad vb6 is. That helped me realise that I’m a short of an unreliable scum , using a such bad tool, providing bad services to my customers.

Then you completely misunderstood what was said above -
and cynicism will surely not help.

Considering that
1. is unsupported

But the runtime *is* supported - I thought I already mentioned that ...
Tanner now even gave a proper link: https://msdn.microsoft.com/en-us/vstudio/ms788708

2. was not taught to universities 2-3 years before its release

You completely misunderstood once again.
Sitten Spynne complained (basically) about a "lack of scientific background"
when discussing software-design-topics in the VB-community.

And no, it doesn't matter at all, what language was the "educational base-language"
for people who studied informatics at the university - it's the "general background" that's
important - no matter what kind of "working language" these guys will choose in the end.

The problem lies in the fact, that of those "guys with a background in computer-sciences"
only a very minor part ends up in the VB-camp - most of them go elsewhere.

3. NASA can’t use it to fully program the next trip

If it's any consolation... a few VB6-components apparently made it to the Space-Shuttle -
others were used in Simulations and SubSonic-Testing for the Shuttle.
(from an old discussion in the m.p.v.g.d NewsGroup)...

4. vb6 users use it because (OBVIOUSLY) they are “low level” in mind,
unable to use anything else, makes me feel guilty already!

Being on a "lower level on a learning curve" is different from being "low level in mind" -
there is no disgrace in it, especially when you're one of the "lateral movers" to VB
(but I guess everybody reads the things he wants to read).

I want to change. I want to be a better person.

As said, that kind of cynicism will not help you very much.

So it comes C and FORTRAN (for me)

Whatever works for you - just keep in mind that by a too often repeated
"learning-curve-hopping", the chance that one will only achieve "average results"
at best, is quite high.

Simple logic dictates, that when you put more time-slices of "experience-gathering"
into the same topic, you will end up higher on that (specific) learning-curve.

Olaf

[dilettante]

These threads end up the same way no matter what somebody tries to get at when they start the darned things.

It seems to be impossible to discuss any topic related to VB6 without the .Net fans crowding in and trying to derail it into yet another pointless argument from entrenched positions. It would be refreshing to see a thread where this didn't happen, but there would seem to be far too much insecurity on both sides of the divide.

I believe the real mistake is that sites like this try to crowd both groups in here together when they should be dealt with separately. Things would get just that much worse if this also had become a major resource for other languages like Delphi, REALBasic, and PowerBasic that contend for roughly the same application domains and programmer sophistication level.

It's the old "stick brother and sister in the back seat for a long trip" syndrome.

[FunkyDexter]

These threads end up the same way no matter what somebody tries to get at when they start the darned things.

It seems to be impossible to discuss any topic related to VB6 without the .Net fans crowding in and trying to derail it into yet another pointless argument from entrenched positions. It would be refreshing to see a thread where this didn't happen, but there would seem to be far too much insecurity on both sides of the divide.

I believe the real mistake is that sites like this try to crowd both groups in here together when they should be dealt with separately. Things would get just that much worse if this also had become a major resource for other languages like Delphi, REALBasic, and PowerBasic that contend for roughly the same application domains and programmer sophistication level.

It's the old "stick brother and sister in the back seat for a long trip" syndrome

I think there's an awful lot of truth there.

BTW. If anyone's interested in the opinions Sitten Spyne expressed (and I have to say, I endorse them 100%) I would recommend a book called "Head First Design Patterns" by Eric and Elisabeth Freeman, published by O'Reilly. It covers all the gang of four patterns as well as a bunch of other useful ones. It's written in a light hearted way that makes the information easily digestible but doesn't sacrifice depth of content in the process. I personally think it's a much better way to ease yourself into modern OO principles than the typically dry offerings you'll find elsewhere. Unfortunately it uses Java as the language it teaches in but that shouldn't matter as it's really about the concepts, not the syntax. Also the sassy looking girl on the front cover was also featured in a teen awareness campaign for gonorrhoea... though that's probably not really relevant.

[dilettante]

Interesting book review though: http://blog.codinghorror.com/head-fi...sign-patterns/

[FunkyDexter]

Yeah, I've read Jeff Attwood's blog post on it before. He undoubtedly writes a lot of good stuff and it's hard to argue with the credentials of the man who started Stack Overflow but on this one I absolutely disagree with him. The thrust of his argument is "Don't teach people good software design principles, they might miss-apply them. Make it hard to learn because then they won't learn it until they're ready". That's the antithesis of my position and the one expressed by Sitten Spyne. I think people should learn good design principles as early as possible and one of the things I thought the book was really good at was explaining why to apply the patterns.

[Tanner_H]

Yeah, I've read Jeff Attwood's blog post on it before. He undoubtedly writes a lot of good stuff and it's hard to argue with the credentials of the man who started Stack Overflow but on this one I absolutely disagree with him. The thrust of his argument is "Don't teach people good software design principles, they might miss-apply them. Make it hard to learn because then they won't learn it until they're ready". That's the antithesis of my position and the one expressed by Sitten Spyne. I think people should learn good design principles as early as possible and one of the things I thought the book was really good at was explaining why to apply the patterns.

Jeff clarifies his position if you check out the comments on that post...

I didn't say the book was entirely without merit. I like the writing style, and it's a good overview of patterns.

That said, I feel very strongly this advice -- that patterns are complexity, and not to be used lightly -- should be presented up front, not 600 pages in..

Brian, I agree the presentation of the book is great. But I still think the advice may end up steering a lot of programmers in the wrong direction:

http://www.relevancellc.com/2007/5/1...re-code-smells

I think Jeff's main complaint is that the authors waited until the end of the book to point out the (somewhat obvious) concept of "write simple code, then worry about patterns". But given that the entire premise of the book is patterns, I can't really fault them for this.

[JackB]

@Schmidt

Let me say that it is you that misunderstood my post.
It was not cynicism. It was sarcasm. In any case , not against you.

Of course its it is very very important (for devs and customers) that vb6 runtime is supported. But it takes more ,as about a development language , to be considered as supported. The comments were not about runtime , nor my post was about it.
You also missed the numbers of years on the comments about if vb6 was taught to unis. I wonder has ever been any language that was taught before , (let me repeat it BEFORE) its release.

As for the NASA part , I did mentioned it to emphasize the sarcasm beyond any doubt.
After all the FORTRAN mention was sarcastic enough.

But lets not be over analytical about these.

Why been sarcastic ?

Well sarcasm is not a synonym to irony , but can be both used to respond to someone who tries to insult you. Το replay without bad mouthing.
Somehow , someone can give an elegant answer to a tactless comment.

@Dilettante is right about the mixed thing of vb6 users and the .NET ones.

But its not symmetrical. I don’t see any vb6er comment about what the “others” have to do.
Lots of comments that a vb6 user HAS to move on.

Move where ? Move to the astonishing world of .NET.
Move what for ? To stop being a caveman.

No matter if someone uses C++, HTML, PHP , Javascript , Python , Java or anything else among vb6.
The fact that someone uses vb6 , makes him a caveman. Period.
Makes him a specimen that has to extinct.

Conversely , if someone has moved on, and now uses the last version of .net , is OK. He has moved on and now can be happy.

After all , I’m doing a favor to any of them who are going to feel guilty that have played with my emotions. They can be sure they haven't done it.

(Sorry from all , about the big post).

[Schmidt]

The fact that someone uses vb6 , makes him a caveman. Period.

See, that kind of bitter emotion, which swings along in your entire post,
made me write the thing about cynicism - which is a certain mind-state - a stance,
from which sarcastic and bitter comments are uttered more often than not.

And why do you *feel* like a caveman?
If you do not - then why mentioning it at all?

Do you think, that e.g. Tanner, dilettante or me feel like cavemans for using VB6?

The decision to stick with VB6 is rationally entirely comprehensible and sound also
from a technical point of view - sound even from a monetary point of view in most cases.

And if you reached your own decision to stick with VB6 from weighing the pros&cons
rationally as well, then no comment out of the .NET-camp should be able to make you
unsure about it.

Olaf

[JackB]

@Schmidt
It is NOT me that consider a vb6 user , or any other , for any reason as a caveman.
Some of the .NETers are.

I do not feel the need to prove their mistake.
After all , I don’t even know if I would like that.

That’s why the sarcasm.

[dilettante]

I use VB6 for one main reason: I have used it enough that I can almost think in VB6, know where most of the "furniture" is placed so I can "walk through in the dark without stubbing my toe" and so on.


I used it so much because for a long time I was getting one contract after another to rip and replace non-performant .Net software.

A good chunk of the problem stemmed from the hemming and hawing of garbage collection and slow-start due to giant class library loading, JITting, etc. But the honest truth is most of the problems I saw came from just very poorly written code and not anything inherent in .Net programs as such.


I've moved to Android client development and Java server development and I see much the same thing going on. And you know what most of it seems to come from? Blind application of patterns and OOP-drunkeness!

[Niya]

The decision to stick with VB6 is rationally entirely comprehensible and sound also
from a technical point of view - sound even from a monetary point of view in most cases.

Human beings are not a rational species. We're a rationalizing species.

[Schmidt]

Human beings are not a rational species. We're a rationalizing species.

No problem - go on, rationalize away ...

Olaf

[FunkyDexter]

I think Jeff's main complaint is that the authors waited until the end of the book to point out the (somewhat obvious) concept of "write simple code, then worry about patterns".

Yeah, I got that too and if the book was just a recital of how to apply the various patterns followed by a warning at the end I'd agree with him. But one of the great strengths of the book is that it fully describes the problem each pattern is meant to solve before it describes the pattern. The authors spend as much time explaining why and when to implement a pattern as they do explaining how. No doubt, understanding the Why and the When is probably more important than understanding the How.

I'd also disagree with his statement that patterns equal complexity. Miss-applied patterns equal complexity but correctly applied ones equal simplicity. A really good example is the strategy pattern (which rather also neatly dovetails into the inheritance vs composition debate that we touched on earlier). I'll try and summarise the example from the book because I think it's quite an easy one to follow.

Imagine you're simulating Ducks. All ducks Quack and Swim in the same way but they look different. So you implement a base class of Duck with an implementation of Quack and Swim and an abstract method for Display. You'd then implement a few derived classes (Mallard and RedHead) which would implement their own Display methods. Voila, you've got a bunch of ducks that swim, quack and fly appropriately without any duplication of code. Inheritance is a wonderful thing.

Then you implement a Rubber Duck. Rubber Ducks don't quack, they squeak, so you overrode the Quack method from the base class to make a different noise. This seemed like a pretty good solution at the time and kept things nice and simple. Gotta love Kiss programming.

Then you're asked to implement flight for the ducks. Mallards and RedHeads fly but Rubber Ducks don't. You've now got two obvious choices. You could:-
1. Implement it in the base class and override it to do nothing in the Rubber class. This is starting to increase the amount of overridden implementation of the Rubber class though (and therefore the coupling from the derived class to the base class).
2. You could make Fly abstract in the base class and implement it in each derived class - but that means RedHead and Mallard are going to implement exactly the same code so you'll be violating the DRY principle. And you know that the vast majority of ducks are going to want to share that Fly and Quack behaviour so you're going to violate it ALOT.

Realistically you probably pick option 1 as the simplest.

Now someone asks you to implement a WoodenDecoy duck which doesn't fly or quack. So now you add another derived class which overrides Quack to do nothing and overrides Fly to do nothing. And you've just violated the DRY principle because a wooden duck and a Rubber duck share the same behaviour for Fly (I.e. they don't) but each has it's own (admittedly empty) implementation.

So maybe, instead you implement a Flyable and NonFlyable duck class which inherits from Duck and then have all the other ducks inherit from them... except how does that marry up with the Quack method. Some ducks Quack but don't Fly (the newly introduced DecoyDuckWithRealisticQuackAction), some Fly but don't Quack (the newly introduced RemoteControlledFlyingDuckBoat), some Quack and Fly (Mallards and ReadHeads), some don't Quack or Fly (the plain old Decoy) and then you've still got that bloody aggravating Rubber duck which insists on bloody well squeaking... SQUEAKING! Where the hell's that going to fit in. And they ALL still swim. Go on, design an inheritance tree that properly manages this lot. I dare you!

This is a real world problem (well, sort of, it is if you substitute products or orders or staff for rubber ducks anyway) that most OO programmers have faced at some time or another. The book walks you through this problem in full before it ever gets to offering a solution (which is why I think Jeff's criticisms are invalid) and then offers up the Strategy Pattern as a solution.

The strategy pattern is a classic example of favouring composition over inheritance. It says, instead of just inheriting behaviours from the base class you should make each behaviour a class in it's own right and then have each instance of duck compose a set of behaviours.

• Write an iQuackBehaviour interface and then derive Squeak, Quack and DoNotQuack classes from it. Write an iFlyBehaviour interface and derive FlapWings, Glide and DoNotFly classes from it.
• Give the base duck class an iQuackBehaviour member and an iFlyBehaviour member(in other words, have it compose those behaviours)
• Change the Quack method on the base class to just call the Quack method of its iQuackBehaviour and the Fly method to call the Fly method of its iFlyBehaviour
• Now have each derived class set it's own behaviours in the constructors (n.b. to those interested in Inversion of Control you would, of course, make these properties of the derived class rather than setting them in the constructor but that's a different issue, you'd probably implement a factory too) e.g.

Public RubberDuck()
{
   QuackBehaviour = new SqueakBehaviour();
   FlyBehaviour = new DoNotFlyBehaviour();
}

At this point you can remove all implementations of Fly and Quack from the derived classes, they're no longer needed. You still implement Display in each derived class because you decided previously that no two types of duck look the same. And you can still use plain old inheritance for the swim method because all ducks swim and you want to keep things simple (until someone introduces China duck ornament at which point you'll refactor). We've got all the benefits of shared behaviour where we want it and we've got built in flexibility where we need it. Adding new behaviours and new derived duck classes is now a piece of cake and we can do so with confidence that we're not affecting extant duck types and behaviours

If you tried to design a plain old inheritance tree for this lot it would be hugely complex, prone to breaking and difficult to maintain. The domain added a bunch of complexity but the domain is out of our control. The pattern, far from adding complexity, removed it.


DuckStrategy.zip
Edit> I've attached a class lib to demonstrate just how much the strategy pattern can simplify a complex inheritance tree. I'm afraid it's in C# because that's where I'm fluent these days but it shouldn't be beyond the wit of either VB.Net or VB6 programmers to digest it.

Note that, although this pattern favours composition, it still relies on implementation inheritance for the Fly, Quack and Swim methods. As such it cannot be implemented in VB6.

I'm sure you can find a way to work around that but I'm willing to bet you won't be able to without either violating the DRY principle or increasing the coupling between the classes. I'm willing to bet I'll see a pretty chunky Case or If statement appearing somewhere.

VB6 was a great language. It let me knock out relatively shallow LOB business applications for years. But it was designed when OO was in it's infancy and so missed out on a few of the key features that OO really requires. As the apps I was producing grew in both scale and complexity I could not deny that VB6 was starting to fail me, largely because of those OO omissions. I could not take advantage of the work that was being done by others in the field of good software design and, instead, still had to rely on the same old hacks and workarounds which, while they worked, were not producing clean and maintainable code anymore.

I moved to .Net (and then C#) because they offered better ways of designing my applications and designing (not writing) my code. And no, Olaf, I didn't move before I was ready to understand these concepts. I moved because I already understood them.

I say again, if VB6 continues to work for you then use it. I do think you're putting yourself at some risk of having the rug pulled from under your feet but that risk does seem to be diminishing as MS continues to offer support for the run time. Familiarity is not cheap, and it's familiarity with VB6 that supports many of you in knocking out and maintaining your apps. That's a pretty compelling reason to stick with it.

But don't fool yourself that VB6 offers you the same abilities in terms of software engineering and good design that more modern languages do because it doesn't. Those more modern languages have the benefit of over a decades more hindsight than VB6 does.

VB6 may well be the right choice for many of you. The benefits may well outweigh the costs. But do take some time to understand the costs before you make that choice.


And one last thing in a post I've definitely allowed to become overly long: There is no such thing as Death By OO, merely Death by Bad OO. If, in the above example, we had continued to try to cram every possible combination of behaviours into our inheritance tree that would have been Bad OO and our application would surely have died from it. But Good OO contained the solution that we needed. Spend some time learning these patterns and all your worries vanish.

Edit> Hey, Sitten, was that the kind of design discussion you wanted? If so then start up some discussions in threads of your own. A few codebank submissions would be great place to start. I'd love to see more of this sort of stuff being discussed and would happily dive in. I've had half an eye on the template pattern thread but haven't contributed because I've never been aware of Hook as a pattern. I'd have said hooking is a technique used when implementing a Template pattern (amongst other uses) and that's led me to think I might be missing the point.

[Schmidt]

DuckStrategy.zip
Edit> I've attached a class lib to demonstrate just how much the strategy pattern can simplify a complex inheritance tree.
I'm afraid it's in C# because that's where I'm fluent these days but it shouldn't be beyond the wit of either VB.Net or VB6 programmers to digest it.

I did so just now - and would place your example definitely in the category "Death by Bad OO".
Sorry, but it's an overengineered mess of too many Classes in a wrongly choosen Pattern.

VB6 was a great language.

It still is Funky - it still is...

...I could not deny that VB6 was starting to fail me, largely because of those OO omissions .... I had to rely on the same old hacks and workarounds which, while they worked, were not producing clean and maintainable code anymore.

Then you never really learned to apply the correct Patterns, VB6-implementations work best with.

I moved to .Net (and then C#) because they offered better ways of designing my applications and designing (not writing) my code. And no, Olaf, I didn't move before I was ready to understand these concepts. I moved because I already understood them.

Ok, let's see how well you understood them.

Here's your Duck-Scenario implemented in VB6, using a combination of the Composition- and Factory-Pattern.
It comes (despite an additional Factory-Class) with:
- less Code (although even already respecting a LeadenDuck, which can't swim)
- half the Classes
- less redundancy, whilst keeping "DRY"
- more flexibility already from the Get-Go
- allowing dependency injection of alternative behaviours with ease
- already accounting for different Display-Methods (as e.g. on a Printer instead on Screen)

The following Form-Code:

Option Explicit

Private oDuckFactory As New cDuckFactory
 
Private Sub Form_Load()
  TestDuckMethods oDuckFactory.CreateDuck(Mallard)
  TestDuckMethods oDuckFactory.CreateDuck(RubberDuck)
  TestDuckMethods oDuckFactory.CreateDuck(WoodenDuck)
  TestDuckMethods oDuckFactory.CreateDuck(LeadenDuck)
End Sub
 
Private Sub TestDuckMethods(Duck As cDuck)
  Duck.Display
  Duck.Fly
  Duck.Quack
  Duck.Swim
End Sub

will output these results:

Mallard
  I'm flying
  I'm quacking
  I'm swimming
RubberDuck
  I don't fly
  I'm squeaking
  I'm swimming
WoodenDuck
  I don't fly
  I can't quack
  I'm swimming
LeadenDuck
  I don't fly
  I can't quack
  I'm sinking...

Here's the Source-Code: Ducks.zip

...don't fool yourself that VB6 offers you the same abilities in terms of software engineering and good design that more modern languages do because it doesn't. Those more modern languages have the benefit of over a decades more hindsight than VB6 does.

Feel free to deliver an example which proves your point...
The Strategy-pattern you applied to the above Duck-scenario definitely doesn't do so...

And what about the little Coding-Challenge I've layed out in post #730?

Why not taking this up, to show us all those advantages .NET (allegedly) has over VB6?
Maybe build a team, when you think it's too time-consuming or difficult for a single .NET developer.

Though it is a quite common LOB-scenario, which can be solved in VB6 with ease.

Olaf

[kfcSmitty]

While I'm not particularly a fan of the way Funky did it, I definitely don't like the way Schmidt wrote this.

So instead of having properties on each object and implementing the correct interface, you've hard-coded an if statement deciding whether a duck can fly or not. So instead of me going into the rubberduck and specifying it can now fly, I have to go into the fly class and modify the if statement? That is horrible to maintain!

I'm not sure if that was done just because it was a demo, but based on my experience, and the other programmers I work with (since Schmidt's code wouldn't actually pass peer review -- modifying core code because an implementation's property changed?), Funky's is definitely more extensible and easier to maintain.

[Schmidt]

So instead of having properties on each object

You mean "specific Duck-Class" (which my implementation doesn't need at all, to cover the scenario).

...you've hard-coded an if statement deciding whether a duck can fly or not.
So instead of me going into the rubberduck and specifying it can now fly, ...

Wich would be "hard-coding" as well... (in a specific class, which the example avoids)...

I have to go into the fly class and modify the if statement? That is horrible to maintain!

Not at all - in your case, you will have to locate the position to "change something"
(e.g. to be able to make a formerly non-flying "RubberDuck fly") this way:
- locate the "type of duck" in your Code (double-click on cRubberDuck for example)
- locate the correct "duck-behaviour"-Method of this Class (in this case Fly - or the Constructor)
Apply your changes in the appropriate Method.

In my case the thing works over the same steps (just starting with the behaviour you want to change):
- locate the "duck-behaviour" you plan to change (double-clicking on the bDuckFly-Class)
- locate the "type of duck" you will apply these changes to (over the Enum-Value)
Apply the changes in the appropriate Select Case.

Schmidt's code wouldn't actually pass peer review -- modifying core code because an implementation's property changed?)

A behaviour-Class is *not* Core-Code - one can easily inject another one also in the Factory, if you care to do so
(e.g. to implement a special "Flight-Mode" for RubberDucks in a separat, dedicated behaviour-class)

Shaggy's is definitely more extensible and easier to maintain.

Nope, absolutely not (and BTW, it was Funky, not Shaggy who provided the "Duck-Strategies").

Please enhance Funkys example about "Displaying on a Printer" -
then post the needed Diffs... I will then do the same on my example.

Olaf

[kfcSmitty]

You mean "specific Duck-Class" (which my implementation doesn't need at all, to cover the scenario).

No, I mean the implementation of the duck interface or abstract class. Whether you need it or not, if you have a property of "can fly," "nurses young," "extinct," etc., that will each have an if statement you will need to modify if you implement a new class or a duck goes extinct. Instead of just updating the interface, you now need to hunt down everywhere you have these if statements and update them. Hardly maintainable.

Wich would be "hard-coding" as well... (in a specific class, which the example avoids)...

Not hard-coding, especially if you are loading up the ducks as extensions. The core of the interface isn't changing, the properties of the implementation are.

Not at all - in your case, you will have to locate the position to "change something"
(e.g. to be able to make a formerly non-flying "RubberDuck fly") this way:
- locate the "type of duck" in your Code (double-click on cRubberDuck for example)
- locate the correct "duck-behaviour"-Method of this Class (in this case Fly - or the Constructor)
Apply your changes in the appropriate Method.

In my case the thing works over the same steps (just starting with the behaviour you want to change):
- locate the "duck-behaviour" you plan to change (double-clicking on the bDuckFly-Class)
- locate the "type of duck" you will apply these changes to (over the Enum-Value)
Apply the changes in the appropriate Select Case.

Maybe it is my way of thinking, but when I want to modify the a property of "rubber duck" I go into the rubber duck and find the property. I wouldn't think "I want to modify the rubber duck, so let me find the class that houses the property."

A behaviour-Class is *not* Core-Code - one can easily inject another one also in the Factory, if you care to do so
(e.g. to implement a special "Flight-Mode" for RubberDucks in a separat, dedicated behaviour-class)

I completely disagree. If I have a system that is used to categorize ducks, and for some reason I'm not using some kind of database, but rather extensions that house the information, it is definitely a core change to update that information. Instead of simply dropping a DLL into the project folder or something, I now need to edit the source code to update.

Nope, absolutely not (and BTW, it was Funky, not Shaggy who provided the "Duck-Strategies").

Whoops, sorry for the mistake Shaggy/Funky! I'll update my post after this. As for your comment, I've added comments to every point I've made as to why I feel the way I do. Can you elaborate more than "absolutely not"? My quotes above show even more why his is more maintainable in a real-world scenario. Yours may be nicer in a "this will never change so my code is more readable" scenario, but we all know that is never the case.

Please enhance Funkys example about "Displaying on a Printer" -
then post the needed Diffs... I will then do the same on my example.

Olaf

Not sure if that is directed towards me or not. I have no idea to what you're referring.

[Schmidt]

No, I mean the implementation of the duck interface or abstract class.

Wich is exactly, what I used the term "specific class" for.

Whether you need it or not, if you have a property of "can fly," "nurses young," "extinct," etc., that will each have an if statement you will need to modify if you implement a new class or a duck goes extinct. Instead of just updating the interface, you now need to hunt down everywhere you have these if statements and update them. Hardly maintainable.

Nope, my example is better maintainable - I mean, we have two "original Zips" out there, right?
- the one I've posted: http://www.vbforums.com/attachment.p...9&d=1439745837
- the one Funky posted: http://www.vbforums.com/attachment.p...7&d=1439717133

So, the needed maintenance-efforts can be measured quite nicely: -> please extend Funkys example about:
- the DuckType 'RedHead'
- introduce the new Property 'NursesYoung'
Then post the Diff to his original example-Zip - and I will happily post the Diff to my own implementation.

Maybe it is my way of thinking, but when I want to modify the a property of "rubber duck" I go into the rubber duck and find the property.
I wouldn't think "I want to modify the rubber duck, so let me find the class that houses the property."

That's just semantics - both sentences (in natural speech) are valid:
- "I want to change the flying-behaviour of a RubberDuck" (the order, how the change-position is located in my example)
- "I want to change the way, a RubberDuck behaves when flying" (the order you apparently prefer for code-location)

A behaviour-Class is *not* Core-Code - one can easily inject another one also in the Factory, if you care to do so
(e.g. to implement a special "Flight-Mode" for RubberDucks in a separat, dedicated behaviour-class)

I completely disagree. If I have a system that is used to categorize ducks, and for some reason I'm not using some kind of database, but rather extensions that house the information, ...

You're wrong also on that account...
Again the task:
- enhance Funkys example, to do "categorizations of 100 additional DuckTypes"
(god, what a mess that would make, defining all these new "specific Classes" in a Dll)
but do so, and I will post the differences, my example would require, as well).

Can you elaborate more than "absolutely not"?

No, there was no need to - because this statement was meant
in conjunction with the change-request I've asked you to apply.

Not sure if that is directed towards me or not. I have no idea to what you're referring.

I was referring to the change-request I've asked you to perform on Funkys original example.
Here it is again:
Please enhance Funkys example about "Displaying on a Printer" -
then post the differences to his original Code... I will then do the same on my example.

And now please, if you want me to take you seriously in the future discussion,
you should not find further excuses to avoid doing a few simple maintenance-changes
to prove your points.

Olaf

[Carlos Rocha]

I think it all depends on how one see the problem. Not sure if this will add something useful to it, but here's my view
DuckClass.zip

[Schmidt]

I think it all depends on how one see the problem. Not sure if this will add something useful to it, but here's my view
DuckClass.zip

That might serve as a good example for what was mentioned
whilst discussing the pattern-book, further above:

"write simple code, then worry about patterns"

It was possible to do it in that simplified way, because - so far - you
were using only simple Properties (different State) in your Duck-Class-Instantiations.

But what when you need to introduce a "Method that requires action"
into your current scenario - as e.g.:

Sub RenderLandingParable(SomeGraphicsContext)
'...
End Sub

And each different Duck-Type then requiring a little bit different implementations
of that Method. (that's what the 4 behaviour-classes are covering in my example).

Olaf