There is a good reason why Perl's design seems to "work out" better than VB's. And that reason is that all of Perl's design was understood and digested by one man (ie Larry Wall) before being spit back out on an unsuspecting world. By contrast VB is designed by committee. That means that there is no conceptual core to the language, leading to many different pieces designed independently that don't work together very well and whose interactions leave something to be desired.

Some of the dangers of design by committee are well-illustrated by this complaint (scroll to the bottom for "Sidebar 1" to find said complaint) about the new Java IO classes:

On the other hand, the new I/O doesn't integrate well with the old I/O. (And when exactly will it stop being new? Will Sun rename the packages when the next, newer I/O capability comes along?) In particular, the Buffers don't connect well with existing java.io classes. Just try explaining that BufferedReader can't read into Buffers and you can't pass a Buffer to BufferedWriter! The JCP operates by chartering an expert group (a committee) to address each specification request. These expert groups work independently, each with a relatively narrow charter. It is hardly surprising that there is little interaction between feature sets, or that new features do not reach broadly into the existing APIs.

OK. That is about a different language. But the issue is the same. As Paul Graham has pointed out, any good hacker should develop a radar for what technologies they want to look into more deeply, and what they should avoid. And a lot of what goes into that radar has to do with who the language is designed for, and how. If it is designed by committee for the use of average programmers, it probably isn't going to be very fun.

BTW, FWIW, I learned VB before Perl. While my VB is very rusty, my experience a few years ago was very similar to what you describe. For me Perl was a breath of fresh air...