VBA Sucks???

[señorbadger]

What does everyone think of VBA and excel as far as i am concerned it si the most tempermental c**p i have ever seen and will probally drive me and my friends suicidal !!

so what u guys think of VBA?

[Kasracer]

Worthless, just like Java Script

[Madboy]

I vote crap, because it really is I only used it for a while, and when i did everything came up with Microsoft has performed an illegal operation forcing close.

[powdir]

in it's defence it has it's moments...

Wouldn't use it for anything remotely critical but i've found that populating a worksheet direct from a db which in turn creates a pie chart or something has won me more smiles from the common or garden user than the biggest projects i ever worked on

[Cander]

Considering it is the cause of 95% of Windows security problems, it is the suck! They have made every product they put out able to run VBA scripts with ability to run any command on your computer.



Not to say VBA itself sucks, but if MS would have implemented it for what is shouled be used for like automating tasks locally by Admins, then it would be fine.

[Arc]

Originally posted by kasracer
Worthless, just like Java Script

You can't compare VBA to JS. JS is highly usefull in web developement. I use it ALL the time for field validation.

[Pc_Madness]

VBA is a pain in the arse to work with.

[Kasracer]

Originally posted by Arc
You can't compare VBA to JS. JS is highly usefull in web developement. I use it ALL the time for field validation.

Over 90% of all java script created on/for the web does not validate (i.e. was not coded properly) so it usually doesn't even work correctly on other browsers besides IE.

Therefore, I usually have it disabled, or if it's enabled it usually doesn't work.

It's worthless

[Pc_Madness]

You can't say that a coding language is worthless simply because developers don't use it properly.

[Kasracer]

Originally posted by Pc_Madness
You can't say that a coding language is worthless simply because developers don't use it properly.

Yes I can and I just did

[wossname]

VBA sucks a LOT of @$$.

VBA in Access, though, is the mother of all things unholy and putrid. This disgusting union should be banned. It is bollocks.

[visualAd]

Originally posted by kasracer
Over 90% of all java script created on/for the web does not validate (i.e. was not coded properly) so it usually doesn't even work correctly on other browsers besides IE.

Therefore, I usually have it disabled, or if it's enabled it usually doesn't work.

It's worthless

I have a big book on Javascript and even after reading it in its entirity and gaining a sound understanding of it I still found it a struggle to use in my web pages.

Javascript would be a great language if it was fully supported by all web browsers. To garuntee a script that will work in the vast majority of web browsers you need to write reems of code, test it in a whole host of browsers old and new and then do your best to minimize the huge bandwidth which will be used for downloading it. Then you realise that for all your efforts most of your visitors have disabled Javascipt becuase it is used in those annoying popup Windows.

It is usually safe to assume that the majority of your users will support the Javascript 1.1 specification making it the reality that Javascript is only good for a bit of client side field validation.

This is probably why websites now rely mainly on server side technologies such as PHP and ASP.

[Spajeoly]

I wont use it outside of work, but at work, it cut my job time doing retarded reports from 4 hours to 10 minutes.

[numtel]

I like vba, it adds a lot of functionality to the microsoft office applications

[kovan]

Originally posted by numtel
I like vba, it adds a lot of functionality to the microsoft office applications

i secone that thought,

not only to microsoft apps but others
like Great Planes..
o wait microsoft bought them too recently

vba is good for what it was designed for

[nemaroller]

Originally posted by visualAd

Javascript would be a great language if it was fully supported by all web browsers. To garuntee a script that will work in the vast majority of web browsers you need to write reems of code, test it in a whole host of browsers old and new and then do your best to minimize the huge bandwidth which will be used for downloading it. Then you realise that for all your efforts most of your visitors have disabled Javascipt becuase it is used in those annoying popup Windows.

Well, we write web apps, so when potential customers ask what browsers will it work with, we say IE 5+. If they have a problem with that, we tell them to move on.

It makes the javascripting just a little less painful.

[visualAd]

Originally posted by nemaroller
Well, we write web apps, so when potential customers ask what browsers will it work with, we say IE 5+. If they have a problem with that, we tell them to move on.

It makes the javascripting just a little less painful.

That's a little suicidal. Its like opening up a shop and saying to your customers you can't go inside unless you have a blue car.

[nemaroller]

Originally posted by visualAd
That's a little suicidal. Its like opening up a shop and saying to your customers you can't go inside unless you have a blue car.

More like you must be at least 5' 9" to ride this train.
Remarkably, our clients don't seem to mind. And these are large well-known household-name clients.

For the most part, I think because IE5+ has the best support for client-side processing, and thereby reduces the traffic on the network, the clients are all for it.

I don't know how many of them realize MS stopped supporting IE for unix... but hey, not my problem.

[l3g4to]

VBA is a decent tool for the purpose it was created for - simple Office automation tasks... You can't compare it to other programming languages just like that... If anything Javascript is closest to be compared with VBscript and VBA and it is c**p compare to VBA IMHO - with anonymous functions and all.

This topic keeps coming and going with many "predicting" VBA being dead:
http://analystcave.com/vba-dead-whats-future-vba/
http://dailydoseofexcel.com/archives...a-development/
http://www.crazyontap.com/topic.php?TopicId=66147

I am curious... if MS removed VBA what would you expect it to be replaced with? Having to install Visual Studio and running scripts in VB/C#.NET?

On the other hand no one can't argue that VBA needs some enhancing/upgrade... the VBA Project environment smells of the 90's.

[Shaggy Hiker]

You resurrected a 13 year old thread. That's a solid chit-chat move.

It's kind of interesting to read what people were saying about JS that far back. It's become so much better adopted and used, by now, but it was not back then.

You don't need VS to write .NET and you never did. There was some talk of replacing VBA with .NET a few years back (like maybe 10, perhaps), but not so much anymore.

[nemaroller]

You resurrected a 13 year old thread. That's a solid chit-chat move.

I fully expect to receive an email about a reply to a 30 year old VBForums thread down the road, and hope to see you there to reflect how technology changed. It is quite possible that in 30 years, all 'coding' will be done by the deep brain cloud, which of course, won't code in any of this nonsense people created. I just hope to reach retirement before it replaces us all.

[passel]

July 1977
Players, my Dad, and a professional programmer who worked at the large manufacturing firm he was employed by at the time.
Dad: My son is starting to learn about computers and wants to be a programmer.
Programmer: That's a dead end. They are developing software that will soon have the users specify the requirements and the program will be automatically created and run without the need for programmers.

Almost 40 years and counting. Fortunately, I liked programming for the programming, so didn't really matter what the forecasters said. The work and being paid for it is mostly a bonus.

[Sitten Spynne]

I think it's worth noting that, like "Is VB6 still OK?" this is a question that's going to keep coming up.

I don't think the VBA language itself is "bad", but it lacks a few things that make JavaScript and other, newer, dynamically-typed languages more convenient. Part of the problem with VBA is it isn't dynamically typed, it's a late bound statically typed language. That makes creating classes an affair that requires more up-front work, like in big brother VB. And it has to interface with COM's memory management, which requires a decent bit of thought to get right.

But the average automation project starts its life in prototyping, where you least want to be doing up-front thought. You want to get a lot of things done quickly, then step back and formalize the prototype code if it's not a throwaway. In JavaScript, you're free to create some random object and add properties/methods to it as you see fit at runtime, because 'object' is synonymous with 'dictionary'. In VB, you can't add properties to things on the fly, you have to go update the type definition.

What I mean is VBA is better at rapid prototyping than VB, but it's still not very good at it compared to several other choices that exist today. When it was developed, maybe JS was around, but in that context I can understand sticking with VBA over JS. In today's world, it's insane. It feels like MS was once very good at leaping ahead of the curve and defining what the future would be. Now, saddled with the burden of compatibility promises, they can't even keep up while strapped to a rocket. They're only allowed to do something "new" and "exciting" if it doesn't rock the boat. The boat capsized and sank in about 2008.

I think that makes JS a strong answer to, 'What could replace VB?'. It can play the part of Perl and let you write nightmare constructs when you aren't really sure what you should be doing. And when you're ready to apply some discipline, it has a complex enough type system to facilitate good practices. If you haven't been asleep, you might've noticed Office works on the Web, Mac OS, iOS, and Android now. None of those platforms support VBA, but all of them support JS. I'd be willing to bet in the next few years MS is going to unveil a JS automation API for Office. They've already dabbled with HTML/JS as an application platform on the WPF side. That tells you they've at least prototyped it.

Plus also, tons of devs understand JS. A much smaller subset understand VBA, and a big subset doesn't want to touch anything like VB out of superstition.

The hangup is they somehow have to recreate the COM API in a way that's both sensible to access from JS and familiar enough that VBA developers won't result. They've got a slight advantage in there's still not a really good competitor to Office for angry mobs to jump to. What's more likely to happen is the enterprise deciding "Well we'll just run Office XP forever and never upgrade." That's risky, and unsustainable.

It feels to me the conversation in these threads usually involves a lot of, "Well I'd lose my job if that happened so I'm angry you'd suggest it." I don't like the thought of losing my job either. That's why I dip my hands into other things every now and then, just in case I can save myself by changing my title.

I'd normally say, "I don't want VBA to go away", but I actually do. The automation API is a mess, and COM feels very rickety from the viewpoint of a developer who didn't grow up using it. We'll all be a lot better off with a new iteration.

[Shaggy Hiker]

AWESOME! I was going to mention that resurrecting an old thread might cause a lost soul to revisit. This one brought back Nemaroller!!

[Shaggy Hiker]

I think that makes JS a strong answer to, 'What could replace VB?'. It can play the part of Perl and let you write nightmare constructs when you aren't really sure what you should be doing. And when you're ready to apply some discipline, it has a complex enough type system to facilitate good practices. If you haven't been asleep, you might've noticed Office works on the Web, Mac OS, iOS, and Android now. None of those platforms support VBA, but all of them support JS. I'd be willing to bet in the next few years MS is going to unveil a JS automation API for Office. They've already dabbled with HTML/JS as an application platform on the WPF side. That tells you they've at least prototyped it.

Heaven forfend!!

JS is a nightmare language compared to VBA. It gives you plenty of rope with which to hang yourself, and even ties the knots for you. All that versatility means that you are only really productive if you are really disciplined when writing, which is not what VBA was intended to require.

They've got a slight advantage in there's still not a really good competitor to Office for angry mobs to jump to. What's more likely to happen is the enterprise deciding "Well we'll just run Office XP forever and never upgrade." That's risky, and unsustainable.

Having used LibreOffice a bit, I'm not sure that I'd agree with that statement. Apache OpenOffice is also a contender, though due to the oddities of Open Source licensing, OpenOffice can feed LibreOffice, but not vice versa.

[dilettante]

I guess I shouldn't be surprised to see that people still confuse WinRT and WPF at this late date.

WPF is not used at all in Metro/WinRT. There are two different though similar markup languages that are both being called XAML just to lure in the gullible. However it doesn't apply to Metro crapplets made using HTML5+JScript where HTML is the UI markup language.

[FunkyDexter]

This internet thing'll never catch on

[dilettante]

Climate deniers! Oh well.

In the meantime Anders is still at it, trying to put his stank all over JavaScript by front-ending it with a private macro language:

TypeScript 1.8 Hits Beta

Maybe that'll be used to try again in the wake of the massive fail known as VSTA/VSTO?

[Shaggy Hiker]

Actually, that's an evolutionary move. Javascript, as it stands, pretty much sucks rocks. The purpose of a language should be to assist in taking a concept and turning it into working code. A language can help with that or it can hinder. JS is more the latter than the former, and it doesn't need to be that way. The prototyping concept is fine, the ease with which you can totally mess up is stupid. If I have an object with a member called Species, and one time I type it species...yeah, that's totally legal, but 99.9% of the time it is also a mistake. Any reasonable IDE could point out that it is probably a mistake, while allowing it to happen if it isn't, but that's not the JS way. Instead, if it is legal then it's legal and that's all there is to it. Of course, that particular complaint is largely about the IDE, but that's all TypeScript is anyways.

TypeScript emits plain JS that is exactly the same as what you could write yourself with a set of standards and a bit of discipline. In that way, it is more like a high level language over machine code: You could have written all the same stuff in ASM, but you didn't, largely because ASM doesn't help you at all, but just makes it harder to write good code (and machine language is even worse in that regard).

I expect that the people who write in JS will eventually become like the people who write in ASM: Insufferable, yet less productive.

[NeedSomeAnswers]

I think it's worth noting that, like "Is VB6 still OK?" this is a question that's going to keep coming up.
..........
..........

What i like about your posts Sitten, is you never post a sentence if a few paragraphs will do the same job !

This internet thing'll never catch on

Whats that then?

[Sitten Spynne]

I could say a lot about why I like JS, and if people were writing code more like the Agile/testable movement advocates (which is really their contribution, not the process) then VB starts to feel like its type safety gets in the way.

It's kind of moot, though. I think what Office needs more than a new language is a new automation API. The boilerplate .NET for Excel interop reminds me of the boilerplate for a "Hello World" app in C, it's just as impenetrable for a newbie, and it's just as catastrophic if you get a tiny bit of it wrong. I don't really care which language they choose, but I think the reason they're so reliant on late binding is because COM demands it.

VBA doesn't suck any more or less than JS. In the hands of unskilled developers, every language is some degree of terrible. But the Office automation API almost demands a usage pattern that's more Goofus than Gallant. If it's hard to do the right thing when you have skill and discipline, expecting newbies (especially "not a programmer" newbies) to work with it is cruel.

[FunkyDexter]

Why do you say that type safety gets in the way of Agile? I don't think I've ever heard that assertion before.

[dilettante]

Agile software development

[dilettante]

Another look at Agile

[Shaggy Hiker]

Man, you're down on that, too?

Well, it is a bit of a fad, but we don't have an excellent solution, so why not try a fad?

[dilettante]

"Methodologies" begin with people trying to solve some problems in software development. Sadly these often turn into medicine shows where there are usually pricey books and consulting tours where somebody takes the prior work, distorts it, and then makes outlandish promises.

Then this is taken by shops, comprehended at some minimal level, and applied as a religion. The motivation is usually one of desperation to create silk purses out of sow's ear teams.

The result is pretty much what you'd expect.

There is no substitute for good requirements gathering, deep programming background, reasonable testing practices, and lightweight project management. No imperfectly understood ritual practices can make up for the lack of these things.

Sadly these days any low-ball coder who can get "Hello World" to work seems to get hired, and then in desperation people sell their souls to these traveling shows.

See a confession:

Software Engineering: An Idea Whose Time Has Come and Gone? (pdf)

[Shaggy Hiker]

By the time WE hear about them, they are ALL medicine shows. Somebody finds something that works for them and they use that. When they decide that both it is THE solution, and they are interested in spreading the gospel, that's when the rest of us hear about it. Up until that point, every single coder has a methodology (good or bad). It takes some proselytizing to change it from a methodology to a Methodology, so all we see are the medicine show stage.

Still, there are some aspects of agile that do make sense to me. I have never found a case where a design of more than trivial complexity couldn't be improved upon, and couldn't be improved upon by input from knowledgeable others. So, I would say that while agile is still an example of groping in the dark, it's at least groping in the right direction.

[dilettante]

Ahh, but "aspects of Agile" are not Agile and probably not unique to Agile anyway. For example everyone agrees that breathing is a good thing, the fact that Agile doesn't (yet anyway) rule out continuing to breathe is very little to its credit.

However Agile is similar to the newer medicine show called "DevOps." Similar in that dumping more unskilled voices into the pot will somehow magically create success.

You can have great success combining the two as "Agile DevOps." What does this mean?

It is a social engineering tactic that involves cosying up to the users and the operators ("admins" - oh I can hardly keep a straight face) to get buy-in. It does mean some wasted time implementing crackpot notions and making them take part in testing so they can see what lunacy they are so you can rip them back out and reach successful results. The trick is to implement and discredit as many of their wacky ideas as early as possible, after which they're just along for the ride and mostly sit quietly.

You get information you need out of the users about actual requirements that they are too illiterate to express in writing, and you get resources out of the uneducated "certificated" box jockeys.

Be sure to hand out badges, pizza parties, etc. all around and issue status reports praising their roles and contributions to the effort.

Smarmy? You bet. This why some burn out and others take to drink or vanish into the woods and start eating mushrooms though a few thrive on it and eventually run for political office.

[Sitten Spynne]

Why do you say that type safety gets in the way of Agile? I don't think I've ever heard that assertion before.

It's a bit philosophical.

While I'm writing C#, I'm constantly thinking about types, even when my code units are small. This line of code can go a lot of different ways based on the types involved:

var c = a / b

Are a and b integers? What if one is a double? What if one's a double and the other's a single? Do I want an integer result? Type inference is a convenience, but in "int Foo()" I have to guarantee by the end of the function that c is at least implicitly castable to an int.

That sounds not so bad, but only because this is a trivial example. This little nightmare's been bothering me lately in a SQLite library I use:

Function ExecuteScalar(query As String) As Object

It returns the first column of the first row of the resultset from the query. Good so far. But that can be a double, long, string, DateTime, or probably some other value I haven't encountered yet. Obviously I wrote the query when I call it, so I have some clue of what it is. But I never expect it to be a long, and always get burned by the cast.

In JS, I'd expect "a number". And I'd treat it like "a number". And if it gets a string back, it's going to bomb at runtime just like it does in C#. Except if for some crazy reason I go from "250 rows is a lot" to "6 billion rows isn't much", I don't get blindsided like I would in .NET when an API chooses Int32 where Int64 should've been used (like array length).

It's a very strange situation if all you've ever done is static typing because while you're in that state, it feels like you're catching so many errors. But all I notice now after writing some JS and Python is how often a C# "Unable to cast..." error represents some situation that would never be an actual runtime error in my code. And how many other times it's caused by getting caught up in vagaries of <TGeneric, TType, TParameters> and having to please some arcane god. It's not the kind of thing I can demonstrate in a trivial example, it's more like "At the end of the day, I feel like I waste 2-3 minutes out of every hour dealing with type safety and it's always a goofy "oh this API returns long and you used an int shame on you" when I logically know the value's going to be within Int32's bounds and sort of want to die if I get something out of that range.

I feel like dilettante has been burned by what usually passes for "Agile", the thing you get when management reads books and implements scrums and is actually too afraid to do the things that really make Agile. When I see this:

There is no substitute for good requirements gathering, deep programming background, reasonable testing practices, and lightweight project management. No imperfectly understood ritual practices can make up for the lack of these things.

I totally agree. But then I scratch my chin and can't figure out why he puts that up as "better than agile". Everything past requirements gathering is key to operating on an agile team. You don't do deep requirements gathering because the process is designed for a world where the customer doesn't know what the hell they want, and if you sit and ask them you'll get a different answer every day. So you make something and ask them what's wrong with it. Then you fix that and try again. And you keep going until you're close enough to finish that deep requirements gathering because there's not much of a gap remaining.

If what you write is well-defined and you can get requirements out of your customers, then cool, use a methodology that requires up-front design. My customers haven't signed a contract yet, and I can't ask them what they need until they're already customers. That involves a lot of rapid prototyping based on pre-sales interviews and being prepared to trash a feature if I get it wrong. Sometimes the sales guys even remember to let us do that prototyping before promising it to the customer. We can't afford multi-week requirements gathering missions, we prefer to deliver prototypes and ask the customer to tell us what parts hurt.

This part I agree with:

Then this is taken by shops, comprehended at some minimal level, and applied as a religion. The motivation is usually one of desperation to create silk purses out of sow's ear teams.

'Agile' isn't magic voodoo that turns a team of nobodies into superstars. It's an idea about approaching requirements as unknowns, and only investing in architecture as you start to clear the fog. I'd sure as heck prefer up-front design, but I think I'd be bored to tears in the world where every project has clear requirements from the get-go.

I think, metaphorically, the way to discuss whether scrum meetings and this or that process makes a shop "Agile" is similar to this I found in an old .txt file about karate I found as a teen:

The person who has earned it realizes that the true purpose of a Black Belt is to hold up one's pants.

A certification means you took a class. Delivering software on schedule in the face of unclear requirements means you're agile. You can print a lot of certificates in a day. You can't ship that many products, especially if you hustle.

[Shaggy Hiker]

I'd have to say that I feel quite unconvinced by that argument. It seems more like personal perspective, which I find reasonable, but don't share.