 |
|
 |
|
On Tue, 16 Jun 2009 21:30:08 +0200, "Cor Ligthert[MVP]" <...@planet.nl
The article is from 2007 while it state by instance that there was no Linq
in VB, which is completely wrong.
Linq was developed in different tastes for C#2 by instance DLink and
whatever fancy name.
The Linq that was used for C#3 was however the same as in VB9
And in that way the article goes on, it looks to nothing.
By the way, many C# developers complain that there are so few (correct)
samples on Internet, they only find VB
Cor
|
|
 |
|
 |
|
|
|
|
On Wed, 17 Jun 2009 06:44:54 +1000, "Harry" <...@ffapaysmart.com.au
"Marcus" <...@sunce.iskon.hr...
I don't think that is correct. In fact, MS themselves admit to about a 50/50
percent spread between C# and VB. In a recent video I watched, MS claimed
that they were directing future VS studio development to making features in
both languages equal and were diverting from adding even more bells and
whistles.
It is a good idea, however, to become conversant in both languages. They are
not that different, anyway,
Cheers
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 10:45:35 +0200, Ertugrul Söylemez <...@ertes.de
"Marcus" <...@imperator.hr
It won't, since both languages have the same features. However, C# is
usually much easier to deal with and much less to write, especially when
it comes to advanced features like delegates, lambdas, LINQ, etc.
Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife http://blog.ertes.de/
|
|
|
|
|
|
|
|
|
On Tue, 16 Jun 2009 12:06:01 -0700, Tim <...@discussions.microsoft.com
I did not get this impression from reading the article. This is just one
person's opinion. I believe Microsoft has given the axe to J sharp, but I
don't believe they will ever do this to VB.Net. I do not agree with the
author on saying C# is for helping Java programmers transition over to .Net;
that is what J# was for.
From what I understand, it doesn't really matter what language you code
in, it all compiles down to the same MSIL.
I think VB.Net will be around for some time.
[Tim]
>
|
|
|
|
|
|
|
|
|
On Tue, 16 Jun 2009 12:15:06 -0700 (PDT), Joe Cool <...@live.com
On Jun 16, 3:06 pm, Tim <...@discussions.microsoft.com
I agree. While the LSE and Intellisense works differently for VB than
it does for C#, and there are some namespaces available in VB that
aren't available in C# (and vice version, I assume), it is my
impression that both are merely wrappers for the .NET Framework, which
really does all the work.
> > about this, is VB dead?
|
|
|
|
|
|
|
|
|
On Tue, 16 Jun 2009 16:33:48 -0400, "Neb Okla" <...@hotmail.com
If you have to code in VB, make sure you charge by the line...
VB Property:
Private newPropertyValue As String
Public Property NewProperty() As String
Get
Return newPropertyValue
End Get
Set(ByVal value As String)
newPropertyValue = value
End Set
End Property
C# Property:
private int myVar;
public int MyProperty {
get{ return myVar; }
set{ myVar = value; }
}
It adds up.
"Tim" <...@microsoft.com...
|
|
|
|
|
|
|
|
|
On Tue, 16 Jun 2009 23:05:51 +0100, rossum <...@coldmail.com
On Tue, 16 Jun 2009 16:33:48 -0400, "Neb Okla" <...@hotmail.comwrote:
private int myVar;
public int MyProperty
{
get
{
return myVar;
}
set
{
myVar = value;
}
}
:)
rossum
|
|
|
|
|
|
|
|
|
On Tue, 16 Jun 2009 18:38:42 -0500, "Fernando A. Gómez F." <...@gmail.com
However, the VB version can't be shortened... can it?
--
Fernando Gómez
http://www.fermasmas.com
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 15:41:22 +0900, "Abubakar" <...@nowhere.com
ummm Ladies and Gentlemen, this is not a newsgroup for c# vs vb discussions
:)
""Fernando A. G F."" <...@TK2MSFTNGP04.phx.gbl...
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 09:48:32 -0500, "Fernando A. Gómez F." <...@gmail.com
But is a newsgroup for C# discussions, is it not? If not, I beg you a
pardon... :)
--
Fernando Gómez
http://www.fermasmas.com
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 14:43:11 +0200, "Herfried K. Wagner [MVP]" <...@gmx.at
""Fernando A. G F."" <...@gmail.com
I wonder why there should be the possibilty to shorten it. The way the
property is defined in VB allows for easy extension by adding new statements
to each accessor's body.
If I want to see the signatures only, I use the class view or object browser
instead.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/ V B <URL:http://dotnet.mvps.org/dotnet/faqs/
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 10:26:52 -0500, "Fernando A. Gómez F." <...@gmail.com
Nobody said there should be one... IIUC, Neb said that VB was too
verbose (which I agree, but I guess that it is a matter of getting used
to). Rossum's reply implied that C# was also too verbose, just by adding
whitespace. The point of my post was to state that C# does not have to
be verbose, but that VB had to be verbose.
If only because that was one of the original primary design goals for
the language.
Best regards.
--
Fernando Gómez
http://www.fermasmas.com
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 09:30:57 -0400, "vanderghast" <vanderghast@com
Probably doable too in VbNet, the line:
public int WhatIsThat { get; set; }
***completely*** defines a perfectly working read/write propery, with
anonymous variable 'sustaining it', in C#, since version 3.5 of the
framework (if not before). It is not 'just' the signature. I don't see it
often used, though, in comparison with the long version., which uses an
explicit declaration of the local variable (the one capturing the 'value'
for the set definition and returning what get expect to return), and an
explicit statement for each get and set access.
Vanderghast, Access MVP
"Herfried K. Wagner [MVP]" <...@TK2MSFTNGP05.phx.gbl...
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 17:40:23 +0200, "Herfried K. Wagner [MVP]" <...@gmx.at
"vanderghast" <vanderghast@com
Well, I never said that it's the signature only. I just mentioned that I
prefer the long version because it's easier to extend. The long version's
code skeleton is typically generated by a code snippet, including the
backing field.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/ V B <URL:http://dotnet.mvps.org/dotnet/faqs/
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 10:09:20 -0400, "mayayana" <...@rcXXn.com
The whole of .Net is aimed at Java programmers. (And at
getting 3rd-party programmers out of the Windows system.)
From "the horse's mouth" (Mark Russinovich):
"A few years ago Microsoft embarked on an anti-Java campaign called .NET,
spinning .NET as a revolutionary technology (while failing to explain that
it's really Microsoft's own implementation of the JVM concept with new
languages layered on top of it)."
http://blogs.technet.com/markrussinovich/archive/2005/04/16/the-coming-net-w
orld-i-m-scared.aspx
But people are writing Windows software with a 200 MB
dependency because they think it's "what Microsoft wants"!
Microsoft wants whatever makes money. That may be something
different tomorrow than it is today. Microsoft is not a guru. It's a
for-profit corporation.
If people don't know any better than to write Windows "desktop"
software with a 200 MB dependency, then what difference does it
make what language they're using?
The competition between languages will always be there.
Some C-type people look down on basic-type languages
as being too verbose. Some Perl people look down on everyone
else for the same reason. :) So what? Can't people think for
themselves a bit rather than trying to work out "the truth"
by reading junk filler pieces on blogs? The linked article is
written by someone with high school writing abilities who fails
to express any clear thoughts. It's just a "tossed salad" of
hearsay and wiseacreing.
------------ Looking at a few samples -------------------
* most really cool pieces seem to be in C# and not VB.Net.*
"Cool"? What's "cool" other than what does the job?
* The ones [job applicants] that strike me as really "senior" mostly
trend towards C# and not VB.Net. Sure, it could be a coincidence,
but it might not be. *
Translation: "C# people seem to be more "cool", but then
again my judgment can't be trusted."
* For the time being, VB.Net is my .Net language of choice; ...
VB.Net is an easy way to tap into the .Net Framework ....
So, C# it is. Am I thrilled? Not really. I like what they are doing with
C# but not C# itself. But I feel like I have hit the limits of VB.Net.
*
He's sticking with VB.Net, and VB.Net is good, but now he
apparently has to switch to C#, but he doesn't like C#, but VB.Net
is not so good...
Is your head spinning yet? Mine is.
Most of the "article" is just one long string of popular cliches. (It's
usually a good bet that people are going to prattle cliches when they
start sentences with "Sure, ..." Use of the word "cool" is another
dependable indicator. "Cool", after all, is really just a "cool"
synonym for "fashionable".)
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 10:52:49 -0500, "Ben Voigt [C++ MVP]" <...@newsgroup.nospam
I translate this differently. .NET is (still) new. Senior people used
something before .NET, mostly C++ or Java. People who knew C++ or Java
before starting .NET were more comfortable with C#, people who knew Classic
VB/VBA were more comfortable with VB.NET
Once .NET reaches 10 years old this will no longer be true of course, and
we'll know longer be able to identify the bogus job postings by the way they
require "10 years experience with C#".
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 19:01:36 +0100, rossum <...@coldmail.com
On Wed, 17 Jun 2009 10:09:20 -0400, "mayayana" <...@rcXXn.comwrote:
Some Perl people need to have a look at APL.
rossum
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 08:29:38 -0700 (PDT), Branco <...@gmail.com
<snip
Both of then fantastic goals. If Sun and friends hadn't sued MS years
ago, we'd all have to program in an MS variation of Java today.
Honestly, I can read Java, but I hate programming in it. =))
And having 3rd parties cast out off the Windows API is great,
considering the amount of trouble bad usage of said API and COM has
brought to us all in the years before .Net.
The "dependency" part is really relative, don't you aggree? Ok, .Net,
if not installed in a system, will take some minutes to download
(according to Brazilian metrics =)) -- last time I checked the full
3.0 redist is around 50MB. Once it's installed, I have *no* idea how
much disk space/memory it will amount for. **But** once it is
installed (and it will be), it becomes part of the system (that is,
zero dependency =))). So, what are we talking about here? Download
time? Space in a setup CD? These are, usually, non-issues.
If for dependency you mean the actuall labraries each .Net app depends
upon, well, by this metric most native Windows app has a *huge*
dependency then (on all the native windows dll's that must be loaded
for the application to run). My point is: once the required code is
part of the system, dependency becomes zero.
Best regards,
Branco.
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 15:04:43 +1000, "Timothy Casey" <...@timothycasey.info
"Branco" <...@w3g2000yqf.googlegroups.com...
[SNIP]
No, it was mostly hackers and malware that caused the most persistent
problems that weren't already caused by defects in the API and COM
themselves - and nearly all of the malware causing these problems got in
due to slack security settings that allowed the JavaScript, VBscript, &
ActiveX autoloaders to execute without the user's knowledge or consent.
As for buggy software, no serious problems here. Back in 1999, I surveyed
nearly 500 software packages and less than twenty functioned substantially
as documented. Most didn't function at all, many were pretendware (GUI with
no other object code), and about 1 in 5 blue screened windows or crashed
Windows altogether if they were set to run on startup. The Windows 98SE
operating system that bore the full fury of these tests still runs to this
day, and is more stable than some WinXP and Vista systems.
I might add that third party software is much improved. Fully half of it
actually works these days and pretendware is much rarer than it was in the
90's. Nonetheless if buggy software caused the amount of grief you mention,
that clunky old Win98SE system of mine would be reduced to a smoking pile of
blue-screens by now. This is not the case.
Without third parties in the API, you have no security packages other than
the few malware removal tools Microsoft have to offer. If it were not for
third party packages that police the security settings in the registry (eg.
Drawbridge), it would be impossible to keep the script kiddies out of any
computer system, because the door that is so commercially favourable SaaS is
the same hole that modern "hackers" use to gain access in more than 99% of
modern security exploits.
--
Timothy Casey - Email: 5th-...@timothycasey.info
Software: http://software-1011.com; Scientific IQ Test, Web Menus, Security
http://web-design-1011.com http://speed-reading-comprehension.com
Science & Geology: http://geologist-1011.com; http://geologist-1011.net
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 13:17:55 -0700 (PDT), Branco <...@gmail.com
Yes, but, then, not exactly (IMHO). It's true that the lack of
security in the OS allowed for a really fun ride for hackers, script
kiddies and their neighbour's dog, but the political development of
the Windows API, the different models it had (has) to support to
favour legacy compatibility, etc, well, it seems to me that that
allowed for a lot of damage also, due to friendly fire. I seem to
remember a nasty bug in the GetWindowText API caused by some clever
programmers using the window caption to pass (binary) data around
between running instances of their apps. Programmers (from big
companies like Adobe) went through hoops and jumps and twists to force
Windows behave according to their plans and then there were the
counter hoops and anti-jumps placed by MS to revert Windows back to
its (uh...) "correct" behavior (sorry for not providing factual
references, these are stories I remember reading in my long gone --
stolen, mind you -- MSDN Magazine collection *before* it was branded
"MSDN Magazine").
That doesn't surprise me a bit, I had my fair share of non-working
commercial applications or the ones that subverted the system in such
a way as to drive it (and me) nuts.
"Fully half of it actually works" is some statement! =)) It seems we
actually agree. Don't you think that having those bad programmers
working in a more "secure", "rich", "easier to learn" and "accessible"
environment (.Net) may produce better applications? In the meanwhile,
nothing would stop the real bad *ass* programmers from giving us
Proccess Explorer and similar (unmanaged, native, API based, etc)
shining apps.
Here in Brazil we have the expresion "Boi de piranha". It's how you
call the cow that is sent alone as bait to cross the river downstream
so it attracts all the piranhas (really, really bad fish) and allows
for the rest of the cattle to cross safelly upstream. To me .Net is a
boi de piranha for the general programmer. I consider myself a
reasonable to good programmer and I notice that I write better .Net
apps than I write "API based" apps (damn, I just realized I'm a
piranha!)
Best regards,
Branco.
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 09:27:18 -0400, "mayayana" <...@rcXXn.com
And having 3rd parties cast out off the Windows API is great,
considering the amount of trouble bad usage of said API and COM has
brought to us all in the years before .Net.
I daresay that whole idea of "get the clowns
out of the API" is a good example of a cliche
that's been spread around, and that people have
picked up without really thinking about it. As the
marketing experts know, it's very easy to get
people to accept a premise by simply repeating
it over and over.
When your anti-API statement is scrutinized it's really
a somewhat illogical thing for a programmer to say. It
amounts to saying, "I'm happy to be put into a sandbox
where I can't access the system if that helps to block
other people who don't know what they're doing."
Beyond that there's a profound implication in
the changes brought by .Net's sandbox. The end result
of shutting off the real API is the transformation
of Windows from a platform to a service. The
security/stability issue is a red herring. (Remember,
the original idea was that an OS is a "platform"
that supports software by interfacing with the
hardware. It's important to distinguish between
needed security improvements on the one hand,
and radical redefiniton of the product on the other.)
...And speaking of cliches, what's with all the
badmouthing of COM? I don't mean just what you
said. I've heard derision of COM for years. But I don't
find any problems with it. It's been great for scripting.
And Windows itself is still extensively COM-oriented,
while being almost entirely free of .Net.
The "dependency" part is really relative, don't you aggree?
Ultimately, sure. But a basic XP system is about 1GB.
.Net2 is about 88 MB unpacked, by my measure. As I
understand it, .Net3 is over 200 MB. It's adding some
25% to the OS. So where do you draw the line with
what's "relative"? Would you install a 2 MB Java program
if you knew it was going to require a 200-300MB VM?
I wouldn't.
We're talking here about whether .Net is a sensible
choice for desktop software -- not just whether some
people will be agreeable to having the .Net runtime
installed. There are issues of bloat, security, possible
instability, etc. It's not just a question of how long it
takes to download the package.
If the "relative" bloat of the runtime were not an issue
then .Net installers wouldn't be designed to sneak out
and download the runtime without even asking the person
installing the software.
Then there's also the general unsuitability in the design
of .Net for Windows software. If you read Mark Russinovich's
piece from the link you'll see that his whole point is the same
point that I'm making. (And I suspect that most of the people
reading this also agree, and are probably using .Net not
for Windows software but rather are using it where
they might have formerly used Java -- server-side or for
producing corporate intranet web services.)
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 15:01:41 -0700 (PDT), Branco <...@gmail.com
mayayana wrote (responding to a post of mine):
Me:
Mayayana:
It's certainly a coincidence that this is repeated over and over and
also a cliché, besides being my educated opinion =)))
Well, yes, nicelly put. Of course, nothing is really restraining me
from actually using tools that allowed me access to the API. So, yes,
its a choice I make and I hope others make too, so the guys who "don't
know what they're doing" (API-wise) can come to this bandwagon and
know a little better =D
I don't see the problem in Windows turning (evolving?) from platform
to service. That's actually what Windows -- and it's API -- allways
longed to be (IMHO). This role of providing a thin abstraction layer
between application and hardware was never played very well by Windows
since its inception, and I doubt it defines this OS as we know it.
Yeah, I see your point, but don't get me wrong: I'm not bad mouthing
COM. My opinion is that COM was a fantastic breakthrough in
application interoperability, a really visionary and radical approach
(yes, there was CORBA, but COM actually *existed*, contrary to CORBA).
Trying to learn COM made me a better programmer, really =))
But COM for the masses had an intrinsic complexity that no tool
(besides VB) would easily circumvent (C++ smart pointers were
"discovered" too late in the game when there was a lot of damage
already done by programmers forgetting to call AddRef/Release
appropriately). Thus there were lots of badly written COM application
(or so the legend says). I remember that .Net exploded on our faces
just when COM was preparing to turn into COM+. For a few months MS' PR
was "COM+ this" and "COM+ that", "COM+ is the wave of the future", and
then *boom* there was .Net. It really seemed to me that a political
tour de force had ensued inside Microsoft and this new platform (lol
sorry, "service") got the upper hand, maybe because it provided
answers to COM "faillures" that outshone COM's benefits (DLL hell,
registry bloat, referene counting, anyone?)
The merit of .Net, in my opinion, is to provide this really rich and
*likable* environment (for a programmer such as myself) while it
allows the OS to continue its regular existence: as you notice,
Windows is vastly COM-based still.
I'd install Vista, which would change the contribution of disk usage
from the .Net libraries to mere 2% of the OS =)))
I'm just kidding of course. Or maybe not. Vista takes up 10GB of space
in a regular install, if I'm not mistaken. What drives us to install
such a monster? Even the slim and fat-free (yeah, right) XP seems huge
if we compare its 1GB (I'm trusting your numbers, here) to, say, a
functional Linux install that fits what? 100 MB? And then came World
of Warcraft. Damn, that thing alone is 15GB!!
I'm using VB.Net to write corporate apps that are used in a daily
base. It replaced both VB6 and Delphi as the default development
platforms here, and suffocated to death (I really like this image,
considering the people involved) a movevement that wanted to migrate
all our development to Java. =))
What I see is: .Net is kind of fresh still, and it allowed a freedom
in development that really shines if compared to the alternatives. Is
there bloat? yeps, but this is good fat, not bad fat, and comes mostly
from new services and tools mayde available to you. Is there
instability? uh, I really hardly see it (there was a 3rd party app
once that failed to install with no elucidative message. I installed
the 3.0 redist -- the machine had only 2.0 -- and everything worked
without a glitch). Lack of security? In C# maybe. I suppose it's
easier to write a faulty app (security-wise) in C, unmanaged C++ or
unmanaged C# than to write a faulty managed .Net app (I may be wrong,
of course, we VB programmers once had a history of circumventing the
system).
Best regards,
Branco.
|
|
|
|
|
|
|
|
|
On Fri, 19 Jun 2009 08:44:31 -0700, "Bill Yanaire" <...@yanaire.com
Does that mean my VB applications will stop working?
HA HA HA HA
"Marcus" <...@sunce.iskon.hr...
|
|
|
|
|
|
|
|
|
On Fri, 19 Jun 2009 09:07:01 -0700, Jai Singh <...@discussions.microsoft.com
Per the decades old flame war whose smoke and flame still linger eternal in
our hearts and minds...
The reality is that no matter what the "reality" is or is not... VB, by its
very name, has always and will always, apparently, suffer from SEMANTIC
Discrimination, based solely upon its lowly, debased name... which no longer
adheres to its type descriptor.
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. C#
is not a powerful, dangerous, low level language (save for unmanaged code
segments) - it's a nice, highly abstract language that is powerful because of
its abstraction (like VB 6 was) and that is a million miles away from message
pumps, unmanaged pointers, and hwnd of C based windows development.
The .NET Framework was a MAJOR advancement for VB and for VC++ programmers
who really wanted a simpler, VB like world to develop in... and wanted the
incredible real world gains that that provides.
VIVA LA GUERRA!
>
|
|
|
|
|
|
|
|
|
On Sat, 20 Jun 2009 02:33:17 -0400, Mike <...@unknown.tv
You have to admit, VB/NET people can certainly hold their own. They
know their place, enjoy it and don't let anyone tell them otherwise. :-)
I was once in a $40M project with 36 or so people during a recession
where many engineers were transferred into the C/C++ OS/2 software
project to give them work. They struggled big time with C/C++ and
OS/2 GUI slowing the project with lots of newbie C/C++ bad coding and
just a terrible time in writing GUI programs. Then something
incredible happen - Microsoft came out with a killer app called Visual
Basic, along with Windows 3.0, MS split with IBM, dumped OS/2 and
because of VB, the project was reduce $15M with 20 people, many
overpaid C/C++ OS/2 consultant were let go, the engineers prospered,
RAD, component engineering and the project was completed. Never
forget that one (I helped decide the switch). :-)
--
|
|
|
|
|
|
|
|
|
On Fri, 19 Jun 2009 12:43:28 -0500, "Ben Voigt [C++ MVP]" <...@newsgroup.nospam
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.
|
|
|
|
|
|
|
|
|
On Sat, 20 Jun 2009 21:39:25 +0100, Axel <...@pe.com
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
|
|
|
|
|
|
|
|
|
On Sat, 20 Jun 2009 21:40:21 +0100, Axel <...@pe.com
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
|
|
|
|
|
|
|
|
|
On Sat, 20 Jun 2009 23:47:25 +0200, "Martin H." <...@gmx.net
Hello Axel,
You can set VB.NET to strict, so if you cast implicitly you will receive
an error from the compiler.
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
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 06:08:01 -0700, Jai Singh <...@discussions.microsoft.com
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!
>
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 10:04:36 -0400, "vanderghast" <vanderghast@com
"Jai Singh" <...@microsoft.com...
(...)
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
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 12:29:01 -0700, Jai Singh <...@discussions.microsoft.com
I did not mean to imply that C# was VB 6 with some sugary syntax overtop.
By 'spirit' I was trying to convey that, in a broad, general sense, C# and
the .NET framework in general, adopted the sort of RAD, abstracted, IDE
approach that VB 6 made so ubiquitous.
>
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 15:17:31 -0500, Bill McCormick <...@community.nospam
I'd say C# and VB.NET are more like Delphi than VB6. Don't they also share a
common developer?
|
|
|
|
|
|
|
|
|
On Tue, 23 Jun 2009 07:41:04 -0700, Jai Singh <...@discussions.microsoft.com
I agree and it only furthers my point. Either way... C# is much closer to
those platforms, in a sense, than to C.
>
|
|
|
|
|
|
|
|
|
On Tue, 16 Jun 2009 21:55:13 +0100, "nak" <...@a.com
pfft! You would not believe how many new articles pop up a year stating
that.
And more often than not they are written by self righteous C# developers who
think it is a "better" language.
Has Harry rightly said above, Microsoft are improving development of both C#
and VB.NET to the extent that both languages will receive new features at
the same time. It's all horses for courses really, I write in both C# and
VB.NET regularly, and personally I prefer VB.NET.
So nope... VB.NET is far from being dead.
"Marcus" <...@sunce.iskon.hr...
>
|
|
|
|
|
|
|
|
|
On Tue, 16 Jun 2009 16:19:59 -0500, "Fernando A. Gómez F." <...@gmail.com
Finally, they've taken the blame out of us, C++ers... LOL
VB6 completely sucked, but the .NET versions kinda improved the language
--as required by the CLS. Nowadays I don't like VB because it is very
verbose (see Okla's post above), but that's the only thing I can think
about.
But I agree that it is far from dead.
A new member to the family: F#. AFAIK it will be a fully supported
language in VS10. Let's see how it goes.
Regards.
--
Fernando Gómez
http://www.fermasmas.com
|
|
|
|
|
|
|
|
|
On Tue, 16 Jun 2009 20:57:35 -0600, "Michael D. Ober" <...@.alum.mit.edu.nospam.
""Fernando A. G F."" <...@TK2MSFTNGP03.phx.gbl...
Sometimes the verbosity of VB is good - other times it's not. However, the
one feature I really like in VB is the declarative syntax for event
handlers. Given that winforms are created as partial classes, having the
event handlers declared in the user part of the class and not hidden in the
designer.vb file is really nice. You don't have to go hunting for your
event handlers. The other thing I like, and this is an IDE issue only so C#
could also get it is the IDE feature that creates the interface handlers. I
can never remember the actual interface handler design templates.
Mike Ober.
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 07:49:58 -0700, Tom Shelton <...@comcastXXXXXXX.net
On 2009-06-17, Michael D. Ober <obermd
VB is what it is, but the declarative syntax is fine until you want to add the
same event handler to multiple events, and then it becomes cumbersome really
quickly.
C# has been doing that for a long time. In a cooler way since C#'s IDE
experince is definately better overall.
--
Tom Shelton
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 09:18:37 -0400, dgk <...@somewhere.com
On Tue, 16 Jun 2009 16:19:59 -0500, "Fernando A. Gómez F."
<...@gmail.com
I love lines like that. I wrote several apps in VB6 (for a former
employer) that are running fine today. I know because I still play
tennis with the old company once or twice a summer. They do exactly
what they were supposed to do and never crash and never leak memory.
I once wrote a voice mail system in VB3 for a 12 step group that had
no money. It ran, 24 hours a day, 7 days a week, on a 40 mhz 386
system, no UPS, for 15 years. It used a third party tool called Visual
Voice from Stylus Innovations.
I remember that it took me about two hours to figure out how VV
worked, and about two weeks to write the app. I recently was asked to
do something similar, but the brilliantly simple Visual Voice is no
longer available. I investigated somethings offering the same TAPI
functionality with DotNet. Due to the wonderful "object oriented"
design, it is now much, much more complicated. There's a Phone object,
and a Call object, and oh, so much more. And, the cheaper version
doesn't allow you to issue a flash, so you can't do three-way calling
(that's how the old app would patch through to a volunteer).
The learning curve was staggering because the complexity was off the
charts. All to do the same stuff as VV did.
I work in DotNet, and have since version 1, so I'm well used to object
oriented technology. But it isn't always better and this was a clear
example to me.
I always laughed at guys like you, bemoaning how VB wasn't a real
language because it had a runtime. I guess C# isn't a real language
because it has this big runtime called DotNet.
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 10:25:26 -0500, "Fernando A. Gómez F." <...@gmail.com
So did I. I guess they still run, they did their purpose quite well. VB
had its market share, and it was designed for a specific purpose. In
particular, we used to create the front end in VB and back end
components in C++ with COM.
Perhaps it was a bad design. At any rate, I agree that OO is not always
the better. Each paradigm has to be chosen according to the design goals
of the application involved.
Please, re-read my post. I never said it wasn't a real language, that
was your assumption. It was designed for specific tasks and under
specific conditions, as happens with any other language. The thing is,
it had all these hidden features and hacks that made the language
unclean and error-prone. Its paradigm was some kind of hybrid between
structured and OO, yet it didn't allowed truly OO design.
You can write apps with any language, and certainly each project must
choose the proper language and platform according to its design goals,
etc. I did that a long time ago, that's why I wrote VB6 code. And that's
why, when needed, I write VB.NET code (although I don't like its syntax,
which I consider too verbose). But that has nothing to do with language
characteristics, rather more with the framework and the programmer's
skills.
And as for that, from an OO perspective, VB6 lacked several features,
despite being marketed as an OO language. That is why I think VB6 sucked.
Best regards.
--
Fernando Gómez
http://www.fermasmas.com
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 21:41:06 -0600, "Michael D. Ober" <...@.alum.mit.edu.nospam.
""Fernando A. G F."" <...@TK2MSFTNGP03.phx.gbl...
Actually VB6 was marketed as Object Based, which is a far cry from true OO.
The VB6 object basing basically allows you to hide implementation details
but not much more.
As for inheritance, I just wrote a simple file parser based on the net
filestream class. I had to read lines that were CRLF terminated, but had LF
characters in the line, so StreamReader wouldn't work. Using Inheritance,
it took less than 30 lines of code.
Mike Ober.
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 12:55:10 -0400, dgk <...@somewhere.com
On Thu, 18 Jun 2009 10:25:26 -0500, "Fernando A. Gómez F."
<...@gmail.com
Yes, it didn't have inheritence. And now it does and I don't use it.
Well, of course I do. Every class inherits from other classes. But I
don't write my own classes that way. I once was at a Dan Appleman
lecture where he said that he could only think of a few instances
where inheritence was needed to do an app right. Mostly I find that
inheritence makes things more complex unnecessarily.
To me, an application language is good when it solves the problem -
and I really did start with 360/370 assembler so I've been through a
few. VB solved an awful lot of problems for me.
I think most folks who argue against VB find it too verbose. I find it
just right but C# is a bit too concise, almost like it's being
intentionally cryptic. Here's an example of a nice concise statement
written in MUMPS:
S:R
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.
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.
|
|
|
|
|
|
|
|
|
On Sun, 21 Jun 2009 05:08:00 -0700, "Michael J. Ryan" <...@tracker1.info.invalid
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"});
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.
|
|
|
|
|
|
|
|
|
On Wed, 17 Jun 2009 14:05:01 -0400, "Jeff Johnson" <...@enough.spam
""Fernando A. Gmez F."" <...@TK2MSFTNGP03.phx.gbl...
Which is what made it the most popular Microsoft language ever, right?
Oh, I almost forgot: bite me.
(Flame on!)
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 10:00:55 -0500, "Fernando A. Gómez F." <...@gmail.com
Yep, but wasn't it the only MS language at the time?
Easy man, we're here to talk. Why did you have to go aggressive?
--
Fernando Gómez
http://www.fermasmas.com
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 12:07:54 -0400, "Nobody" <...@nobody.com
""Fernando A. Gmez F."" <...@TK2MSFTNGP02.phx.gbl...
Nope, sure wasn't.
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 11:27:21 -0500, "Fernando A. Gómez F." <...@gmail.com
Sorry I missed that. Which other languages had MS at the time?
Certainly, C++ is not a MS language... Perhaps you refer to J++?
Best regards.
--
Fernando Gómez
http://www.fermasmas.com
|
|
|
|
|
|
|
|
|
On Thu, 18 Jun 2009 21:32:28 -0700, Tim Roberts <...@probo.com
"Fernando A. Gómez F." <...@gmail.com
By that definition, Basic is definitely not a Microsoft language. It
predates Microsoft by a decade.
The only truly Microsoft language is C#.
--
Tim Roberts, tim...@probo.com
Providenza & Boekelheide, Inc.
|
|
|
|
|
|
|
|
|
On Fri, 19 Jun 2009 03:44:22 -0400, Mike <...@unknown.tv
Good point, but isn't the analogy the same?
VB.NET is to BASIC, what
C# is to C++
C++ and BASIC aren't Microsoft invented but the mutations C# and
VB.NET are. No? :-)
Maybe that is why SUN nips on potential mutation of JAVA by Microsoft
and sued them before it became their own. That is the reason
Microsoft is abandoning Java.NET - they can't control it. :-)
--
|
|
|
|
|
|
|
|
|
On Sat, 20 Jun 2009 17:21:07 +1000, "Timothy Casey" <...@timothycasey.info
"Tim Roberts" <...@4ax.com...
I doubt C# is a language unto itself. C# is simply another variation or
dialect of C, along with C+, C++ etc. (hence the affectation of 'C' with
modifier in the name).
The only language I can trace back to Microsoft is RTF (1987). RTF can be
structured two ways. One uses group hierarchies to define non-overlapping
format zones and results in a structure identical to that of the style of
SGML that uses the generic closure tag; </closing curly brace: }. Interestingly, SGML also has another structure
identical to the inline (potentially overlapping) flag system used in RTF
when the group hierarchy is not used. RTF's equivalent of block elements are
deployed with the same structure as that used in IBM's GML, which is the
root for SGML. RTF may well use different control characters, but in terms
of structure it is closer to a SGML and GML than HTML. Nevertheless, RTF,
having its own vocabulary, is much more a language unto itself than is the #
variant of C.
Much of what we consider "new" on PCs has already been done on mainframes
and minicomputers. Honeywell had DDR memory in minicomputers decades before
it was "new" in PCs and some of the decades old 1Gb SSDs used in older ICBMs
are *still* much faster than the brand "new" SSDs made for the PC market.
Macros were used to describe classes before the word 'macro' was
systematically misused to promote MS Office's reinvention of what was once
known as "master mode". Master mode was the first attempt at laying a
foundation for SaaS, once again back in the mainframe days, and once again
master mode was discredited spectacularly decades before malware authors
used the exact same techniques to exploit Office "macro" functionality. In
fact, the same techniques for information theft are still used via
JavaScript, VBScript, ActiveX, XAML, & .NET components served up to the
client as applications disguised as documents.
Relational databases have not changed since the 1970's - only the
programming interface has changed. Hierarchical databases are still plagued
by the same fragmentation issues now as they were when writers like Kroenke
(1977) outlined the methods and conundrums of data storage. Database
normalisation dates back to Codd (1970), and although Goveran & Date (1994)
are credited with the Orthogonal Design principle, the concept of functional
dependence discussed by authors like Kroenke (1977) is not dissimilar.
Basic was first designed and put to use at Dartmouth College by John Kemeny
and Thomas Kurtz in 1964. However as most of the original vocabulary of
Basic continues in Visual Basic, then VB is likewise an evolved dialect of
Basic (in much the same way that Standard Italian is an evolved dialect of
Latin - probably with overlap of variations of local dialect thrown in for
broader accessibility). The world's first IDE came with Dartmouth Basic, as
Basic was not intended to be simply a beginner's programming language but to
serve as an example of the cost savings offered by a little versatility and
simplified UI. This focus on simplicity is probably why Basic remained the
most versatile programming language. In time, console IDE evolved into
keyboard-based IDEs, such as Maestro I of the 1970's and then the graphic
IDE or CASE emerged in 1982 with GraphiText, followed by DesignAid; the
first to support a wide range of structured analysis and design
methodologies.
Then there is the broken paradigm (not the hippy symbol for establishment
perspective, but the real linguistic animal). Human language structures are
verb oriented, whereas modifications like that of Basic into VB have shifted
the fundamental structural orientation from verb oriented to noun oriented.
This makes separation and identification of subject and object vastly
simpler and more consistent than the more variable verb oriented
expressions. OOP was known decades ago as State Driven Programming and has
quite a long history. It was MIT that originally smashed the paradigm with
PDP-1, shortly followed by Daal & Nygaard's Simula 67 in the 1960's, which
interestingly also had the first 'garbage collection' functionality.
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. VB already has demonstrable roots in GML, SGML,
Dartmouth Basic, PDP-1, Simula 67, & DesignAid, with influences hailing from
C (multilevel programming), Pascal (string assembly systems), etc. Only dead
languages like Latin and Esperanto are pretty. Popular languages are always
'bastardised' and anything but eloquent because it is that flexibility,
which makes a language most accessible to the broadest possible demographic;
and accessibility is the lifeblood of language.
--
Timothy Casey - Email: 5th-...@timothycasey.info
Software: http://software-1011.com; Scientific IQ Test, Web Menus, Security
http://web-design-1011.com http://speed-reading-comprehension.com
Science & Geology: http://geologist-1011.com; http://geologist-1011.net
|
|
|
|
|
|
|
|
|
On Sat, 20 Jun 2009 10:26:45 -0400, Mike <...@unknown.tv
Good show Timothy. Very good recollection of related computer history. :)
+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.
--
|
|
|
|
|
|
|
|
|
On Sun, 21 Jun 2009 06:37:02 -0700, "Michael J. Ryan" <...@tracker1.info.invalid
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.
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 00:16:37 +0100, "Mark Rae [MVP]" <...@markNOSPAMrae.net
"Visual Basic Soul is in our of us"...
What does that mean...?
--
Mark Rae
ASP.NET MVP
http://www.markrae.net
|
|
|
|
|
|
|
|
|
On Sun, 21 Jun 2009 19:43:21 -0400, Mike <...@unknown.tv
Oops
"Visual Basic Soul is in ALL of us"...
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 08:36:28 +1000, "Timothy Casey" <...@timothycasey.info
"Mike" <...@TK2MSFTNGP03.phx.gbl...
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.
--
Timothy Casey - Email: 5th-...@timothycasey.info
Software: http://software-1011.com; Scientific IQ Test, Web Menus, Security
http://web-design-1011.com http://speed-reading-comprehension.com
Science & Geology: http://geologist-1011.com; http://geologist-1011.net
|
|
|
|
|
|
|
|
|
On Sun, 21 Jun 2009 23:22:26 -0400, Mike <...@unknown.tv
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.
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.
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.
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. :-)
Sure to protect their asset.
It depends in how its applied. But sure, the point is solid.
See ya.
--
|
|
|
|
|
|
|
|
|
On Sun, 21 Jun 2009 23:38:18 -0400, Michael Covington <...@www.ai.uga.edu.slash.mc
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.
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 01:21:19 -0400, Mike <...@unknown.tv
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 :)
--
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 10:19:18 -0400, Michael Covington <...@www.ai.uga.edu.slash.mc
That's me. Michael Covington of "Natural Language Processing for Prolog
Programmers" and other books.
Well, I don't know about that. A good typist can do 75-100 words per
minute, which is comparable to the speed of speech (100-180 wpm). The
keyboard is likely to be a lot more concise in many ways.
If only you can get them to THINK! :)
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 14:31:44 -0400, Mike <...@unknown.tv
Very cool!
Interesting. Didn't know the correlation. I think people who grew up
type writers, teletypes machines, punch cards, etc, are fast typist
and possible "power" software programmers. Yes, I can see the more
concise "output" although of recent, my keyboard replacement
selections have been sucking and maybe a little of aging and dyslexia
is kicking in. :-)
Right! which brings me to a surprising twist of a society axiom I
recently saw which I will further twist and apply here:
Give a man an answer, and he will solve his
problem for that day.
Teach a man how to think and find his own solutions,
and we will lose a great business opportunity!
<g
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 10:21:04 -0400, Michael Covington <...@www.ai.uga.edu.slash.mc
One other thought... Something that worked against Prolog is that in the
late 1980s and 1990s, there was a movement to do everything in one
programming language (first C++, then Java) and kill off all the other
languages. Prolog got no respect simply because it wasn't a dialect of
C. Maybe F# will catch on and will raise people's consciousness about
alternative programming methodologies.
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 12:01:57 -0400, "vanderghast" <vanderghast@com
"Michael Covington" <...@www.ai.uga.edu.slash.mcmessage news...@TK2MSFTNGP04.phx.gbl...
Maybe, maybe not. If I compare Prolog to SQL, both are about what we want
rather than how to get it, right? but SQL is still quite alive and well,
even got it nobility recognition by being copied (such as for LINQ).
Vanderghast, Access MVP
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 10:00:50 -0700, "Peter Duniho" <...@nnowslpianmk.com
A favor to ask, please:
Would those of you participating in this thread, please _stop_ changing
the subject.
It was off-topic from the outset, and really shouldn't have been on any of
these newsgroups, if for no other reason than calling a language "dead" is
inflammatory. But the occasional off-topic thread isn't really all _that_
much of a problem, as long as it's easy to filter out.
Except that, when you keep changing the subject, it negates any effort to
filter the thread out and it becomes a much greater problem.
Ideally, if you all would like to have a discussion about various
high-level languages, nostalgic or technical, you'd take it to a newsgroup
where that kind of discussion is relevant. Barring that, please at least
let those of us who'd prefer to stick to actual programming topics not
have to keep re-filtering the off-topic thread, by leaving the subject
alone.
Thanks,
Pete
|
|
|
|
|
|
|
|
|
On Mon, 22 Jun 2009 14:56:50 -0400, Mike <...@unknown.tv
Thats a very good point. In fact, if I recall, there was a movement to
have one OS - Pink? Or something else? Brain is fading. :-) But
that was the promise of the then big people in control, IBM,
Microsoft, Sun and others who have a sake in all this. It never
really materialized.
The axiom I stated in the last post applies. The socialist method (a
monopoly is really a form of socialism) only benefits one capitalist.
So having different ways of doing the same things, some easier than
others, some more powerful than others, etc, with a never-ending
expansion capability allows for more businesses and competition to exist.
I recall in a PDC I attended a while back, arriving tired to the hotel
in Seattle, getting to my room, turning on the TV where there was a
local news channel interviewing Bill Gates about the important PDC
starting the next day. When asked, "How do you keep with your
competitors?", he surprisingly said:
"Change the standards every two years."
It shocked the crap out of me! Of course, he was thinking of then #1
competitor Borland (before he get a record breaking multi-million
signing bonus to steal Anders from Borland), including every MS
developer and business who to depend on Microsoft and could never keep
up with them.
In other words, there is less profits in a stable technology, market
place and it helps competitors to keep them 1 or 2 steps behind always
trying to keep up.
Got to admire Bill Gates. :-) Ray Ozzie? I am not too thrill about him.
--
|
|
|
|
|
|
|
|
|
On Sun, 21 Jun 2009 23:36:11 -0400, Michael Covington <...@www.ai.uga.edu.slash.mc
If English were the ideal language for expressing technical concepts,
there would be no formulas or diagrams in engineering books.
Human languages are not designed for expressing algorithms and data
structures precisely and concisely.
I do NLP research for a living. This is not what it's good for.
|
|
|
|
|
|
|
|
|
On Wed, 24 Jun 2009 13:55:57 +1000, "Timothy Casey" <...@timothycasey.info
"Michael Covington" <...@www.ai.uga.edu.slash.mcmessage news...@TK2MSFTNGP04.phx.gbl...
That depends on specification. I too have an NLP research program, which I
started several years ago. What I am working on will eventually be
adaptable to turning specifications into code - unless the specifications
are incomplete, vague, or misleading (which renders the specification a
meagre pretence).
--
Timothy Casey - Email: 5th-...@timothycasey.info
Software: http://software-1011.com; Scientific IQ Test, Web Menus, Security
http://web-design-1011.com http://speed-reading-comprehension.com
Science & Geology: http://geologist-1011.com; http://geologist-1011.net
|
|
|
|
|
|
|
|
|
On Wed, 24 Jun 2009 14:25:16 +1000, "Timothy Casey" <...@timothycasey.info
"Marcus" <...@sunce.iskon.hr...
Latin is dead. So are Simula 67 and GML!
VB is very much in use. Many happy users and possibly many unhappy users.
Either way, VB is very much alive, kicking, screaming, and disemboweling the
incautious.
People who opine that VB is a dead language either fail to understand the
role of usage as a determiner of language or they are a little out of touch
with the real world, or both.
VB can be used to produce applications that work. Period. So, whether you
'should' invest in VB all boils down to what *you* need from a programming
language. If you need employment as a coder, the more languages you acquire
the more customers can include you in their project development teams, and
the more contracts you can choose from. If you need to write an antivirus
application, neither VB nor C, nor any language other than Assembler or raw
machine code are up to the task. If you need to write ASP and SaaS then
VB.NET is also accompanied by VC and a bevy of other visualised language
interfaces, so the choice is yours. If you need to put a desktop app onto a
286 VB4 does an admirable job, although any C or Basic compiler should do
the trick with a little more work, but neither VB5, VB6, VB.NET, VB2005, or
VB2008 are capable. If it's desktop applications for modern PCs, then VB6
works securely for shareware vendors, while VB .NET has a fantastic IDE &
CASE. Once again, there are always plenty of other programming languages to
choose from.
The big question has always been whether the language suits *you*.
The best way to find out is to try it and see.
Good luck...
--
Timothy Casey - Email: 5th-...@timothycasey.info
Software: http://software-1011.com; Scientific IQ Test, Web Menus, Security
http://web-design-1011.com http://speed-reading-comprehension.com
Science & Geology: http://geologist-1011.com; http://geologist-1011.net
|
|
|
|
|
|
|
|
|
On Tue, 23 Jun 2009 19:48:41 -0400, "mayayana" <...@rcXXn.com
That's a good one. A person wants to know
whether they should continue investing time
in VB.Net, and the two "most dependable"
answers are a Microsoft marketing video and
a signup-required Facebook chat. :)
|
|
|
|
|
|
|
|
|
On Wed, 24 Jun 2009 03:15:28 -0500, "Sanders Kaufman" <...@kaufman.net
"mayayana" <...@TK2MSFTNGP02.phx.gbl...
It's a very effective spam strategy.
Post something like "is vb dead" or "Why Abortion is Good" - and you can
harvest a bunch of ID's from the responses.
|
|
|
|
|
|
|
|
|
On Wed, 24 Jun 2009 05:49:30 -0400, Mike <...@unknown.tv
It only works against people who use their (or a real) email address here.
Look at mime! <g
--
|
|
|
|
|
|
|