On another programming related website, I saw this line in someone's signature. This is NOT the first time I've seen such sentiments, although this is the harshest:
"People who work in VB or any variant
thereof are not programmers, they are
circus chimps throwing feces into an
IDE..."
VBA is my bread and butter and I can automate quite a bit of stuff with it. Yes, I know it lacks polish and some functionality, but why so much negativity toward it? On the flip side, what do other languages have that VB doesn't?
VB6, VBScript, and VBA have the reputation because they just aren't industrial strength languages. Notably:
No OOP. Sure, you have classes and modules, but no inheritance. VB isn't a low-level language, it needs real objects.
No first-class functions, so you can't even simulate OOP or polymorphism.
Lack of a well-developed class library. VB6 has a small library of built-in functions, and almost all other functionality is delegated to Windows calls or (usually pricey) third-party components.
Lousy error-handling. ON ERROR RESUME NEXT is a pox on the planet.
Although its not the fault of the language, VBA earned a bad reputation by association with MSAccess.
Of course, VB wasn't really intended to be an industrial strength language, so maybe nothing mentioned above is really proper criticism of the language at all. Fortunately VB.NET and the latest versions of VBA fix everything above, so VB.NET is on par with any other "serious" language in the marketplace.
[anecdote]
In defense of VB, I find most people criticize the language just to go along with the status quo, not because they've actually used it.
A few years ago, in a chatroom, I ran across young neophyte railing against a VB6 developer for using such a crappy language. I innocently asked "what's wrong with VB".
The first thing he said was "Because its a WINDOWS language!" So I pointed out that Borland Delphi is a Windows only language*, but I've never heard anyone malign it for that reason. (* There was a product called Kylix which cross-compiles to Linux, but its expensive, buggy, and discontinued. Its been a while since I've used Delphi, but last I'd heard, its still not ready for Linux.)
So, he said "It has a HORRIBLE SYNTAX!" Is that really the reason people hate this language? I'd say Perl, Lisp, and C++ are worse on the eyes than VB.
Next, he says "Its too easy to learn!" Well, I'd consider that a point in favor of the language. I'll never write a GUI by hand if I have a drag-and-drop designer at my disposal. What else you got?
So finally, grasping at straws, he comments "It has... no string manipulation functions". Left, Right, Mid, Replace, InStr and Trim. QED noob.
Interestingly, VB has features found some "hacker" languages, namely variant datatypes and duck typing. Compiled code performed reasonably well, interop between COM and native windows DLLs was easy, and the GUI editor basically set the bar for all future RAD development.
[/anecdote]
Read some of Joel Spolsky's articles and you'll feel better about yourself. From his article Working on CityDesk, Part Three:
Visual Basic is an extremely productive way to write code, especially GUI code. Want bold text on a dialog box? It's one click in VB. Now try doing it in MFC. You have to create a subclassed control, it's a big mess, you have to know all about LOGFONTS and Windows window subclassing and a bunch of other things and you need about three lines of code once you have the magic class.
But many VB programs are spaghetti, either because they're done as quick and dirty one-offs, or because they're written by hack programmers without training in object oriented programming, or even structured programming.
What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines. The code looks pretty good, it's object-oriented and robust, but you don't waste time using tools that are at a level lower than you need. I've spent years writing code for C++/MFC and years writing code in Visual Basic, and let me tell you, VB is just much, much more productive.
This simplicity attracts a lot of new programmers. Saying there are a lot of bad programmers using Visual Basic does not mean Visual Basic is a bad language; it simply means that Visual Basic is accessible to bad programmers (AKA new programmers).
I work in a place where all the code is C#, not VB .NET. One developer wrote most of the code. You know how he achieved this feat? Easy: He copied-and-pasted all over the place. A given method might have anywhere from a few to hundreds of copies throughout the system.
Good developers can be good in any language. Crappy developers can be crappy in any language.
Also just to note that VB, VBA, and VB.NET are all three different languages even though they might share some similar syntax. There's no real difference between VB.NET and C# (besides the keywords/syntax), so we shouldn't lump VB (6 and before) and VBA in with VB.NET.
The real problem that many programmers have with "VB" (just say all 3 of the languages) is really more about the people using it. Most of the time "VB" programmers have less formal education and write sloppier code. That's not true for all "VB" programmers (and that doesn't mean there's not sloppy code written in C++, Java, C#, etc.). It's just the typical expectation that someone who doesn't use VB has when they hear about VB programs.
Meh, these are just religious bigots.
There is no one true language, and most experienced folks not only know that, but instantly recognize these statements as a glaring sign of inexperience.
Average developer quality seems to be inversely proportional to popularity of language * ease of use of language. VB is very easy, and is/was widely used.
This is because
A) there's a demand for coders in popular languages, so every employer has to either lower their standards, raise their pay or go without developers.
B) people without a clue can still appear moderately productive in easy to use languages. There are enough libraries and GUI tools that they can slap together something that looks useful, even if it's complete garbage under the hood.
There's nothing inherently wrong with VB when used in the domains it was intended for, by people who know what they're doing. The same is true for almost any tool/language.
I dislike the language, but that's mostly because I worked with a vb-like language which stripped out absolutely anything that might be considered an advantage and forced "best practices" that really didn't make sense.
The biggest problem I have with VB is that there is an almost direct track from clueless non-programmer -> part time Excel/Access scripter -> VBA "guru" -> VB "programmer" -> lead programmer on the most important project in the company.
Honestly I wouldn't have believed it if I didn't see someone follow that path right in front of my eyes. I even tried to mentor the guy so that he would be familiar with OOP, exception based error handling, etc. but he just dug his head in the sand and wrote everything procedurally because that had always worked for him.
I have had a chance to work with VB.Net and as long as I treated it like an object oriended .Net langauge first and VB second it wasn't so bad. It would never be my first choice for a new project, though.
I'm visiting SO in between writing VBScript code and that statement really rings true to me -- I am currently a circus chimp. If you don't know anything else, VB and its variants seem like great languages.
In my opinion, the reason for the negativity is one basic statement -- On Error Resume Next. This makes bad code a feature of the language. If it didn't have this, it wouldn't have near the bad publicity...
Most every developer I know has worked at one point or another with a VB developer, or a developer with a heavy VB background that just didn't have a clue. Unfortunately, as with most things, all we remember are the bad things about something. So we relate VB to bad programming.
It is certainly not true that all VB programmers are poor developers. But when everybody has stories about "This one old VB guy I used to work with." The stereotype is spread.
Related
I've used Teleflex, developerfusion, and SharpDeveloper, and all these, to convert C# to VB, but as most know, there are always errors, and modules left out, and such.
Does anybody know of a good VB editor, preferably freeware, and can handle translated VB and offer suggestions to correct it for you?
Visual Studio underlines things and offers suggestions on some things, but other things it just underlines and leaves you to the guesswork, which doesn't help a non-coder like me.
Non-coders shouldn't be translating C# to VB.
No code translator will take care of everything for you. Even if it works programmatically, there are design patterns and code standards that are different for each language. Hire a programer.
No. And it's not always possible to convert C# to VB. Some features of C# have no equivalent in VB.
Unsafe code (e.g. pointers)
Iterators (yield)
Conversely some features of VB have no equivalent in C#.
Exception filters
XML literals
Why do you need to convert the code anyway? What's the business case?
VB and C# are different langages, so even the best translator in the world will miss some things. The person doing the translation shouldn't be a "non-coder" and should know at least some VB, so when a compile error is shown, he knows what to do with it, or at least knows how to search on the web (or ask on SO) to know how such part of code can be translated to VB.
Although vb.net and C# are both designed around the same .net framework, and consequently feature very similar features that work mostly the same way, many corner cases are handled differently by the two languages. While one could argue ad nauseum about whether a statement like myStruct = new myStructType(someParams) should affect the value of myStruct before the constructor completes (in C#, it does not; in vb.net, it does), and it's probably good to avoid designing code around corner cases, it's doubtful that any translator--much less a freeware one--will detect all of the corner cases and ensure that code which (possibly accidentally) relies upon them will still run correctly.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've been wanting to get into a pure-OO language for a while now, but I'm put off by the fact that they all seem to demand an IDE and I can't find any good tutorials that aren't in video format.
I'm happy to use an IDE later, but I don't want to learn the language through one. What I'm looking for is a simple console interpreter or command-line compiler such as gcc, ghc, ghci and the python IDLE (yes, it's an IDE, but it's so minimalist that it may as well just be a commandline interpretter). I find that I learn a language faster, better and more comprehensively when I'm not trying to grapple with an IDE at the same time. So please, don't tell me that squeak is the only way to do it :P
I'm also looking for tutorials that are presented textually rather than visually. Again, I learn faster when I can stare at a page and read someone's sentance over and over tossing and turning it in my mind rather than having to pause a video, take it back 10 seconds, press play, do it again, and again, and again.
I'm interested in various languages with various degrees of OO-purity, and I plan to learn them all at some point. Any of the smalltalk dialects interest me, Self (an extreme prototype-oriented version of smalltalk (Very interesting, the more radical the better imo)), strongtalk, vanilla smalltalk (or some implementation which is as vanilla as you can get).
I'm interested in Eiffel as well, the code snippets I've seen make it seem very elegant and I've read that it actually was very innovative (introduced code-contracts and other such things). However I would give preference to a language from the smalltalk camp over one from the Eiffel side because Eiffel at face value seems to be a hybrid between OO and imperative programming. Similarly I'd rather avoid Scala (Hybrid OO and functional) and other hybrid languages. So no C#, Java, C++, D, python etc etc etc. I'm not dismissing these languages because I believe they are bad, it's just that I'm setting out to learn pure-OO and those languages are hybrid OO: Not really what I'm looking for.
Also, would anyone be able to recommend the official books? For smalltalk there's the "Blue book" AKA "Smalltalk-80: The Language and its Implementation". And for Eiffel there's "Eiffel: The Language". I ask because in my experience you can pick up so much by reading books written by the author of the language (see K&R the C programming language), and by reading books in general.
So yes, my questions: What pure-OO language would be good to start off with? How would I go about learning it without having to use an IDE? And is there an associated book written by the language author(s)?
It is not helpful to learn Smalltalk as just another language. You would be missing the point entirely.
Smalltalk's graphical environment is not just an IDE. The core of the system is simply objects. The interface provides various ways to create objects and interact with them. The language is just a convenient way to create messages to the objects. It is secondary to the objects themselves.
In other OO languages, you write your program, then you run it, which creates objects in memory. Not so in Smalltalk. You create objects in memory (e.g. class objects) and then send messages to e.g. add methods. But a class object is only created once, not every time you "run your program".
There is no such thing as "your program", in fact. There is no "main". It's just a world of objects, some longer-lived, some temporary. In fact, in the system there are objects that were created 30 years ago. Literally. The objects are just frozen to disk as a memory dump (a file which we call "image") and unfrozen later (possibly on a different machine).
That image, the world of objects, is the primary artifact in Smalltalk. There is a sources file, yes, but that's just a database of text snippets to not take up so much RAM. You cannot edit this file by hand (objects in the image use absolute file offsets into the sources file). You cannot re-create the system from the sources file - the system was bootstrapped a long time ago and from then on only modified.
It's true that superficially the Smalltalk GUI looks just like another IDE. No coincidence - Eclipse was originally written by Smalltalkers in Smalltalk. But there is the crucial difference that in regular IDEs you just manipulate text files. A text editor is a valid alternative for that. In Smalltalk, the GUI manipulates objects in memory. A text editor can not do that.
And as for what Smalltalk to use, I would recommend Squeak. Very friendly community, very nice environment, and subscribing to the original Smalltalk vision of creating a great personal computing environment for everyone.
As someone who has went through process of learning Smalltalk (at least to a decent degree), I can say that you are taking harder and riskier path, in a sense that some things may take much longer to clear up, or never actually do.
But, if you insist, you can download GNU Smalltalk, for which no GUI is a norm. It also contains all sources of the system written in Smalltalk in a chunk format and you can open your text editor on them and enjoy while slowly reading through the guts of the system.
You could also startup any other Smalltalk, like Pharo, and just stick with a workspace window - this is your equivalent of command line interpreter.
Pharo also includes ProfStef quick interactive tutorial on Smalltalk, which combines text instructions and evaluating Smalltalk expressions.
As for reading, there is Pharo By Example - free book that you can browse, download or buy hardcopy.
There is also a collection of free books in which I would recommend "Smalltalk-80: The Language and its Implementation" By Adele Goldberg and David Robson, if you are interested in the innards and detail of the language.
Late David N. Smith Smalltalk FAQ is also exelent resource.
So, there you go. And take advice, and give in to the Smalltalk IDE as soon as possible, since it makes understanding of Smalltalk much, much, faster.
Richard Gabriel gave a talk recently about a paradigm shift that occurred in the programming language community in the early 90s. He claims that most experts today are incapable of understanding many of the papers from the 80s. He has evidence to back this up. This was the first time he gave the talk, and he expects to give it many times, so I imagine that many parts of the talk will change. At first, he described this paradigm shift as engineering -> science, but then he described it as system -> language. I think that describing it as a shift from systems thinking to language thinking is a better description.
Richard Gabriel is a Lisp guy. (I'm a Smalltalk guy). Lisp is like Smalltalk in that there isn't a clear boundary between the language and the library that it uses. Arithmetic and control flow are in the libraries, not the language. (Well, Lisp has some in the language and some in the libraries, while Smalltalk has it all in the libraries, except that the compiler cheats and hard codes some of them, so there isn't really much difference in the end.) In Lisp, a program is an S-expression, and editing programs is editing S-expressions. In Smalltalk, a program is a collection of objects, and editing programs is editing objects. When you are programming, you are building a system, and you program with the system.
System thinking is different from language thinking. Language thinkers want a precise description of a language. They want a book that describes the whole thing, or (if they are academics) they want a formal semantics for the language. But system thinkers know that as soon as they start to use the system, it will change. They want to understand how the system works, but are prepared to look at the system itself to figure out the details.
These are two ways of thinking, and there are advantages and disadvantages of each. Smalltalk is a wonderful example of systems thinking. I think all software developers should know at least one system that exemplifies systems thinking. Lisp is good. Forth is another old example. Naturally, I think that Smalltalk is great and am happy to help people learn it but I think the importance of learning systems thinking is more important than the particular system you learn.
Unfortunately, learning a system is harder than learning a language. You have to do more than just learn the syntax, you have to learn the libraries, the patterns of naming and of coding, and usually the tools. (Which, if this is a system, are extensible.) That is one of the advantages of language thinking. But systems thinking has long-term advantages, because once you taylor the system to your needs then you can become very productive.
To lean smalltalk syntax, you need to read ONE page of text (see Syntax section on wiki http://en.wikipedia.org/wiki/Smalltalk).
Now, to learn a smalltalk libraries and how to use them, you need to use browser not the text editor, otherwise your will just waste a lot of time.
I think that it is like factor of 10 difference in time, between trying to understand some code by reading in textual format and navigating it using browser and! debugger.
In smalltalk system a living objects could tell a lot about themselves and help you learn how to use them much faster than if you look at it as a static chunks of text, because you won't grasp the idea at all.
I've been playing with Squeak Smalltalk (and its close cousins, Pharo and Cuis) for a while now. There's no better way to learn Smalltalk than by using the system already provided.
I've devised a series of short youtube tutorials ranging in length from 50 seconds to 15 minutes that show how to take advantage of Squeak's ultra-cool features within a few minutes of first starting the system.
In fact, the very first line of code demos the OOP-ness of Squeak. Squeak from the very start
Python is a pure OOP . Actually this is an easy mistake that newcomers make when they come to python.
Python like smalltalk follows the mantra "Everything is an object". So everything inside python is an object, including built-in types. The difference is that python unlike smalltalk and Java does not force OOP as it allows procedural programming. And this is the trap, it easy to assume that makes python less OOP , but being a snake, is so devlish that does not tell you that even functions are objects ;)
http://www.linuxtopia.org/online_books/programming_books/python_programming/python_ch10s04.html
Going back to smalltalk its IDE is the huge deal here, contrary what other smalltalker may believe. If you like me are heavily disappointed with how non flexible IDEs are you are going to love Squeak's IDE. The IDE goes a great deal making easy to navigate through all the libraries and making you understand what , where and why , something happens. I cant see the benefit of using a text editor. But you can, with file ins and file outs. But doing so you cripple smalltalk into becoming as efficient as other programming languages ;)
I am only studying squeak and pharo for a week now but even for me as a beginner the benefits of the IDE is obvious from the first minute.
The fact that code is fragmented into easy to digest methods, those methods grouped into protocols , protocols grouped to our familiar Classes and Classes grouped to packages. Hence the code is so well organized that I never feel lost, everything belongs somewhere, everything is just a click away, everything is inspectable, browseable , you just select right click and sends you there. And it shows you exactly the code you need rarely more than 10 lines long. This is the IDE. Why would you prefer a text editor that will expose to information that you don't need , don't care and is likely to confuse you ?
Then everything is inside a single image , not a collection of files, your code, your libraries, system libraries , even the language itself. Everything is at your grasp, waiting for you, begging you to test, modify it, use it and abuse it. You are part of the language and the language is part of your, if something does not fit your thinking, change it. This is the IDE. Why you want to go back to the disconnected way of files and folders ?
Then you are start being afraid with all this power, all this flexibility its not unlikely that you will do something that could completely destroy the language and the libraries. Its possible , mistakes can and will happen. Again the IDE jumps in offering you a hand of help, every change is stored in a local cvs system, every change is categorized, stored and monitored any time. No lousy undos and any kind of other nonsense . What you get is old , mature well tested version control. You can change back exactly what you want any time, nothing is lost, no mistake is irreversible.
And if you don't trust you hard driver , the vcs extends online to squeaksource . And does it let you at the mercy of command line ? Hell no . You are offered the simple yet efficient Monticello browser , which will make sure you install and unistall with no conflicts .
And of course you don't want your software to have bugs , do you ? Unit Testing tool is offered to make sure your code is reliable , stable and does exactly what you want how you want it. Again a beautiful yet brilliant GUI is utilized to make complicate tasks a button away.
And because none is perfect , there will be time you will come against the dreadful error. Are you left alone ? You guessed right , a tool again is offered. The debugger. You don't need to call it, you don't need to setup it , you don't even need to figure out how it works. Like all other tools, is simple in design yet sophisticated. Not only it will spot the error , not only will tell you what you did wrong , not only will navigate through back to most basic language elements that trigger the error offering a unique perspective on how exactly the language behave like nothing I have seen before, it also allows you to do live coding. Live coding is the ability to code a program while its code runs. Isn't that impressive and infinitely useful ?
Finally , maybe you are one of those people impossible to please, maybe you still find flaws , omissions and thinks you simple don't like. The IDE is written in smalltalk , smalltalk is written in smalltalk , and the IDE can edit itself and the language, there is nothing you can't change besides some very basic functionality of the language and the VM that is compiled C. And you will guess right if you think you can use all the above tools to do exactly that.
And the tools don't stop here , smalltalk might be not that popular as other languages but it has been here for a very long time and it has some very enthusiastic programmers that love to contribute. And frankly with such an amazing IDE and such a well designed language , while with other languages contributing to them might seem a challenge, in case of smalltalk the challenge is to resist the temptation not to contribute as the IDE makes it so easy.
By the time others still code you will finish your code and actually understand what have you done and why. Thats not a small thing at all . I wish Python had such a good IDE or any other language. But the only thing that comes abit close, from my experience , is Delphi. And even in the case of Delphi I still prefer squeak and pharo.
What I find annoying about other IDEs is that they are not IDES at all, they are nothing more than glorified editors, locked, non flexible , non editable (Unless you are willing to use another programming language and navigate through tons of source code) . Squeak , Pharo and all other smalltalk dialects offer a real elegant IDE offering you really useful tools. Other IDEs better take a deep a look at smalltalk and really understand what it means to be an IDE.
Saying all those good things, smalltalk is far from perfect. And I think its biggest weakness and flaw is lack of some enjoyable and useful documentation that can help beginners jump in head first. Squeak By Example as well Pharo By Example has been a big disappointment for me. They both are still two extremely important books that provide a extremely valuable insight in both platforms , but the quality of documentation is from mediocre to bad at times. The main reason is both books follow a non noob friendly approach. First they send you deep diving in the IDE , introducing you from chapter 1 , to debugger and even unit testing !!! For me this a big mistake, and even though I am far from new to programming had to struggle to follow up what was explained. Then the book itself , lets a lot of unanswered questions. For example the explanation of instance vs class variables is not enough, I would prefer several example that not only show the how but also the why . Several areas of the book are also full of gaps or just hard to follow.
My life got a lot easier when I found this link http://stephane.ducasse.free.fr/FreeBooks.html and from there I downloaded "Smalltalk by Example" which unlike the other book not only it does what it says in the title but makes no assumption on who you are and what you know. I can only highly recommend it. I read that the other books there that are offered freely are very good as well, I will certainly download and read all of them eventually.
Alot of help has been also #squeak at irc.freenode.net, people there has been answering my questions and helping me understand.
Squeak wiki, is ok but not enough, its also not very well organised, and I dont like that comments and discussions appear inside the wiki documentation. So documentation generally can be abit of a struggle for the begginer and certainly Smalltalk IS NOT AN EASY programming language to learn. I hear many smalltalkers say otherwise and I could not disagree more, when I compare smalltalk with python is like night and day. BUT ! Once understand smalltalk , it become much easier to program in it then any other programming language I have learned so far, and I have learned most of them. So in the end I think Smalltalk is a clear win , I also love the FFI library that lets you call any C library with ease, which unleashes serious power for smalltalk.
I dont think you need to learn the language first and then the IDE, its actually a very bad idea for the simple fact that the IDE helps you understand the language and its libraries and any type of code in it. Language and IDE is like brother and sister, yin and yang.
Well, if you decide to learn Eiffel a good book would be "Object-Oriented Software Construction" by Betrand Meyer (he created the Eiffel programming language).
The book provides great insight into object-oriented design using Eiffel. In my humble opinion is one of the best OO books around.
I was wondering if there are any good vb.net code repositories around where people share code they have written, widgets they have developed, classes developed? I hate re-inventing the wheel.
I've been to many places but I must say, CodeProject is the best by far. Their site is http://www.codeproject.com
IMHO, if you're really keen on not reinventing the wheel, I'd suggest you learn at least one more language.
I was stubbornly glued to VB and VB.NET until it dawned on me that vb and vb.net aren't the only language in the world. I therefore learned C# and my programming life has never been the same.
I can now write code in all those 3 languages and am hoping to learn another, probably c++ before the end of the year.
The good thing about being multilingual is that you're never limited in resources; if you can't find code to something in one language, you could find it code in another language. Plus, it doesn't stop you from using your preferred language.
Something like this?
http://www.getvb.com/
You could try the Visual Basic section of GitHub (though you'll need to learn how to use Git before you get anywhere). You could also have a look at these search results on SourceForge.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm reasonably familiar with the various forms of VB that existed prior to .NET (VB6, VBA, VBScript...), but have yet to delve into The Sweet New Flavor that is VB.NET.
So I would very much appreciate it if someone would provide a quick summary of the major differences in the language brought about by VB.NET.
Assuming when you say vb you mean vb 6.
Pretty big. The original visual basic does not use the .net runtime environment, and although they have similar names, they are pretty much too different languages. Visual Basic is not fully object oriented, but VB.net is. Error handling is vastly different between the two. VB.Net has try catch blocks where traditional vb uses On Error GOTO statements. These are just a few differences. The list goes on and on.
Here is a link describing the "Visual Fred" Name.
Oh the horror.
Sorry, but all existing answers are wrong in some way or another. Joel’s is actually the best of the bunch but its poor wording encourages misunderstanding (sorry, Joel – but just look at your comments!):
contrasting VB.Net with VB is not possible, because they are the same thing.
That’s exactly like saying that “contrasting apples with fruits is not possible because they are the same thing,” and as such not very helpful; especially since many people (still) use “VB” synonymously with “VB6.”
So, to clear things up a bit: both VB6 and VB.NET are dialects of the Visual Basic language family (let’s call it that). Their resemblance is superficial at best; someone who has actually used them both (and not only looked at some source codes) will have noticed that apart from a cursory syntactic similarity, they are completely different beasts. Using them are fundamentally different experiences.
The only aspect in which they actually resemble each other (apart from said syntax similarity) is that they both are very well suited for rapid application development (RAD) … at least until you’ve tried dynamic languages such as Python or Ruby in combination with GUI agile frameworks such as Shoes. But even as RAD environments go there’s a huge difference.
VB6 was basically developed to do RAD, nothing else. And in its time, VB6 was the best thing on the marked to do RAD, by a large margin. VB.NET, on the other hand, was not singled out for RAD development – any more than C#. Both are high-end languages backed by a general-purpose framework, much like Java but with the aspiration to improve on some of Java’s faults, such as its over verboseness by cutting a lot of boilerplate code (introduction of delegates, events, properties, operator overloading, autoboxing to name but a few such features).
And while VB.NET is to a large degree backwards compatible, this is very misleading. First off, no sane person would say that C and C++ are the same languages just because a lot of C programs compile fine on C++ compilers. The differences between VB and VB.NET are even bigger by some metrics because no complete VB6 code is valid VB.NET. It needs an automated “upgrade assistant” to produce valid .NET code, and experience has shown that this upgrade assistant is unsuitable even for medium-sized projects, mainly because its literal translation breaks many guidelines and assumptions of the .NET world.
Saying, like Kibbee, that the compilers of VB6 and VB.NET are “basically the same” is flat out wrong. Likewise, claiming that “the .Net runtime is not a change to the language” misses the point completely. Of course it’s a change in the language. VB.NET was completely build around the .NET framework, it’s not just any other library.
He claims that
If VB.Net was meant to be a new language, and not just a new version of an old language, they would have got rid of "On Error Goto" which they didn't.
– which is likewise misleading. “On Error Goto” was included solely for backwards compatibility (the upgrade assistant cannot convert old-style error handling into exception-based error handling).
Let me sum up the main point of this rather long posting so it doesn’t get lost: Just like Java and JavaScript, VB6 and VB.NET have very similar names (and for very much the same reason, too: marketing) but this is entirely misleading. There are a few syntactic similarities. Apart from that, superficially as well as under the hood, they are completely different languages.
VB.Net is just the version of Visual Basic intended to work with the .Net framework. It also makes other changes and additions to the language, but contrasting VB.Net with VB is not possible, because they are the same thing.
What you can do is contrast with VB.Net with VBA, or VB6, or VBScript, or some other variant of Visual Basic. But VB.Net still IS one possible variant of VB. In fact, if you look at the language part of the product by itself, they're now calling the latest version VB9, with VB10 due out later this year.
In the same way, you can't contrast "Pespi" and cola, because Pepsi is a cola, but you can contrast Pepsi and Coke.
That said, the VB.Net dialect of VB brings a significant number of changes and improvements to the language, including true support for object oriented and functional paradigms, to the point where idiomatic VB.Net code is often very different from VB6-era code.
There are quite a few - too many to list I think. You could almost consider VB.Net a completely different language that shares some similar syntax to VB. The biggest change is becoming familiar with the .NET classes.
VB.Net is a newer version that uses the Dot Net Framework / managed code.
VB is the old version.
VB compiles to p-code or native code, VB.net compiles to MSIL. Also the syntax differs a bit. As VB.net is the upgrade path for VB users and programs, there are a bunch of helper objects and functions that makes moving code from VB to VB.net easier, these objects and functions aren't normally used in programs written in other .net languages.
This is sort of a "best language" question, but hopefully with enough of a twist to make it worthwhile.
As someone who only uses C and C#, I'm curious to learn a dynamic language to expand my knowledge. I don't know which to choose.
The thing is that my motivation isn't necessarily to create any "real world" projects, or projects that integrate with other systems, but rather just to learn.
With that said, for someone only familiar languages such as those I mentioned, and possibly ignoring obscurity and lack of support..
Which dynamic language would be the biggest departure?
Which would introduce the most novel concepts?
Which is the exemplar of dynamic languages?
I would suggest learning IronPython. As a language it will still be a significant departure for you, but you'll be able to use everything in the .NET framework that you're familiar with. (I usually think it's a good idea to try to vary just one aspect of development radically at a time... work your way through the different aspects one at a time, and you'll always be comfortable with part of what you're doing, which will help you learn the new part more quickly, IMO.)
Also, with C# 4 you'll be able to call into IronPython from your C# code, including using its dynamic features that way.
The functional languages (LISP, Scheme, etc.) are always worth checking out. They may be some of the bigger departures.
JavaScript is a great stepping stone to go from the C arena to the functional arena. From there you can mess around with JQuery, which, although not a language, forces you to do things in non procedural ways.
Another often overlooked language is SQL. It's obviously a niche language, and as Josh points out, not really 'dynamic', but acquiring a deep understanding of they way set based languages work can really progress a coder.
Careful, if you 'Learn' to much you may end up frustrated with the older languages.
Which dynamic language would be the biggest departure?
Which would introduce the most novel concepts?
I guess that would include Scheme, Erlang and Oz
Which is the exemplar of dynamic languages?
I'd say Ruby and Python
I would suggest any Lisp dialect or Smalltalk. These are dynamic and had heavy influence on the design of other, more mainstream languages.
They also include interesting concepts that are not found in other languages.
Another interesting dynamic language to have a look at is Lua.
It is hard to say, it is definitely a matter of personal taste in a lot of ways. I like learning Python but I am sure that you could learn just as many good things from Ruby about a dynamically typed language.
If you are used to C and C# then any dynamically typed language is going to be a departure. So I say you should use Python because that is what I like, and hopefully you will like it too. If you start using it and you hate it then try something else (like Ruby, Perl, PHP, etc.).
I would say that Lisp fits most, if not all, of your criteria. It's definitely a big departure from C/C++ and C#. It has got alot of novel concepts, and many would argue that it's hard to find a more dynamic language.
Barring Lisp, I myself would go for Ruby.
I'm going to have to vote for Common Lisp here. It is a highly dynamic language that can be adapted to just about anything. You get not only functional programming, but also OO, and even procedural if you so desire. And macros in Lisp are very interesting to study, since to my knowledge no other language has its equivalent.
Plus, developing in a functional style tends to help development in other languages as well. For example, I've noticed that I do OO primarily with immutable objects, thanks to concepts influenced by Lisp and Scheme. And with this, I've noticed an improvement in the stability and maintainability of my OO apps. Just my two cents.
I've been a C++ and C# developer for a long time, and recently started experimenting and learning other languages. I played with Ruby for little while and like it, but it wasn't what I wanted.
I ended up choosing Erlang. After reading about Erlang, I've decided that I really wanted to learn it. I'm not learning Erlang with any hopes of getting a job writing Erlang code. I'm learning Erlang only to become a better developer.
I really do like this language so far. It's only been about a month, and the syntax still gets me sometimes, but I can really see the power of the pattern matching and get excited to write it again. I struggled with the concept of everything being non-mutable at first. But this was mostly because I've "grown up" on C# and C++. C# is a great language and has some amazing tools, but you really have fun with some other languages, particularly something like Erlang. Just don't expect to land a job as a full time Erlang developer. (At least not yet).
For anyone curious, my hobby project is multiple player iPhone app connecting to an Erlang server. For a Windows developer, this has been a major change. But it has renewed my passion for programming, which really was my goal.
If you really want to go crazy but want things to at least be slightly familiar (I know that sounds like a contradiction but it's true), look at F#. It's a type-inferred language but it supports a lot of dynamic type properties. It's a functional language built on top of the CLR so you get full use of the .Net object system which is cool. Because it's a functional language, there are enough novel concepts to really work your brain.
If you really want to go for "biggest departure", Clojure might be of interest. It's a Lisp dialect built on the JVM. It's getting some pretty serious attention both in the Java and Lisp world. It might suit your purposes.