Where are all the big VB open-source projects?

[Tanner_H]

This is a question I've had for awhile, and I'm hoping the many experts at vbforums can shed some light on it.

By most accounts, VB (both classic and .NET) remains a popular choice for a lot of developers. A lot of people reference the TIOBE index when comparing programming language popularity, and VB always ranks highly, right around other interpreted language like C#, Python, PHP, etc. This seems to indicate that VB has a large user-base and a strong presence in the professional world, which I think most developers agree with.

So why, then, does VB have such a minor presence in the open-source world? There are lots of way to measure this; for example, ohloh.net compiles information from open-source code repositories like SourceForge and GitHub, and analyzes everything from "how many lines of code are in a given project," to more complicated things like "how much is a given open-source software worth in man-years?"

Ohloh has a metric they call "Hot Projects", where they look at an open-source project's activity over the past two years - number of commits, number of developers, users, etc - to highlight the most active projects in various development languages. (Not exactly rocket science.)

If you look at the popular project pages for languages similar to VB - C#, Python, Java - you see very similar lists: many healthy, established projects with large, active communities. The list for other languages, like C++, includes software many of us probably use on a daily basis.

Then there's the VB list. Half of the top ten projects have seen zero activity over the past two years, and the remaining ones are small projects with only one or two developers. That list includes both VB.Net and classic VB projects, so it's not like this is a .NET vs VB6 thing. Both are heavily underrepresented.

I realize this is just one data source, but I'd say the Ohloh data mirrors my personal experience pretty closely. I use a lot of open-source software, and I like to submit issues, patches, etc., when I can, but I rarely come across open-source VB projects. This seems odd, given VB's ongoing popularity in the closed-source, commercial world.

Any thoughts on why this is? VB has plenty of healthy online communities (obviously, since I'm posting this at vbforums.com!), so why aren't there more community-driven projects to match? Does it have something to do with the language itself? Or is it more about the kind of people that use VB? (I'm a heavy-duty VB user, so I hope it's not the latter!) Just curious on other people's thoughts, as I'm interested in what existing open-source VB projects could do to get more talented VB guys contributing their skills and their projects to the open-source world.

[georgekar]

'Note: this file has been modified for use within PhotoDemon.

'This code was originally written by vbforums user "dilettante".

I found a nice program...

[jpbro]

I think one big issue would be the use of third-party ActiveX OCX/DLLs. Many of them are not open source, but are still incredibly useful. It isn't/wasn't uncommon to be able to buy a one-time, royalty-free redistribution license for a couple of hundred dollars for libraries that perform incredibly useful functions that you wouldn't necessarily want (or be able) to implement yourself. Even some incredibly useful free libraries (e.g. Olaf's dhRichClient or vbRichClient) aren't open source. So how do you open source your project if your libraries aren't open source? You can, but then you are asking other developers to either buy the same libraries as you (some of which may no longer be for sale), or use a closed-source library. Either way, it "corrupts the open-source stack" so-to-speak, and is likely to deter adoption of your code within the OS community.

Which makes me think of an even bigger issues - VB6 itself isn't open source, and was created (and abandoned) by a typically OS antagonistic company. So what's the incentive for an OS project to use VB6 vs. an OS language/IDE?

Going back to the library thing - there are also some inherent difficulties with ActiveX registration, binary-compatibility, class IDs etc...I think that these are disincentives to OS distribution of some kinds of VBcode. An example would be the vbAccelerator code. They make a point to tell developers to change the project names of code that breaks compatibility, but what if a less knowledgeable deveoper doesn't, and then rebuilds and redistributes a DLL build with broken binary compatibility? You can end up with nothing but headaches if some users install two programs with competing builds and one of them breaks. Granted this may be be avoided with SxS, but not everyone uses that approach either.

Basically, I think the language was never developed with open source in mind, and as such there are a few somewhat serious disincentives limiting the attractiveness of open sourcing a VB6 project.

That said, you have a big VB6 OS project - does any of the above make sense? Has it been a challenge to be one of the few VB6 OS projects out there? If so, do you think the challenge has been exceptional compared to other open source projects? Curious about your experience.

[Schmidt]

...
I use a lot of open-source software, and I like to submit issues, patches, etc., when I can, but I rarely come across open-source VB projects. This seems odd, given VB's ongoing popularity in the closed-source, commercial world.

Any thoughts on why this is? VB has plenty of healthy online communities (obviously, since I'm posting this at vbforums.com!), so why aren't there more community-driven projects to match? Does it have something to do with the language itself? Or is it more about the kind of people that use VB? (I'm a heavy-duty VB user, so I hope it's not the latter!) Just curious on other people's thoughts, as I'm interested in what existing open-source VB projects could do to get more talented VB guys contributing their skills and their projects to the open-source world.

Thought about that myself quite often - and would identify the following reasons
(the points below somewhat interdependent...)

1) Of course reasons are to be found in the language (and the surrounding COM-lib eco-system) itself
- VB is "too easy", "too RADish"
- even when it gets harder, you will find many professionally written Tools from 3rd parties,
either for free, or for the price of "roughly a workday" when you're about to buy one from a
larger vendor (Professional Grid-, Charting-, Graphics-, Messaging-, Reporting- COMponents -
often bundled in a whole "suite of tools").

2) The above "easyness" attracts "studied professionals", but due to the low entry-level also a
lot of "semi-professionals" (who studied and work in a different field from informatics, but use
the tool for their daily, often scientific work - many coming into contact with VB over VBA) -
then there's quite a lot of non-professional, enthusiastic casual coders (hobbyists) - and of
course (as in any language) also the whole lot of beginners, who often choose VB due to its
"low-entry-barrier" to make the first steps on their learning-curve.
Any language has a kind of "demographic pyramid" - though ours is quite different - the
percentage of "self-thaught, fast-solution-oriented" programmers quite high - and our Newbies
(different from C/C++ Newbies) perhaps never before heard about "turing- or state-machines",
about basic "numeric analysis", "common base-algorithms", how a compiler works or what a stack is.
Don't get me wrong, I'm not "bemoaning" that fact - or engage in "down-talking" - that's just
how it always was with VB - and I still believe, that "programming should be as easy as possible
for everyone", not be "reserved for an elitist circle" - because there's a whole lot of problems which
can be (and were) solved by leap-frogging enthusiasts with good domain-knowledge about their
daily work.

3) Understanding of OpenSource in general (especially the different "rules" and "licenses")...
The VB-community (whilst being quite generous in posting freely usable code - even complete Apps -
e.g. to PlanetSourcecode or here into the CodeBank), doesn't know much about OpenSource -
or how choosing the right license might help to truly "bundle efforts", whilst steering and
influencing the intended usage of the opened sources - but for that to work (as it does for
other communities), the VB-community would have to learn a bit more about those licenses -
there's only a very few IMO, which could explain the differences and implications when a
projects sources are e.g. opened under GPL or alternatively under LGPL for example.

4) Good knowledge about Code-Repositories, to easier manage the incoming code-contributions
whilst working as a team... (and yes, shame on me ... started with stuff like that quite late -
only in the last few years learning to work with GitHub or BitBucket).

------------------------------------------

Point 2) I brought, to explain that we have more like a "babel"-situation in our community -
we often don't speak "the same language" - the differences in other dev-communities are
less drastic - experienced developers who are on a head-hunt for a promising project,
are easier understood, I think.

But point 1 is for or me (explaining a bit the effects, in points 3 and 4) one of the main-reasons,
why the more *experienced* VB-Developers rarely engage in OpenSource, seldom feel the need
to use Code-Management - if you are selfemployed, having lots of years of experience under your belt,
then you can knock out pretty astonishing things in quite a short time - kind of like a "one man army"
one might say - there's seldom the need for a team - the tool-universe and the RAD-features of VB
and its IDE(s) allow for that.

So, those who have the capabilities and the backgrounds, to e.g. write a new VB6++ compiler,
have pretty much learned "to do well all alone" - strong individuals - great skills - though with
regards to team-oriented development "for the good of the community", we're all lacking IMO,
seldom needed that for our jobs, never felt the need to develop "a great library, too complex
to accomplish in a reasonable time all alone, looking for devs with the same interest on the web" -
instead we were looking at the COM-tool-market... which in almost all cases delivered what we
were in need of.

Also playing a role with the above described effect is perhaps the fact of being:
"a typical Windows- or Office-programmer" ... which often goes along with:
"being employed in a Win-centric Office-world, having no time - the shops you're working for, or sell
your Apps to, often having no Linux-ties (where OpenSource-usage and -understanding can barely
be avoided and comes more or less automatically "with the job-description").

So, that's basically how I see those things - there's enough good VB-developers still around,
who could bring a decent VB6-compiler to fruition (when truly working together) - though those
devs are mostly over 40 or 50 in the meantime, having work and family, and are quite proud and
"stubborn" individuals (according to the circumstances I just described).

What's further hindering things with regards to e.g. "the new compiler and IDE", is
the currently entirely unclear course MS is steering.
Before Win8 (and the idiotic "go mobile, go touch" paradigm came up), it was pretty clear
to me, to develop the compiler for the typical VB-domain of "well-looking Desktop-Apps"
(based on a platform-independent OpenSource-lib, to ensure easier portability also for
other platforms, especially with regards to the Visual-Part which plays a large role in VB).

Though since Win8 nobody seems to be clear anymore about:
- how long Desktop-Apps will be around (I think MS is making a mistake in underestimating this demand)
- but even if those Desktop-Apps will be supported and around, against what API will they be developed in the future?
... e.g. I'm not really convinced yet, if it really will be Metro/WinRT/XAML which Desktop-Apps will be
developed against in the future - I'm not even sure if MS will even allow "Apps compiled the classical way"
(e.g. with different compilers than MS-VC) - or whether there will be a restriction to "MS-IDEs only"
(as the only tools which allow a "certified upload into the official AppStore").

These recent trends are quite crazy - and I hesitate to put additional years of efforts behind an attempt,
which (if MS continues in that manner) might well turn out to be "entirely pointless".

A relative secure alternative could be, to develop a VB6-to-Javascript compiler (treating Javascript as a
kind of "intermediate language", nobody will be doing any manual editing on) - then using the quite good
GUI-capabilites of modern Browsers for the graphics-stuff.

Any comments on that (waiting further, until MS comes up with clear statements and signals
with regards to future Desktop-development - or not waiting and going the JS-route already today)?

Olaf

[Schmidt]

I think one big issue would be the use of third-party ActiveX OCX/DLLs. Many of them are not open source, but are still incredibly useful. It isn't/wasn't uncommon to be able to buy a one-time, royalty-free redistribution license for a couple of hundred dollars for libraries that perform incredibly useful functions that you wouldn't necessarily want (or be able) to implement yourself. Even some incredibly useful free libraries (e.g. Olaf's dhRichClient or vbRichClient) aren't open source. So how do you open source your project if your libraries aren't open source? You can, but then you are asking other developers to either buy the same libraries as you (some of which may no longer be for sale), or use a closed-source library. Either way, it "corrupts the open-source stack" so-to-speak, and is likely to deter adoption of your code within the OS community.

Which makes me think of an even bigger issues - VB6 itself isn't open source, and was created (and abandoned) by a typically OS antagonistic company. So what's the incentive for an OS project to use VB6 vs. an OS language/IDE?

Going back to the library thing - there are also some inherent difficulties with ActiveX registration, binary-compatibility, class IDs etc...I think that these are disincentives to OS distribution of some kinds of VBcode. An example would be the vbAccelerator code. They make a point to tell developers to change the project names of code that breaks compatibility, but what if a less knowledgeable deveoper doesn't, and then rebuilds and redistributes a DLL build with broken binary compatibility? You can end up with nothing but headaches if some users install two programs with competing builds and one of them breaks. Granted this may be be avoided with SxS, but not everyone uses that approach either.

Basically, I think the language was never developed with open source in mind, and as such there are a few somewhat serious disincentives limiting the attractiveness of open sourcing a VB6 project.

Really good points - I was approaching more from the developers-side - but you underlined the fact,
that it was the whole VB-ecosystem which played a large role in shaping the mindset of
"the archetype of a VB-developer" (if there is such an animal).

And one point came out especially clear in your post - if we don't manage (as a community) to
overcome the "closed-sourceness" of our *BaseTools* (with a new Compiler and IDE, which also
allows to produce easier to load libraries, without any necessities to register them somewhere),
then we will not really change our ecosytem (and the mindset) ... sounds like a nice "vicious circle"
problem tough... <g>

Olaf

[si_the_geek]

Thread moved to the 'General Developer' forum.

[Tanner_H]

Well-said, jpbro. Thanks for replying - a lot of good insights here.

I think one big issue would be the use of third-party ActiveX OCX/DLLs. Many of them are not open source, but are still incredibly useful. It isn't/wasn't uncommon to be able to buy a one-time, royalty-free redistribution license for a couple of hundred dollars for libraries that perform incredibly useful functions that you wouldn't necessarily want (or be able) to implement yourself. Even some incredibly useful free libraries (e.g. Olaf's dhRichClient or vbRichClient) aren't open source. So how do you open source your project if your libraries aren't open source? You can, but then you are asking other developers to either buy the same libraries as you (some of which may no longer be for sale), or use a closed-source library. Either way, it "corrupts the open-source stack" so-to-speak, and is likely to deter adoption of your code within the OS community.

It is interesting how the proliferation of paid 3rd-party libraries splits the VB userbase. I'm sure there will always be paid 3rd-party libraries for niche uses, but a lot of fairly basic stuff can't be done in VB without the help of an outside library. In my own open-source projects, this dilemma leads to one of two things: having to rewrite a lot of stuff from scratch, which kills development pace, or just learning to live without certain features. Both decisions are unfortunate, but for an open-source project, paid libraries are pretty much always out of the question.

Which makes me think of an even bigger issues - VB6 itself isn't open source, and was created (and abandoned) by a typically OS antagonistic company. So what's the incentive for an OS project to use VB6 vs. an OS language/IDE?

In my experience, most open-source projects don't make a conscious decision to use a specific language. It's typically more a matter of "I started this project in a language I already know, and since the code is already written, I'm just gonna stick it online and see what happens." That's actually why I've done open-source work in VB - I had some VB code already written, it wasn't doing any good sitting in a random folder on my hard drive, so I stuck it online to see if others could make use of it.

Since VB seems to have a sizable following in the corporate development world, you'd think that would translate to a lot of personal and hobby projects, too... but if such projects exist, they aren't being shared online at the same rate as other languages, at least not that I can see.

Basically, I think the language was never developed with open source in mind, and as such there are a few somewhat serious disincentives limiting the attractiveness of open sourcing a VB6 project.

A great point, especially when referencing classic VB... though I'd hope some of the barriers have been lowered by successive iterations of .NET.

I'd also hope that VB's problem of "not being developed with open-source in mind" would be offset by the language's pure readability. For example, on non-VB forums related to graphics programming (my coding hobby of choice), I'll often share my existing VB code without modifications, and simply call it "pseudocode" to avoid the problems that arise when a guy publicly admits to using BASIC for serious work. Other coders - who have no familiarity with VB specifically - can totally understand the VB code, and many times they can even point out possible optimizations and bug-fixes. This is a really neat feature of VB that you don't get with other languages: that non-VB developers can read and understand the code without modification, which you'd think you'd make it amenable to open-sourcing. Maybe not enough to offset its other weaknesses, but still...

That said, you have a big VB6 OS project - does any of the above make sense? Has it been a challenge to be one of the few VB6 OS projects out there? If so, do you think the challenge has been exceptional compared to other open source projects? Curious about your experience.

I could probably fill a dozen lengthy posts with stories of managing open-source VB6 projects, but I'll try to keep it short.

Yes, there are some unique challenges to open-sourcing VB6 work. Here's a few off the top of my head.

- A lot of guys interested in contributing to my VB6 projects no longer have access to the VB6 IDE. This limits their participation to small contributions that don't require compiling. A free version of the VB6 IDE would make my life much easier, but that's never gonna happen. (And I don't blame Microsoft at all - doing something like that would gain them very little, and introduce a ton of headaches. Totally understandable.)

- VB6 plays pretty nicely with most source-code management systems, but there are obnoxious quirks. I'm a Git guy, and classic VB code causes trouble for Git with things like - randomly changing case of code between saves, sometimes sticking data in an .frx file for no good reasons, only to have it reversed on the next save, unpredictably reordering header data inside VBP files. Multiple developer PCs can have weird quirks too, like all your form measurements being in twips, so they change if a developer has a different DPI setting. Also, VBP references change completely between OS versions and 32/64-bit machines, which plays havoc with VBP versioning.

None of these are deal-breakers, and once you know how to work around them they're not too much trouble. But as you mentioned earlier, they do speak to the language not being developed with things like version control systems in mind. (.NET is obviously much better in this regard.)

- VB6 lacks a lot of the organizational features that make a large open-source project easier for developers to get into. Small things like organizing forms, modules, and classes into subfolders in the Project Explorer would help *a lot*. Separating components into ActiveX DLLs isn't a great solution either, for all the reasons you described in your post.

Anyway, all languages have quirks, and open-source projects always come with universal baggage (managing contributions, maintaining code quality and styles, finding contributors in the first-place, etc). VB does have some obnoxious traits, but in my mind, not enough to explain the huge deficit of meaningful open-source projects. And for VB.NET, it's even harder to explain, as C# has the same shortcomings as VB.NET (closed-source compiler, .NET framework versioning hell, etc), yet C# has a vibrant open-source ecosystem. Similarly, C#'s closed-source-but-free ecosystem has given rise to nice projects like Paint.NET, but the same doesn't seem to be true for VB.Net.

[Tanner_H]

Thanks Olaf for a typically well-constructed and thoughtful reply. Lots of interesting topics raised by your comments, hopefully I can do them all justice...

1) Of course reasons are to be found in the language (and the surrounding COM-lib eco-system) itself
- VB is "too easy", "too RADish"

While true, this hasn't seemed to hurt open-source work in other comparable languages. I see very little difference in RAD-ness between VB and Python, for example, but maybe the "BASIC" moniker hurts VB more than I would like to think...

2) The above "easyness" attracts "studied professionals", but due to the low entry-level also a
lot of "semi-professionals" (who studied and work in a different field from informatics, but use
the tool for their daily, often scientific work - many coming into contact with VB over VBA) -
then there's quite a lot of non-professional, enthusiastic casual coders (hobbyists) - and of
course (as in any language) also the whole lot of beginners, who often choose VB due to its
"low-entry-barrier" to make the first steps on their learning-curve.

Any language has a kind of "demographic pyramid" - though ours is quite different - the
percentage of "self-thaught, fast-solution-oriented" programmers quite high - and our Newbies
(different from C/C++ Newbies) perhaps never before heard about "turing- or state-machines",
about basic "numeric analysis", "common base-algorithms", how a compiler works or what a stack is.
Don't get me wrong, I'm not "bemoaning" that fact - or engage in "down-talking" - that's just
how it always was with VB - and I still believe, that "programming should be as easy as possible
for everyone", not be "reserved for an elitist circle" - because there's a whole lot of problems which
can be (and were) solved by leap-frogging enthusiasts with good domain-knowledge about their
daily work.

A very interesting observation. In most programming languages, the skill level of the community tends to follow a normal distribution ("Bell curve"), with a lot of coders in the middle, some well-meaning beginners, and some very advanced coders.

I agree that VB is different, with more of an inverse distribution - e.g. lots of beginners and a surprisingly good "expert" base, but a loss of many coders "in-the-middle". My experience has been that once guys get their feet wet with BASIC, they move onto other languages for whatever reasons, and in many cases never return to VB.

It's unfortunate, because in my own open-source projects, many of my most interesting and surprising contributions have come from the "semi-professionals" who might represent the middle section of VB's expertise curve. While the coding style from developers like this may not be as technically sound as, say, guys who studied CS at university, the code is frequently no less capable. Taking that a step further, I would say that the willingness of hobby developers to approach a problem from a unique angle can yield really terrific results.

So IMO, as an open-source project manager, I would say that VB developers of all shapes and sizes can contribute really incredible things, although you might not guess it from the "semi-professional" status of many guys who use the language.

3) Understanding of OpenSource in general (especially the different "rules" and "licenses")...
The VB-community (whilst being quite generous in posting freely usable code - even complete Apps -
e.g. to PlanetSourcecode or here into the CodeBank), doesn't know much about OpenSource -
or how choosing the right license might help to truly "bundle efforts", whilst steering and
influencing the intended usage of the opened sources - but for that to work (as it does for
other communities), the VB-community would have to learn a bit more about those licenses -
there's only a very few IMO, which could explain the differences and implications when a
projects sources are e.g. opened under GPL or alternatively under LGPL for example.

At the risk of sounding like a hypocrite, since I certainly make use of PlanetSourceCode contributions in my own projects... my personal opinion is that sites like PSC have been a huge detriment to the VB ecosystem. A giant, unstructured collection of .zip files is very community unfriendly, as there is no good way to incorporate changes from others, or easily browse code prior to downloading, or really to maintain any level of quality control beyond just throwing the .zip file up in the first place.

PSC suffers worse than other sites in that regard as its monthly contest actively encourages garbage contributions, with many coders simply repackaging other people's work, without thought for licensing or even basic copyright. Comments cannot be edited or deleted by project owners, so they tend to fill up with nonsense very quickly, and in recent years this has only gotten worse as the site has been overtaken by opportunistic coders simply looking to win the contest by default, as there are not many active contributors these days.

To be honest (and I hope I'm not crossing any boundaries here), a CodeBank section as found in sites like vbforums is also not ideal for creating a healthy open-source ecosystem. There is an *extraordinary* wealth of good VB code at VB forums, but it suffers from similar problems to PSC - difficult to incorporate changes and suggestions from others, no way to "browse" code without downloading whole zips, difficult to maintain a change log for project updates, once a thread grows beyond one or two pages, very difficult to track the development history.

This is certainly not to say that sites like vbforums don't fill a great niche (because they do, especially for the Q&A format) but I wonder how much better some of the CodeBank samples would be if they simply mirrored a public repository at a site like SourceForge or GitHub, where features like Bug-Trackers could be used instead of a long line of forums replies. I think both the nice guys who shared the code in the first place, and the community, would greatly benefit from that approach. My $0.02, anyway.

4) Good knowledge about Code-Repositories, to easier manage the incoming code-contributions
whilst working as a team... (and yes, shame on me ... started with stuff like that quite late -
only in the last few years learning to work with GitHub or BitBucket).

Certainly a sticking point. In my own VB6 open-source projects, I still get a lot of guys who are frightened to use Git, so they send me fixes and suggestions via email. "Beggars can't be choosers," and I am of course deeply grateful for any help and contributions, but familiarity with systems like Git would make my life much easier!

Of course, all coding languages have to get contributors to cross that "code repository" hurdle, so I'm not sure why VB would be specifically worse in that regard. Maybe the problem is that guys familiar with Git, like myself, haven't taken the time to write tutorials or articles helping new guys get acquainted. It's certainly something I have considered doing, but I always push it back in favor other, more pressing work...

Point 2) I brought, to explain that we have more like a "babel"-situation in our community -
we often don't speak "the same language" - the differences in other dev-communities are
less drastic - experienced developers who are on a head-hunt for a promising project,
are easier understood, I think.

But point 1 is for or me (explaining a bit the effects, in points 3 and 4) one of the main-reasons,
why the more *experienced* VB-Developers rarely engage in OpenSource, seldom feel the need
to use Code-Management - if you are selfemployed, having lots of years of experience under your belt,
then you can knock out pretty astonishing things in quite a short time - kind of like a "one man army"
one might say - there's seldom the need for a team - the tool-universe and the RAD-features of VB
and its IDE(s) allow for that.

Well-said. VB does seem to be king of the "one-man army" approach. I have approached a number of prolific VB developers and presented the idea of moving their projects from something like PSC to GitHub, where collaboration would be easier. Few, if any, make the move. Part of this is stubbornness (after all, stubbornness is what led them to producing impressive work in the first place) and part of it does seem to be an unwillingness to learn new things (again, if you are writing excessive code in VB6, this seems to be a common trait).

But can it be said that VB is any better or worse than other languages in this regard? I honestly don't know...

So, those who have the capabilities and the backgrounds, to e.g. write a new VB6++ compiler,
have pretty much learned "to do well all alone" - strong individuals - great skills - though with
regards to team-oriented development "for the good of the community", we're all lacking IMO,
seldom needed that for our jobs, never felt the need to develop "a great library, too complex
to accomplish in a reasonable time all alone, looking for devs with the same interest on the web" -
instead we were looking at the COM-tool-market... which in almost all cases delivered what we
were in need of...

...Any comments on that (waiting further, until MS comes up with clear statements and signals
with regards to future Desktop-development - or not waiting and going the JS-route already today)?

Olaf

Oh yes, many thoughts on that topic... but at the risk of sounding rude, I'm leery to dilute the current conversation by wandering too far off track. Maybe I can say this: as you very well describe, the same "one-man army" approach that makes VB attractive to many developers, also tend to hurt its ability to sustain large project development.

I often find myself split on this point. On the one hand, I would very much like to contribute to large-scale development of something like you describe. But I also feel that such a project is useless if there aren't big, existing open-source VB projects that would motivate the development of such a tool in the first place.

So I am torn: by continuing to try and increase the visibility of VB in the open-source community, I feel I am providing a good service to the community, and perhaps showcasing some of the strengths of classic VB that might draw more developers to take it seriously. If I stopped doing that, and instead turned my focus to helping develop VB-centric tools that were more open to open-source, is that really a good trade-off, or do we need both types of developers - those who create fun software using good tools, and those who make the good tools in the first place?

That's my dilemma, anyway. Not sure if others feel the same way.

[Shaggy Hiker]

Great replies to this by all. I particularly agree with what Schmidt was saying, but I'd also like to suggest another possibility:

A very large part of the OS community is also strongly anti-Microsoft. MS-bashing is part of the OS culture, as is a veneration of C++ and to a lesser extent Java. I'd post some cartoons about this, except that I'd have to hunt for them pretty extensively. The User Friendly cartoon is the one I have in mind, though xkcd has a bit of that, too. When a theme makes it into cartoons, it is pretty well entrenched in the community, or nobody would get the cartoon. The User Friendly cartoon explicitly denegrated VB, and has also explicitly exalted some of the leading OS figures.

So, if this belief is fairly common in the OS culture, you would expect less OS projects in MS languages. The only exception noted by the OP about OS in MS, is C#, but that could be for a couple different reasons. The first reason is that C# is so close to C++ in syntax that it is effectively a RAD tool for C++, and lacks the MS taint that goes with VB. Another possible reason is the persistent difference in pay for VB vs C# developers, which adds a blatantly economic reason to work in C# over VB. The other possible alternative is that C# is where most new technology comes out from MS (XNA was C# only, at first, as was LINQ, Lambdas, and native compilation), which would argue against the theory that there are few VB OS projects largely due to MS-bias. In other words, the Anti-MS OS could be BS.

Still, it's possible that the driver is cultural. Those in VB may simply be more tolerant of MS and less firmly in the anti-MS camp.

[Tanner_H]

Thanks very much for the reply, Shaggy. More interesting ideas to consider!

A very large part of the OS community is also strongly anti-Microsoft...

I'm probably biased on this count, as I've long had feet in both the open-source and Microsoft camps (and I'm actually typing this reply from my Macbook, lol), but I thankfully don't see the same kind of anti-MS hostility I did in past years. Maybe it's still there, but I'd like to think that some progress has been made on that front over the past decade. I give Microsoft a lot of credit for trying to court peace with the FOSS crowd - not just with their work on open-sourcing parts of the .Net stack, but Azure, direct contributions to the Linux core, and a lot of smaller initiatives.

I like your theory on why C# could be exempt to years of past MS hostility, but I wonder - what do you think about all the great open-source software that is Windows-only, or that specifically targets Windows? Looking over my own software collection, I see quality projects like Notepad++, MinGW, the whole PortableApps intiative, WAMP, and probably tons more if I looked harder.

Not to disagree with your assessment, necessarily, but I find there is an impressive ecosystem of Windows-only open-source software, and in the case of Notepad++, I often find myself wishing some open-source Windows software was available on other OSes.

As I said, maybe I am overestimating the newfound "love" between Microsoft and open-source, and bad feelings still linger...

So, if this belief is fairly common in the OS culture, you would expect less OS projects in MS languages. The only exception noted by the OP about OS in MS, is C#, but that could be for a couple different reasons...

A great assessment on C#, including the economic argument.

Since you mentioned Java, it got me thinking about how Java went from being looked down on by much of the serious programming crowd (particularly C/C++ developers), to being a major part of the professional coding ecosystem. I remember the many years that being a Java developer was not something you'd admit to in public, because it invited the same kind of comments VB guys still get - "Java isn't a real coding language," "only terrible programmers use Java," etc.

In my mind, Java really came into its own when two things happened.

1) Google making Java the language of choice for Android development. It's hard to argue that a coding language is somehow lesser when a behemoth like Google doubles-down on it.

2) Hugely successful software emerging, that just so happened to be written in Java. I'm thinking of things like Minecraft, which for all its flaws, has sold something like 100 million copies, which once again legitimizes the language in a way that 100 million online discussions never will.

Anyway, this thread has provided a lot of good information on the lack of popular software written in VB, but I think #1 is a problem too. Microsoft has never doubled-down on VB as a development tool, and in many ways, they actually seem to be giving it less attention as time goes by. (As you say, all their interesting work happens in C#.) And I certainly don't see any other tech companies investing in BASIC as a development tool.

I wonder if #2 is caused by #1, or vice versa, or if like everything else in this conversation, it's a chicken-and-egg problem where one feeds the other.

[Shaggy Hiker]

I'd say it's the chicken and egg. If MS is primarily a C++ culture, then C# > VB is probably how they see it. I personally feel that the C-family of languages carry too much baggage from the days when computers had no reserve processing power, but it's hard to argue with the mass of coders who work in that family (which includes Java, as it is syntactically similar to C). It's even harder to argue with the pay differential. I feel that VB is a more evolved language, but my opinion doesn't amount to anything.

In general, I feel like the amount of anti-MS feeling has diminished, as well. I've always thought that a big part of that was that Linux didn't take the world by storm, and by now nobody expects it to. Without an OS taking significant share, how anti-MS can you really be? I've always thought that was why Dilettante is so sold on Android, but I'm not convinced that Android will do better than Linux, even with Google behind it.

[Tanner_H]

I agree, and am much in the same boat - I enjoy high-level languages like VB and C#, and feel coding would benefit greatly from moving more in that direction, but the sheer momentum behind C/C++ will probably make it the development language of choice for many years to come. Things like quality third-party libraries take a long time to evolve, and C-like languages have so many that that it may never be displaced as *the* language to learn.

Re: the Linux crowd and Microsoft, it's funny how in many ways they've ultimately met in the middle. Microsoft is more open-source friendly than it's ever been, while Linux has seen the emergence of companies like Red Hat and Canonical who have turned open-source into profitable commercial endeavors. I'm glad that zealots on both sides have seen the wisdom of both approaches; coders need to be paid for their work, but it's a lot easier to code if good open-source libraries exist. These days, there seems to be a healthy balance between the two ecosystems. (Just not for VB, which is why this thread exists!)

Where it goes from here will certainly be interesting. In the consumer space, Apple comfortably controls the high end of the market, while Google has successfully taken over much of the low end. Microsoft has been increasingly squeezed in the middle, as Apple has invested more and more heavily in devices like the iPhone and iPad, while Google continues producing nicer and more capable Android and ChromeOS devices. Tablets and phones only obscure the space even further, and we all know about Microsoft's struggle in those arenas.

I actually think that's a big part of why Microsoft has invested more heavily in open source in recent years. Their software ecosystem is really struggling compared to iOS/OSX and Android, and better open-source involvement could be a way to help.

Whether or not VB guys still have a role to play in that world... well, I guess time will tell.

[Schmidt]

I've always thought that a big part of that was that Linux didn't take the world by storm,
and by now nobody expects it to.

If those who currently think, that "mobile devices will take over the world by storm" are right
(and MS clearly belonging into that camp), then Linux has already won (by a huge margin).

I've always thought that was why Dilettante is so sold on Android, but I'm not convinced that Android will do better than Linux, even with Google behind it.

Well, LMGTFY again:
http://en.wikipedia.org/wiki/Android...ting_system%29
First sentence: "Android is an operating system based on the Linux kernel ..."

And as the trends currently are, I highly doubt that your opinion that Android will play
a "diminishing role" in the mobile world anytime soon, should be paid much attention -
the opposite is true instead:

Phones:
http://www.businessinsider.com/iphon...t-share-2014-5
"...In Q4 2013, according to research firm IDC, Google's Android mobile operating system had a 78% share
of all users globally... IDC predicts that in 2014 Android will claim 80.2% of users ..."

same thing for Tablets (growth for Android):
http://www.strategyanalytics.com/def...viewer&a0=5505

Olaf

[Shaggy Hiker]

Well, that's true, but I'm not sure how much it matters in a practical sense. Mac OS is based on the Unix kernel (unless that changed again, I don't keep up with Apple), yet people don't call Mac OS Unix. Similarly, Android is based on the Linux kernel, but most people hold Linux and Android as two different things. If Android takes over the world, then technically, Linux has taken over the world, but only a subset of geeks will see it that way.

[dilettante]

Android is probably doomed as a desktop OS now. After Google combined the Android and Chrome OS efforts under the former Chrome OS boss (Pichai) all such plans have been shelved, reversed, and actively suppressed. The Chrome OS group feels desktop Android steps on their toes.

So the one thing that might have saved the world from a fate of the changing over-mobilized Windows landscape (i.e. a shrinkwrapped x86/x64 desktop Android, blessed by if not from Google) will never occur. Instead while things will be out there (e.g. Console OS) they'll be marginal players like conventional Linux distributions always have been.

Expect people to tighten their grips on Windows 7 and Vista even tighter than they are now. A few years out Microsoft will have a hard job killing Win7, probably as hard as killing XP was.

[Tanner_H]

I wouldn't read too much into Android's market share at present. They have had effectively zero competition at the low end of the market, which is where the vast majority of their sales numbers come from. Remember that Android passed Apple in phone sales in 2010. Four years later, Apple still rakes in 3.5x the annual revenue that Google does, and as of 2013, a disproportionate number of Android users were still switching to iPhones. Gross device counts aren't everything, especially when you look at numbers like mobile ad revenue, (another relevant link), where Android continues to perform miserably.

Now that we're getting some viable competition at the low end of the phone market, things are going to become more interesting. Samsung's discontent with Android has long been known, and as they more strongly emphasize Tizen, Android is going to suffer. (Samsung still makes up a hugely disproportionate number of Android sales.) Similarly, now that Microsoft has finally wisened up and stopped charging OEMs for Windows Phone, expect to see a lot of other Android-unhappy manufacturers give Windows Phone a try. Whether they stick with it is anybody's guess, but Microsoft has a much better track record of successfully courting hardware companies than Google does. I wouldn't count them out yet.

Android does a lot of things right, but troubling security practices, fragmentation, discontented hardware manufacturers, and Google's iron hold over both the marketplace and all the key Google Play apps are going to continue to haunt it.

And this isn't even getting into things like iOS developers making 5x more revenue than Android developers. Developers go where the money is, and Android remains a questionable investment that way.

[Schmidt]

If Android takes over the world, then technically, Linux has taken over the world, ...

Glad we have established at least that ...

...but only a subset of geeks will see it that way.

Then let's hope, that said geeks will keep reminding those who claim otherwise.

Olaf

[dilettante]

I think you miss the point.

What Android offered was an "open" platform from a deployment standpoint. Both iOS and Metro-fied Windows are closed in the sense that writing and deploying small-scale applications is very difficult.

People could write or hire out custom in-house applications and deploy them relatively trivially on Windows in the past. But the changes make such one-off and line of business applications (probably most of what VB and VB.Net programmers produce today) much harder to get onto machines to be run there.


Most programmers simply are not going to produce mobile applications for the broad market that will ever accrue much revenue at all.

[Tanner_H]

Most programmers simply are not going to produce mobile applications for the broad market that will ever accrue much revenue at all.

Yes, I certainly agree. So what's the debate, then - which operating system coders will flock to if/when Windows becomes less relevant? I was under the impression that an argument was being made that developers were migrating from Windows to Android (or that they should be moving to Android), but very possible that I misunderstood. (Sorry!)

Re: all things deployment. I would argue that the web is the last great "open" platform, and that all small-scale application deployment will eventually migrate there. The timespan is debatable, but the ultimate migration is inevitable.

Why? All companies want to monetize their marketplaces, and as a result, deployment is already very similar across iOS/OSX, Android, Windows, Amazon's Marketplace, etc. If companies want to monetize their respective marketplaces, they assume liability for said marketplace, which makes them more averse to risky software, and deployment rules grow stricter. I don't see this ever changing, especially since the web is more of an open marketplace than any company could ever provide (with all the good and bad that entails).

So developers really only have one choice: play by the rules of whatever closed ecosystems you want to participate in, or move your software to the free-for-all web.

For VB developers, the story is more conventional, pretty much what you said earlier: "tighten your grips on Windows 7 and Vista even tighter." The whole "Windows 7 is the new XP" seems pretty much a given. My curiosity is whether Microsoft will humor Win 7 holdouts as patiently as they humored XP holdouts, or whether they'll finally say enough is enough and make Windows 9 the unified desktop / mobile operating system people keep rumoring. If many of Microsoft's developers have already moved to other platforms, what do they have to lose by breaking backwards compatibility and starting anew with Windows 9 or 10...?

[Schmidt]

I wouldn't read too much into Android's market share at present. They have had effectively zero competition at the low end of the market, which is where the vast majority of their sales numbers come from. Remember that Android passed Apple in phone sales in 2010. Four years later, Apple still rakes in 3.5x the annual revenue that Google does, and as of 2013, a disproportionate number of Android users were still switching to iPhones. Gross device counts aren't everything, ...

Yep, currently Apple is holding its own - though at the bottom of the article I posted a Link to (here it is again):
http://www.businessinsider.com/iphon...t-share-2014-5
there's a well-made point about "lower average prices" and their long-term-effects, I agree with...

Note that the average Android price is heading toward $200 and the average iPhone price is heading toward $600. Apple is asking the question, do you want to pay three times as much for our phones? Thus far, 80% of the market has answered "no."

Branding and quality are important, of course. Apple usually wins there. And Apple's business model is to only do the most profitable thing, not the most widespread thing. So loss of share may not bother Apple CEO Tim Cook. It may, in fact, be good for both margins and shareholders.

But the history of computing has one iron-cast lesson for us all: Devices get cheaper over time, and better over time. The high-priced seller usually loses. This is why nobody uses $8.8 million Cray computers anymore.

As for developers, their potential revenue (and the success of the appropriate AppStores) -
it seems that Android is catching up.
http://www.businessinsider.com/googl...t-apple-2014-4

Aside from that, the successful developers and companies who make good money
with mobile Apps, usually leave nothing out and develop for all mobile platforms.

But well, Phones and Tablets currently *are* "status-symbols" - and in the same
way as a Mercedes will always have its place in the car-market, Apples current success
with a similar HighQuality/HighPrice strategy will perhaps remain a constant in the mobile
and tablet-market too.


But to get back to the original topic, and to your reply in post #8

... If I stopped doing that, and instead turned my focus to helping develop VB-centric tools that were more open to open-source, is that really a good trade-off, or do we need both types of developers - those who create fun software using good tools, and those who make the good tools in the first place?

That's my dilemma, anyway. Not sure if others feel the same way.

It's not that much a dilemma IMO... it's pretty simple for us really (especially now, that
MS has clearly stated, that no OpenSourcing of VB6 is planned) - if we want to continue
"to have fun" (in the long-term), then we either manage (as a community) to come up with
a nearly compatible compiler and IDE for VB6, or we don't.

There will be (with high probability) nobody else who will do it - we are on our own.

As for the term "large scale project" you've choosen - a new "community IDE" will in the end not
contain much more lines of code than say, PhotoDemon - it's perhaps more tricky in some areas,
but those will make up only about 10-20% of the over-all-source - the rest of the codebase
will be "business as usual" (just a lot of work, not that much rocket-science).


Olaf

[dilettante]

With Android failing to stake out a desktop position the pressure on Microsoft to continue supporting conventional desktop programming is reduced. This could eventually mean the typical VB/VB.Net guys will be frozen out entirely with no platform to develop for.

The winners will be the "big guys" selling generic packages everyone must conform to. If you have a special requirement... too bad, computers are no longer for you. The corporate driven mass market has won and "taken all."

Android remains as a contender within the limits stemming from Google's anti-desktop position. You can still run Android-x86 for now, or some Intel-blessed build, etc. but now Android will never become a generic desktop OS for millions to use. The Chrome OS guys want to keep Android strictly a phone/tablet OS.


As for the web, surely you jest?

The market segment I'm in doesn't fit there. Most of what I'm doing runs either on a server (mostly integration services, sitting between mainframe code and Windows code) or else on embedded devices. For the latter Android-on-ARM is quite viable, these devices are primarily data loggers attached to various sensors.

I also write and support software that sits between user-written Office VBA and data feeds of several kinds. This typically comes from those Android (and previously WinXP Embedded) instruments. The VBA guys jealously guard their "proprietary analysis algorithms" so I'm basically providing VB6 DLLs they use from Excel or Access.

I can give customers MSIs and APKs and they can trivially deploy to Windows servers, desktops, or Android now. There is no "app store" required or desired.

I can't see where web applications fit in there anywhere. There isn't anything to publicly expose and most of these are small engineering companies with no IT guys to change the diapers of a web server farm. Many of the workers are in the field working on laptops with no Internet access much of the time.

A web application sure isn't going to provide a mainframe application with high-volume access to a 3rd party data cleansing application that runs on a Windows server.

[dilettante]

To address the actual topic here: I think the biggest factors in the state of "VB open source" projects are probably pretty simple.

One is that VB probably has a far higher proportion of untrained casual programmers than many other languages. The other plays into that: VB is more often used to build specific solutions rather than generically applicable tools and most successful open source projects are tools. Things like libraries or utility programs.

[Tanner_H]

Thanks all for continued replies, and sorry to keep drifting off-topic. However I think these things all tie back to the original thesis of the thread.

With Android failing to stake out a desktop position the pressure on Microsoft to continue supporting conventional desktop programming is reduced. This could eventually mean the typical VB/VB.Net guys will be frozen out entirely with no platform to develop for.

This is what motivated me to start this thread in the first place. I see a ton of parallels in Microsoft 2014 vs Microsoft 2000, and I think VB.Net's days are numbered. At this point, I think the only thing that could spare VB.Net from a demise similar to classic VB is the emergence of some "killer app" that relies on .Net. (But even then, it's probably too late.)

The similarities are obvious: new management team at MS. Serious threats to Windows (back then, the web; now, mobile), and accompanying year-over-year declines in Windows revenue. Heavy pressure from investors to improve profitability, and years of investment in VB failing to produce a meaningful contribution to Microsoft's bottom line.

VB represents a large cost to Microsoft, and traditionally they've accepted that cost because VB served as a sort of "gateway drug" to the MS ecosystem. If they could get students and other new programmers tied into their ecosystem via VB, they could eventually monetize those guys through MSDN, etc, plus those developers would help produce software that further tied end-users to the MS ecosystem.

In the late 90's, it became obvious that such a strategy wasn't working. Java and web technologies had completely displaced VB as the language of choice for education, and the web was further threatening to erode developers' reliance on the MS ecosystem. (In retrospect, the threat was obviously overblown, just as I think the mobile threat is overblown now - but I don't underestimate the ability of such threats to motivate extreme changes.) Anyway, MS did the most reasonable thing they could: they greatly reduced their VB costs by integrating VB into the new .Net initiative. Yeah, VB developers were furious, but all that fury obviously didn't make a dent in Microsoft's bottom line.

Today, things are very similar. VB.Net has still failed to produce a meaningful ecosystem, and if anything it's far less relevant to the wider coding community than VB6 was in the late 90's. VB also continues to cost MS a lot more money than they'd like (double the support staff, double the documentation, double the Visual Studio testing and debugging), and for what? Microsoft could axe VB.Net tomorrow and simply tell everyone to move to C#, and I doubt they'd have any meaningful repercussions from it. In fact, since migrating from VB.Net to C# is more straightforward than VB6 to VB.Net ever was, it would likely produce less fallout than the VB6 to VB.Net transition ever did.

Anyway, maybe my analysis is totally wrong, but I think the VB6 users of 2000 have more in common with the VB.Net users of 2014 than either side would like to believe. To that end, I think it's worthwhile for VB developers (classic or .Net, doesn't matter), to do one of two things: reevaluate their love for VB, or work to improve the overall VB ecosystem. Quality open-source projects are a very visible way to do that, and if there are a bunch of VB developers with potentially interesting hobby projects hidden on their hard drives, now's a good time to reevaluate sticking those things online, and possibly saving VB.Net from the same fate as VB6.

(Was that melodramatic enough? haha)

I never participated in the commentary on the silly MS petitions to open-source VB6, but what I wish those guys would have realized is that instead of wasting time badgering MS, they should have spent their time developing quality software using VB. That would go much further toward encouraging MS to invest more in the technology (or open-source the old compiler, whatever), than a million silly diatribes about "abandoning developers" and "making fatal mistakes" and "you will live to regret this," blah blah blah.

[Tanner_H]

It's not that much a dilemma IMO... it's pretty simple for us really (especially now, that
MS has clearly stated, that no OpenSourcing of VB6 is planned) - if we want to continue
"to have fun" (in the long-term), then we either manage (as a community) to come up with
a nearly compatible compiler and IDE for VB6, or we don't.

While I think this analysis is spot-on, I have big doubts about the follow-up...

As for the term "large scale project" you've choosen - a new "community IDE" will in the end not
contain much more lines of code than say, PhotoDemon - it's perhaps more tricky in some areas,
but those will make up only about 10-20% of the over-all-source - the rest of the codebase
will be "business as usual" (just a lot of work, not that much rocket-science).

Maybe I am pessimistic, but I see a compiler+IDE being much, much more work than a silly little project like PhotoDemon.

Despite many attempts to replace VB with a more "open" variant, there will always be an unsurmountable hurdle: VB projects' reliance on the Windows API. VB's core language set is so limited, that any meaningful VB project must rely very heavily on WAPI to fill the gap.

So the question is - would VB fans produce a new Windows-only VB IDE, that perhaps just translates VB code to some other Windows-friendly language, and relies on an existing compiler to do the rest? Or would the goal be to create an entirely new VB, that can stand on its own, with a custom compiler, and a custom feature set completely separate from WAPI.

The former is possibly doable. A ton of work, but not impossible, especially if the goal was merely to translate existing VB code into something that a 3rd-party compiler could handle. (Although if it were trivial to do this, you can bet that VB6 to VB.Net translators would be a lot more prolific than they are.)

But I think the latter is downright impossible, for an obvious reason. Building a VB-like language independent of WAPI would require VB guys to rewrite all their existing projects from scratch. If they're going to do that, why not just do the obvious thing and move to another language entirely? Or if they really love the VB syntax, what could be done to improve on an existing VB-like solution, like Gambas?

Apologies if this is overly pessimistic. I'm just trying to get a feel for what is meant by the term "community VB replacement"...

[Tanner_H]

As for the web, surely you jest?

Sorry dilettante, I was still talking about the "direct-to-consumer" market. For other markets - B2B, intranet, embedded solutions like you describe, you are definitely right, and the web is no more of a replacement now than it was a decade ago. (Though to be honest, for embedded systems, I have trouble seeing what advantage Android provides over stock Linux + Linaro tools and patches - maybe you can educate me?)

[Schmidt]

Maybe I am pessimistic, but I see a compiler+IDE being much, much more work than a silly little project like PhotoDemon.

Not if we use (as is the current practice in VB6) a C or C++ Code-Emitter (with an
existing C or C++ compiler in the backend, which does the final translation into native
CPU-instructions for a given platform).

Despite many attempts to replace VB with a more "open" variant, there will always be an unsurmountable hurdle:
VB projects' reliance on the Windows API.
VB's core language set is so limited, that any meaningful VB project must rely very heavily on WAPI to fill the gap.

Well - and there you have the reason for the vbRichClient-project, which
provides a Class-Layer which abstracts from most of the underlying System-APIs.

Aside from that - *if* Win32 goes out of scope on the Win-Platform - then not
only the typical (WinAPI-heavy) VB6-code will be doomed - but any compiled
binary which directly (or indirectly) made use of those APIs (along with any
Compiler or IDE which is heavily based on the classic Win32-API)...

On the other hand, if the Win32-API will remain available on Win-Desktop-Systems for
more than "the next 10 years" - then the output of the new compiler will of course be able
to call into that "classic Flat-API"... (How many lines of code do you think are needed,
to re-implement the delayed loading-mechanism of the VB6-Declare-Statement? -
I can ensure you, that it is not more than about 200-400 lines, to make the new
compiler support that - the C-Code which is emitted to the backend, will support
appropriate LoadLibrary and GetProcAddress-calls just fine - also against the
64bit-pendants of this WinAPI-layer, should you decide to compile to a 64Bit Binary).

So the question is - would VB fans produce a new Windows-only VB IDE,
that perhaps just translates VB code to some other Windows-friendly language,
and relies on an existing compiler to do the rest?

Yes - VB6' C2.exe currently does nothing different in this regard.

Or would the goal be to create an entirely new VB, that can stand on its own,
with a custom compiler, and a custom feature set completely separate from WAPI.

As explained above - from the viewpoint of the compiler - the WAPI-support
comes automatically, when VBs Declare-Statements are supported - this is not
rocket-science - and e.g. FreeBasic already demonstrates, how such platform-
independent support for VBs Declare-Statement can be implemented (on Linux
it maps against dlopen/dlsym - on Windows against LoadLibrary/GetProcAddress).

The former is possibly doable. A ton of work, but not impossible, especially if the goal was merely
to translate existing VB code into something that a 3rd-party compiler could handle.

Yep.

(Although if it were trivial to do this, you can bet that VB6 to VB.Net translators would be a lot more prolific than they are.)

Have to disagree here - the *language* (the naked one) could have been
lifted over pretty easily, nearly 100% compatible (including proper mappings
from VB6s Integer or Long-Types into the appropriate MSIL-representations).

It's the VM, the new (COM-incompatible) Class+Object-System, the GC vs. RefCounting,
the immutable Strings - and of course the surrounding Class-Runtime which stood in the way.

We will have less problems (by far) with a true native compiler in the backend.

Apologies if this is overly pessimistic.
I'm just trying to get a feel for what is meant by the term "community VB replacement"...

A replacement which is (as it always was with VB6 and C2.exe) a relative thin layer
above a C/C++ compiler:

True native compilation - mapping of VB-UDTs (in the correct alignment) and
VB-intrinsic Types to their appropriate C-type-representations and -structs.
(e.g. support for unsigned Integer-Types is easily accomplished at this occasion).

RefCounting Classes, their methods supporting the COM-ABI - internally generated
compatible to the current COM-VTable-scheme.

Continued support for (mutable) 16bit-BStrings (WStrings).
Continued support for absolutely compatible Arrays (based on the SafeArray-struct).
Continued support for the Declare-Statement (incl. __cdecl-calls at this occasion).

Support/Mappings for all Flat-Functions which currently make up the VBRuntime
(quite an amount - but easily splittable across a few developers - for the Win-
Version of the compiler, many VBruntime-functions have direct representations in
system-functions).

In addition to the classic (mostly flat) VBruntime-functionality, the new Class-Layer
of the vbRichClient provides modern functionality especially with regards to the new
(already platform-independently mapped against cairo) graphics- and Control-Engine.

That's it very roughly (compiler-wise).

I could go on in "overwhelming detail", because that's *my* personal "hobby-project"
I engaged in over the last years... a few more comments on that I offered already in:
http://www.vbforums.com/showthread.p...True-VB-7-0%29
... in case you're interested in flying over them.

Olaf

[georgekar]

Thanks to Virtualbox vbcode can be usable for decades. So for the coder which love to code with the friendly basic, os isn't the problem.
Businesses solutions can stay to mainstream top languages and all the thing they have to do is to collaborate with other professionals.
Here the reason of this topic is to initiate a collaboration between non professionals. And this is a bit difficult. Especially on two things. First we have to use a version aware solution and a treatment for some rules that define the scope of the program. Any idea about that?

[dilettante]

(Though to be honest, for embedded systems, I have trouble seeing what advantage Android provides over stock Linux + Linaro tools and patches - maybe you can educate me?)

Embedded Linux distributions are still viable and Linaro has helped, but the rise of Android has meant very good tooling support (both breadth and depth). Despite much talk about fragmentation the situation for Android there is far less dire, more like a 64-square checkerboard vs. 1000x1000 pixels of white noise.

Thus Android presents a developer target with a focus much more like Windows and Mac. This means hardware OEMs can produce boards and systems with a reduced software and driver development burden, yielding lower costs and longer life cycles. It also means programmers have huge resources available in terms of tutorials, training materials, formal classes, and so on as well as community support. And there is a great deal of code from the vast Java open source portfolio that can easily be repurposed for use in Android projects.

All of this momentum makes it easier and cheaper to develop for Android than most Linux-based OSs.

If there was a better "desktop Android story" this would only improve things. That should make it even more viable for people among the VB masses to play with and even adopt as an alternative on a casual programming basis, whether LOB or hobby. But no point in crying over spilt milk.

[Schmidt]

Thanks to Virtualbox vbcode can be usable for decades. So for the coder which love to code with the friendly basic, os isn't the problem.

Whilst it is true, that VMWare, VirtualBox & Co. can extend the life-span of "legacy stuff" -
as soon as we let that happen, we would agree and admit that: "VB is truly dead now"...

Aside from that, developers who want to code in a Basic-language, can always resort to
the already existing (although less "visual") OpenSource-Basics (as e.g. FreeBasic) which
are already platform-independent, and wouldn't require to run on a "virtualized OS in a box".

Businesses solutions can stay to mainstream top languages and all the thing they have to do is to collaborate with other professionals.
Here the reason of this topic is to initiate a collaboration between non professionals.

I've never seen Visual Basic as a language for "non-professionals only" -
and do not think (Tanner might correct me), that he wanted to encourage only the hobbyists
among the VB-Programmers to "come out of their Boxes".

IMO he was speaking more about "professionally written show-cases for everybody to see",
Code-Repositories which increase the positive perception in the general development-scene,
that the language has value, and that its community has to be taken more seriously -
something like the respect e.g. Lazarus (as a showcase for Pascal) has earned over the last years.

Given the lazarus-example - the best showcase a developer-community can make (for
themselves as well as for others), is to write and manage their own community-driven eco-system,
starting with the compiler - a nice IDE - and powerful library-bindings.

And this is a bit difficult. Especially on two things. First we have to use a version aware solution
and a treatment for some rules that define the scope of the program. Any idea about that?

Not really sure what you mean and what "program" you have in mind.

Olaf

[georgekar]

Olaf,
I said for any a program. I am not a professional programmer, but I think that I am an average one. So my experience maybe is useful. I work on my own language because I like a definition and implementation of a language as a free code. For me programming is not the writing of algorithms as in schools teaching, but to make an application that can run in one at least environment with useful results.
So before I or others contribute to any specific open source application, the first calller has to discuss the scope of that, what it can do and what not. Like a reverse solution, you specify the desired solution, and contributors tries for the best code to fit that solution. That is the way in vbforums the members response to an issue, so the same can be done for any application.
I see the git hub for other programs but I never saw a discussion about the final scope. I think that these facilities are for error checking. Free software in a such aspect is a bad program. Who wish to contribute in a bad program.

[Shaggy Hiker]

Microsoft could axe VB.Net tomorrow and simply tell everyone to move to C#, and I doubt they'd have any meaningful repercussions from it. In fact, since migrating from VB.Net to C# is more straightforward than VB6 to VB.Net ever was, it would likely produce less fallout than the VB6 to VB.Net transition ever did.

This move would not surprise me at all. I've been expecting it for years.

Anyway, maybe my analysis is totally wrong, but I think the VB6 users of 2000 have more in common with the VB.Net users of 2014 than either side would like to believe.

There is one BIG difference that you noted in the first quote. Migrating VB.NET to C# isn't just straightforward, it is automated. In fact, there was talk as far back as 2010 of allowing both languages not just in the same project, but even in the same code page. As it is, there are free migration tools to move to C#. One of the things that kept VB6 users from moving to VB.NET was the fact that they simply couldn't migrate existing projects because the tool that was offered, did a pretty bad job. So, if VB.NET went away, but C# did not, the migration would be only slightly more painful than the migration from VB5 to VB6, or from any version of .NET from 2005 on to any later version of .NET (there were oddities that made migration from 2002 or 2003 to later versions more difficult).

[techgnome]

Free software in a such aspect is a bad program. Who wish to contribute in a bad program.

Just because something is free doesn't make it inherently bad. some of the best and my favorite programs that I use are free. It's because they do what I need them to do. If they were bad, then I wouldn't use them. As a result, these things tend to weed themselves out. then you introduce something like open-source. So if there is some bad code in a program that isn't working right, someone can go in there, fix it, and submit it back. Maybe it works, but still performance isn't quite there... so someone else goes in and updates it, tightening the code even more. That is why people will contribute to a "bad" program. I've done it. I've worked with OS projects before, found deficiencies, submitted the code to fix it and had it rolled in. Sometimes the "bad" code is written out of ignorance (the developer didn't know any better) or sometimes it's a result of a change in some other area.

So to answer your question, me. But it does get weighed against the value of the project to me, as well as the value of the project to the community in general.

-tg

[techgnome]

This move would not surprise me at all. I've been expecting it for years.


There is one BIG difference that you noted in the first quote. Migrating VB.NET to C# isn't just straightforward, it is automated. In fact, there was talk as far back as 2010 of allowing both languages not just in the same project, but even in the same code page. As it is, there are free migration tools to move to C#. One of the things that kept VB6 users from moving to VB.NET was the fact that they simply couldn't migrate existing projects because the tool that was offered, did a pretty bad job. So, if VB.NET went away, but C# did not, the migration would be only slightly more painful than the migration from VB5 to VB6, or from any version of .NET from 2005 on to any later version of .NET (there were oddities that made migration from 2002 or 2003 to later versions more difficult).

If MS were to drop VB.NET... wouldn't bother me one bit. I've had my feet in both C# and VB long enough now I could (for the most part) easily slide into a C# role fairly quickly. I might get slowed down as I have to retrain the muscles to use curly brackets and semi-colons, but I know I can do it. Now if they were to drop .NET completely, that might slow me down even more. But I'll have options: 1) Go into project management (not!) 2) learn a new language as needed, or 3) stay with VB.NET and go into maintenance mode. Just as there are a number of VB6-based apps out there that still need to be maintained, there will be a large portion of .NET apps that will need to be kept up (until the app is updated in what ever neoteric lingua comes up next).

Or, maybe I'll retire and do something else.

-tg

[Tanner_H]

@Shaggy and tg,

In my mind, Roslyn was the death knell for VB.Net. An announcement like that comes out of the project abandonment 101 handbook:

1) Make decision to kill project. Because announcing this outright would make the project community angry, instead announce your intention to open-source the product.
2) Once project is open-sourced, cease all internal work on it, and give an inspiring speech about how you "trust the community to carry on the torch."
3a) If the open-source version succeeds, take full credit. Give speech about "this justifies our decision to open-source it in the first place."
3b) If the open-source version fails, place full blame on the community. Give speech about "this justified our decision to cease internal development in the first place."

I think a lot of people figured that VB.Net absorption into C# was only a matter of time, but Roslyn seems to be a very obvious sign that the time is now.

@Olaf,

Thanks as always for your detailed reply. I remember you mentioning that thread before - I will make sure to review it this time. I am impressed at the thought you have put into this project. (When I hear guys talk about replacing VB with a community version, I usually shake my head and laugh because they obviously haven't thought it through. You are very different in this regard!)

@dilettante,

Thanks for the reply. I don't have much experience with embedded Android, so it's enlightening to hear about your experiences. The many things that hurt Android in the consumer market don't seem to matter much there - interesting!

[Shaggy Hiker]

@Shaggy and tg,

In my mind, Roslyn was the death knell for VB.Net. An announcement like that comes out of the project abandonment 101 handbook:

That bell may be tolling, but Roslyn isn't pulling the rope. After all, that's the compiler and they are stating that it is for C# and VB. Frankly, it's a bit unusual for them to mention VB in the same breath as C#, so that's not what looks likely to kill it off. The fact that the native compilation came first for C# with plans to include VB, seems like a bigger sign.