Visual Basic is Dead!

[Mike]

[Snip]

Good show Timothy. Very good recollection of related computer history.

I think that VB will probably evolve into the programming equivalent of
"English" because it is used more often in reliable communications
regarding programming methods.

+1, BASIC dialect will most likely remain with us for a very long
time. I keep thinking "Maybe" we should switch our embedded server
langager to V8 (Google Javascript dialect used in Chrome), but we use
the basic BASIC dialect for marketing reasons - most people understand it.

However, we have also been moving back and forth and closer towards
interpreted languages, dynamic programming, auto construction and
execution is once again becoming feasible. The Hardware speeds pretty
much flatten out. That has always been the ultimate direction, it
came, it went, and languages like JavaScript and Prototyping methods,
along with other symbolic conceptual methods is bringing back the
basic ideas.

It will be the code (of course, it has to start somewhere), that will
be able to analyze a requirement, need, a "GAP", then code it and
executed it. Half the beauty of the smart IDE is just that,
auto-generation of code that links the different ideas.

On the practical side, The MS VB design team need to focus on the idea
that people have matured and can compress their coding and since
VB.NET does compile to the same footprint as C++/CLR and C#, they
will/have attract many C/C++ developers. Not necessarily to switch,
but to use VB.NET mode. It will be a mistake to believe that just
because the RAD (GUI designing) is now also available for C++ and C#,
that this would be enough to move everyone to C/C++/C#. No, big time
marketing mistake.

--

 

[Axel]

Unless you want to do something useful. In which case the HWNDs, message
dispatch loops, and everything else are right there waiting to bite the
unsuspecting C# programmer.

Well that's what I we read the Petzold for back in the 90s! I remember
porting image processing software from DOS (32bit with DOS4GW) to Win16
to Win32s to Win95/98, remember "thunking" and 32 bit extenders? And
always fighting with the stack limitations - but for visual image
processing there wasn't really much choice but C++ and assembler.

We've come a long way but since then but I recall no problems with a
properly managed message loop, in fact I always thought that was one of
the enjoyable things to debug... When I had to move to VB in my new job
(because nobody there want to support C) I first hated it, but you get
used to most of the limitations - as long as you don't have to deal with
other people's code.

Now its fast forward to post 2008 and luckily our customers prefer C#, I
had no problems with switching to that, found it a lot easier than
dealing with C++ and ATL; definitely don't want to go back to VB. My
favorite feature of C# is tight scoping, to me } means a lot more than
END. Also explicit casting is so much nicer - VB used to often trap one
(especially with DateTime types) by doing oblique type conversions,
often resulting in garbled data.

PeekMessage, anyone?

Axel

 

[Axel]

Unless you want to do something useful. In which case the HWNDs, message
dispatch loops, and everything else are right there waiting to bite the
unsuspecting C# programmer.

Well that's what I we read the Petzold for back in the 90s! I remember
porting image processing software from DOS (32bit with DOS4GW) to Win16
to Win32s to Win95/98, remember "thunking" and 32 bit extenders? And
always fighting with the stack limitations - but for visual image
processing there wasn't really much choice but C++ and assembler. "So
little time, so many pixels."

We've come a long way but since then but I recall no problems with a
properly managed message loop, in fact I always thought that was one of
the enjoyable things to debug... When I had to move to VB in my new job
(because nobody there want to support C) I first hated it, but you get
used to most of the limitations - as long as you don't have to deal with
other people's code.

Now its fast forward to post 2008 and luckily our customers prefer C#, I
had no problems with switching to that, found it a lot easier than
dealing with C++ and ATL; definitely don't want to go back to VB. My
favorite feature of C# is tight scoping, to me } means a lot more than
END. Also explicit casting is so much nicer - VB used to often trap one
(especially with DateTime types) by doing oblique type conversions,
often resulting in garbled data.

PeekMessage, anyone?

Axel

 

[Martin H.]

Hello Axel,

Also explicit casting is so much nicer - VB used to often trap one
(especially with DateTime types) by doing oblique type conversions,
often resulting in garbled data.

You can set VB.NET to strict, so if you cast implicitly you will receive
an error from the compiler.

PeekMessage, anyone?

SYS64738
READY.

I like BASIC dialects better than C dialects as the source code is
easier to read. And with the .NET framework underneath it does not
really matter which language you use as they all target the same framework.

There are quite some things in C# where I really wonder...
For example: Why cant you use variables with a "switch" statement?
In VB.NET you can use variables with "Select Case" statement. Or indexed
properties: A property is nothing but a function. Why can't I use
parameters with it? In my opinion, MS should take the good features of
the VS languages and make them available to the other languages. It
should really make no difference which language you use. But all the
languages have their own set of features which maybe the other languages
don't support (completely - as for case sensitive variables in VB.NET).

Best regards,

Martin

 

[Tom Shelton]

sub main()
for i as integer=1 to 10
console.writeline(i)
next
end sub

No need for all that complicated LINQ stuff.

That wasn't link. ForEach is a method of the List class, has been since 2.0.
I used it one, to illustrate list initialization (vb10 gets this), and the use
of a non value returning lambda.

 

[Tom Shelton]

"Tom Shelton" >> Private a = ""

All day I was hoping that nobody would see that mistake, you are right, and
when I had sent it, I realized that myself too.
But then Tom passes by

You mean something like this?

Sub Main()
Dim newList As New List(Of Integer) From {1, 2, 3, 4, 5, 6, 7, 8, 9,
10}
newList.ForEach(AddressOf Console.WriteLine)
End Sub

No - VB's current implementation does not allow list initialization. That is
VB10 - and I'm not sure of your syntax is exactly right Could be, but I
have to reboot to windows 7 to verify... And I dont' feel like it right now.

 

[Tom Shelton]

Hello Tom,


Please go ahead and convert the following code to C#:

Public Class TestCs
Dim Ar(-1) As String

Public Sub Add(ByVal value As String)
Dim u As Integer = UBound(Ar) + 1
ReDim Preserve Ar(u)
Ar(u) = value
End Sub

Public Property Item(ByVal Index As Integer) As String
Get
Return Ar(Index)
End Get
Set(ByVal value As String)
Ar(Index) = value
End Set
End Property

End Class



You, too.

Martin

Here is a pretty good translation... Nothing difficult there...

public class TestCs
{
private string[] ar;

public void Add(string value)
{
Array.Resize (ref ar, ar.Length + 1)
ar[ar.Length - 1] = value;
}

public string this[int index]
{
get{return ar[index];}
set{ar[index] = value;}
}
}

 

[Tom Shelton]

I think you missed the point, ReDim Preserve does have a direct equivalent
(Array.Resize). It's the indexed property that's more challenging in C#
(you need to return a helper object).

Why would you need a helper object - it's simple index property:

public string this[int index]
{
get{...}
set{...}
}

 

[Cor Ligthert[MVP]]

Tom,

I am disappointed that you don't trust me in this kind of answers,

(-:

It is tested and it is VB'10.

The answer is based on the fact, that I guessed that your question has its
base on the fact that you are not common with the new "From" in VB10 and I
got now even more the idea that I was right.

And then I like it to make these answers, you know?

Cor

 

[Martin H.]

Hello Tom,

Here is a pretty good translation... Nothing difficult there...

Yes, it is pretty good. However, you just index the whole class. If you
replace "this" with a different name - e.g. "TestMe" - it does not work.

Best regards,

Martin

public class TestCs
{
private string[] ar;

public void Add(string value)
{
Array.Resize (ref ar, ar.Length + 1)
ar[ar.Length - 1] = value;
}

public string this[int index]
{
get{return ar[index];}
set{ar[index] = value;}
}
}

 

[Michael J. Ryan]

Believe me, I could have made it far worse. Much more concise than C#
though. Does that make it better? By the way, MUMPS has the most
wonderful use of sparse arrays that I could ever imagine. For all the
advantages that DotNet has, I really miss that. Look at this

Set Person(1, "Address')="1919 Mockingbird Lane"
Set Person(1, "Name")="Smith, John"
Set Person(1,"Phone", "Cell")="917-555-1212"
Set Person(1,"Phone", "Home')="555-555-1111"
Set Person(1,"City")="New York City"

Set PersonXA("Smith","John",1)="" ; this would be the index
pointing to the previous sparse array entry.

Data goes in the subscripts of an array. If the next person entered
doesn't have a cell phone, that array element simply doesn't exist.
Such a cool way to store data.

Well there's always Javascript/JSON...

Person[1] = {
"Address":"1919 Mockingbird Lane",
"Name":"Smith, John",
"Phone":{
"Cell":"917-555-1212",
"Home":"555-555-1111"
},
"City":"New York City"
}

Theres also combine/merge extensions for things like...
Person[2] = Person[2].merge({"City":"Buffalo"});

Ah, I love programming no matter what the language. I even coded in
Cobol and liked that. I didn't know better at the time though. Still,
the level 88s were fun.

Agreed, though I'm a pup by comparison, my first real programming (aside from
macros and dos/bbs scripts) was Javascript in the mid 90's, though I've peaked
at some older stuff, I have to say I like JS and C# most... looking forward to
the changes in C#4 which should make using the DLR really fun. Thinking of
starting a FLOSS Javascript/EcmaScript implementation, including E4X... It
just seems the MS Managed JScript library is getting no love... ben peaking at
the IronPython and IronRuby implementations, and should be an interesting
learning exercise... Without a formal CS background I've never written a
parser; though, I've got a pretty good grasp on the expression trees for DLR
execution.

--
Michael J. Ryan - http://tracker1.info/

.... B5: The bitch of it is that you probably did the right thing. But you did
it in the wrong way. In the inconvenient way. Now you have to pay the penalty
for that. I know it stinks, but that's the way it is.

 

[Michael J. Ryan]

+1, BASIC dialect will most likely remain with us for a very long time.
I keep thinking "Maybe" we should switch our embedded server langager to
V8 (Google Javascript dialect used in Chrome), but we use the basic
BASIC dialect for marketing reasons - most people understand it.

After VS10, you can just use the DLR, and allow for VBx, Managed JScript,
IronRuby & IronPython...

--
Michael J. Ryan - http://tracker1.info/

.... B5: Then what kind of head of security would I be if I let people like me
know things that I'm not supposed to know? I know what I know because I have
to know it. And if I don't have to know it, I don't tell me, and I don't let
anyone else tell me either.

 

[Tom Shelton]

Tom,

I am disappointed that you don't trust me in this kind of answers,

(-:

It's not that i don't trust you, i just like to verify

It is tested and it is VB'10.

Ok. But, since we are talking about the current version of VB being more
mature, then it doesn't really count - since VB10 is not the current version.

The answer is based on the fact, that I guessed that your question has its
base on the fact that you are not common with the new "From" in VB10 and I
got now even more the idea that I was right.

No, it wasn't the from it was the use of the addressof.

 

[Timothy Casey]

[Snip]

Good show Timothy. Very good recollection of related computer history.

I think that VB will probably evolve into the programming equivalent of
"English" because it is used more often in reliable communications
regarding programming methods.

+1, BASIC dialect will most likely remain with us for a very long time. I
keep thinking "Maybe" we should switch our embedded server langager to V8
(Google Javascript dialect used in Chrome), but we use the basic BASIC
dialect for marketing reasons - most people understand it.

However, we have also been moving back and forth and closer towards
interpreted languages, dynamic programming, auto construction and
execution is once again becoming feasible. The Hardware speeds pretty much
flatten out. That has always been the ultimate direction, it came, it
went, and languages like JavaScript and Prototyping methods, along with
other symbolic conceptual methods is bringing back the basic ideas.

[SNIP]

It all comes down to usage. I expect that BASIC will inherit a few of the
technical functions of C (like perhaps the compiler in VC) and I suspect
some aspects of Java are trickling in too. The most successful language is
the one that seems most familiar to everyone. In time, every programming
language you've ever heard of will be killed off by the NLP (Natural
Language Processor). A proper NLP will eliminate the coding step and allow
compilation to proceed directly from the specification. Fluency in English
will one day pay very well because advanced NLP compilers will eventually be
capable of modeling and compiling a working prototype directly from the work
breakdown. Basic NLP will make the difference between Google's word for word
auto-translator (which has been a wonderful cross-cultural ice-breaker) and
the kind of auto-translator that only errs only on idiom and is better at
optical character recognition than a competent human cryptographer. Do you
think the person who solves all the conundrums necessary to invent the NLP
would want to write it in an interpreted language?

Compiled code will always be faster, and this is important when performing
high intensity functions such as near match (executing a number of lines of
code equal to 32 times the number of bytes being searched times the square
of the length of the search string). Even with multiple core processing,
independent drives with separate reading arms for caching, application
access, and data access; getting completion times down to milliseconds could
prove a challenge over 150Mb of random length records (300-600 Mb in Unicode
depending on whether you use 16 or 32 bit and if you are talking about
formatted documents this equates to 250, 500, or 1000 Mb depending on
whether you are encoding 150mb unformatted ASCII in formatted; UTF-8,
UTF-16, or UTF-32). Whether the code is interpreted or compiled could spell
the difference between comfortable use and product unmerchantability.

When programmers go independent, the first thing they look for is a compiler
in their language. No-one making a living in shareware wants their source
code cut and paste into someone-else's application - even if it is simply an
adaption of well known techniques into something new with no real trade
secrets (eg. most content managers). When ISVs use interpreters it is the
original developer that always loses out because all the work and investment
is made by the original developer - whereas the reverse engineers get a
finished product they can license in their own names for next to nothing.
Only large corporations such as Honeywell can afford to have investigators
track hallmarks and pursue a legal remedy for such violations of copyright.
It's never so simple in compiled object code. This need to keep one's code
out of the open source domain is what makes third party .NET compilers such
as Dotnet Reactor so popular, and why interpreted code is always very bad
news for ISVs (Independent Software Vendors: people who develop, market, and
sell their own products as finished packages - eg. shareware vendors).

Interpreters are great if you want to write in-house or open source
products. However, interpreters make it cheaper to violate copyright and
vastly more expensive to protect copyright of commercial software directly
exposed to the open market. So if you're in business for yourself, and you
haven't signed away your right to own intellectual property, compilers are
the cheapest way to make reverse engineering more expensive.

 

[Mike]

"Visual Basic Soul is in our of us"...

What does that mean...?

Oops

"Visual Basic Soul is in ALL of us"...

 

[Mike]

It all comes down to usage. I expect that BASIC will inherit a few of
the technical functions of C (like perhaps the compiler in VC) and I
suspect some aspects of Java are trickling in too.

Hasn't it already? Prototyping is currently the hottest direction
today and people familiar with it see it employed in .NET languages
and more so in coming MS coming work. There is no doubt Anders is
incorporated Javascript prototyping ideas into future .NET plans, but
also with a more declarative approach as well.

The most successful
language is the one that seems most familiar to everyone. In time, every
programming language you've ever heard of will be killed off by the NLP
(Natural Language Processor). A proper NLP will eliminate the coding
step and allow compilation to proceed directly from the specification.
Fluency in English will one day pay very well because advanced NLP
compilers will eventually be capable of modeling and compiling a working
prototype directly from the work breakdown.

Why didn't Prolog take off? NLP has its place. Why just english? I
would think globalization will raise a barrier higher toward this long
time endeavor. IMO, symbolic languages will probably get more play.
Component engineering is a model of this, components becoming symbols
that have a "Snapping" (key/receptor) property to it.

Do you think
the person who solves all the conundrums necessary to invent the NLP
would want to write it in an interpreted language?

NLP implies dynamic "automatron" accumulation and generation of
knowledge old and new combined with query dissemination techniques.
It may use fuzzy logic, neuron networks. In general, such systems
required KB Engineers and/or Experts engineers to establish the core
and spark to get the engine running.

Its really a whole different set of applications.

Whether the
code is interpreted or compiled could spell the difference between
comfortable use and product unmerchantability.

Sure, it all depends. A big direction in the application server market
is to offer embedded programming methods, i.e. server-side scripting,
using JIT and/or p-code. ASPX is, but not exclusive, example of that.
Our own application server product has "net programming" as its name
sake "Wildcat! Interactive Net server" with multi-language API, p-code
compilers, JIT dynamic programming, interpreted scripting components
of the framework. But it took a compiler to create it.

When programmers go independent, the first thing they look for is a
compiler in their language.

Sure to protect their asset.

Interpreters are great if you want to write in-house or open source
products.

It depends in how its applied. But sure, the point is solid.

See ya.

--

 

[Mike]

Actually, if you've taught Prolog -- as I have -- you quickly realize
that it isn't just "write down the specification and it executes." With
Prolog no less than with other languages, you have to think about how
the execution will proceed. Lots of things come out a lot more concise
in Prolog than in other languages. I hope it will go on to achieve
wider use; I think one of the key needs is more interoperability with
other languages, so that you could (for instance) code the GUI in C# and
do the computing in Prolog.

You seem to be (Prof and author) I exchanged emails with regarding bad
coding and ethical training at the earliest age about 15 years ago?
Different Michael Covington?

I agree, didn't teach it, but applied many AI languages including
Prolog for the development of Expert systems during my days at
Westinghouse. I also attributed languages like APL to mold my
thinking process understanding how many concepts work in concert and
how data is manipulated mentally. It helped me to quickly apply other
languages as well.

But AI and natural languages processing languages have a long history
and pretty much have their place. I guess in the past, overhead and
performance was a factor, so its possible they would be more
applicable today. In the area of intelligence learning,
gathering/searching, the question is when is most needed. Google would
see a common example where it might apply, but their methods is
probably finely tune for fast classification and query dissemination.
One might thing that is ideally the situation. On the other hand, you
have marketing pressures. i.e. google will yield more than what you
actually ask for, including near hits as well (you have to use he
advance searching to restrict it).

Finally, use, I think there should be more convergence of difference
languages. This is more proof of the interpretive, dynamic and JIT
direction affordable by hardware power today. MS seems to be heading
in the right direction. Whether its something most people will use,
thats probably will be answer much later.

I think everyone (most people) becomes an "expert" in its own ways,
and what they believe once as "better," easier and natural for them,
inevitably becomes redundant and changes in time for them.

So whats correct, better or good for us or everyone will probably
always be a subjective concept.

If you think about it, the method of programming today - typing a
keyboard is really prehistoric and slow. Voice-based programming
"should" the ultimate goal one would think.

- NEW FORM PLEASE
- ADD A VERTICAL SPLIT PANEL, DOCK FULL PLEASE
- ADD TREE VIEW IN LEFT SIDE
- ADD REPORT VIEW IN RIGHT SIDE
- SAVE AS STANDARD TREE & REPORT SPLIT VIEW FORM

The next time, you can just say:

- NEW STANDARD TREE & REPORT SPLIT VIEW FORM

However, I think voice based designs have a degrading factor, probably
in the area of recall. Will you recall the saved phrase to voice it
out over time? I guess the system will incorporate a solution,

- Show me all forms.

Just consider how voice based technical support are getting better and
better in steering callers to a final resolution or point where it
needs to transfer to a human.

Then again, I find that annoying today, and TALK programming can be
deemed annoying by co-workers. For night owls working at home, the
sleeping wife might throw her cell phone at you. "SHUT UP! YOU ARE
GOING TO WAKE UP LITTLE BILL!"

So maybe the final evolution is Thought Programing

--

 

[Jai Singh]

This is sort of an add in to all of the replies in this sub-thread.

First a question to Ben... which managed features does C# provide for
accessing hWnds, message pumps, etc., that VB.NET does not currently support?
Or, are these really benefits provided by inline unmanaged code? (thnx in
advance if you are still following this post)

In regards to all the referencing of image processing C and PeekMessage... I
agree that VB programmers (VB6 and VB.NET) that do not have a firm grasp of
Win32 app dev in C will essentially make less than optimal decisions in many
situations (but the same is true for C# programmers). And, by defending VB,
I am in no way saying that VB, historically, was "powerful" in the sense that
it could handle games, graphics, or scientific programming. I only meant
that VB was, historically, "powerful", because of what it did for the
programmer behind the scenes. And, really, message pump mis-handling in VB6,
especially via DoEvents, led to a lot of problems with no apparent,
straightforward, easy answers.

But, before digressing further my point is simply... in todays world many C#
programmers are not historical Win32 / C programmers and thus are essentially
VB programmers with {} wrapped around their heads. Yet, there is a lot of
posturing by these programmers in the lowly world of the 'business
programmer' - where they believe that the utilization of 'C' within "C#"
allocates them to some lower level / higher order memory register.

And, in my limited experience, many, many VC++ programmers that I have run
into are less than expert in the complexity within which they work. It takes
so long to become proficient in VC++ or C / Win32 programming that many are
lost in the details as they struggle to keep up with the ever changing world
around them.

Thanks for posting!

 

[vanderghast]

(...)

Yet, to interject, C# is nothing but VB (in spirit and form (pun
intended)).
It took the spirit and purpose of VB and wrapped it in {}. That's all.

(...)


Missing an important point, imho: the memory management is not the same.
The framework makes memory management trivial, stupid. Before it, only VB6
was trivial with COM (who want write COM with C++? ) but even in VB6, the
COM reference count is not without problem.

C# is far more than just not a matter of adding curly to VB6!


Vanderghast, Access MVP

 

[Ben Voigt [C++ MVP]]

I think you missed the point, ReDim Preserve does have a direct
equivalent
(Array.Resize). It's the indexed property that's more challenging in C#
(you need to return a helper object).

Why would you need a helper object - it's simple index property:

public string this[int index]
{
get{...}
set{...}
}

You've lost the property name. C# indexes objects, not properties. So you
need the property to return a helper object that is in turn indexed (using
the code you showed) to achieve the syntax of a property with an index
argument.

--
Tom Shelton

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4178 (20090622) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4178 (20090622) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com