So I gave a dev a choice yesterday
-
I've done a bit of tinkering with macros in excel, but it was very basic stuff. I wouldn't claim to have any knowledge of VBA. I'm astonished that both your devs picked documentation over writing code. I'd be jumping at the excel macros to avoid doing documentation. [edit]Ok maybe we need a sarcasm smiley? (maybe we have one that I'm not aware of?)[/edit]
Pete
Peter Mulholland wrote:
I'd be jumping at the excel macros to avoid doing documentation.
Yep, chew the leg off rather than doco, I have so many creative ways to get out of doco I have not needed to delegate it for some time.
Never underestimate the power of human stupidity RAH
-
We had a requirement that needed someone to write some VBA macros in Excel (2003) yesterday, both devs on the team denied any knowledge of VB/VBA/VB.Net I gave them a choice of doing the job in VBA or documentation, we should have some great manuals for this project. I was astonished that a person who calls himself a developer has no knowledge of office or macro programming, I thought we all got dipped in that stuff at some time.
Never underestimate the power of human stupidity RAH
A lot of devs sneer at VBA, but that's mainly because they've never seen just how bluddy useful it can be to people who USE COMPUTERS, rather than spend all their computer-time writing code or playing games. Mind you, finding a dev who can edit a document in a word-processor without screwing the settings/structure/formats up is like finding gold in your bathroom, so finding one who has had experience in making documents even more useful/functional through judicious use of VBA won't be so easy. That said, any dev who says he won't be able to work with VBA, one of the easiest languages to program in, shouldn't be allowed to work with any of the "more difficult" languages until he's proven his mastery of VBA.
I wanna be a eunuchs developer! Pass me a bread knife!
-
The last BASIC I did was on a Commodore 64.
Every man can tell how many goats or sheep he possesses, but not how many friends.
ChrisElston wrote:
The last BASIC I did was on a Commodore 64.
For me, it was a TI-99/4A - good old TI-Basic! :-D
-
We had a requirement that needed someone to write some VBA macros in Excel (2003) yesterday, both devs on the team denied any knowledge of VB/VBA/VB.Net I gave them a choice of doing the job in VBA or documentation, we should have some great manuals for this project. I was astonished that a person who calls himself a developer has no knowledge of office or macro programming, I thought we all got dipped in that stuff at some time.
Never underestimate the power of human stupidity RAH
If you prefer Python you could do anything you can in VBA with PyXLL (www.pyxll.com)
-
We had a requirement that needed someone to write some VBA macros in Excel (2003) yesterday, both devs on the team denied any knowledge of VB/VBA/VB.Net I gave them a choice of doing the job in VBA or documentation, we should have some great manuals for this project. I was astonished that a person who calls himself a developer has no knowledge of office or macro programming, I thought we all got dipped in that stuff at some time.
Never underestimate the power of human stupidity RAH
VBA is where I started programming on the Windows platform. After watching people needlessly re-entering the same data over and over in Excel, and believe it or not I saw people using a calculator to add up the entries in a spreadsheet. They were trying to “train me” on the tracking system doing it this way. After one day, I found that all this tedious mind numbing data entry and calculation was really all just a way for them to make pretty print outs for other people to use to enter the same data into another spreadsheet. I started by recording macros and digging into them and automating them. I could do in 15 minutes what would take them a day and a half to complete and it looked better. I got a $500 spot award for doing this. I was hooked on VBA. I am with a lot of the other posters here, I don’t understand the hatred for VB and it’s variants. It is a very useful tool in the hands of someone who understands how to use it, just like any other programming language. The only problem I do see with it is the very forgiving nature of VB when it comes to variant types, mistakes can be very easily made when mixing and matching types. (I do occasionally take advantage of this when it comes to string handling, everyone knows what a pain it is converting string types in C/C++) . I have seen abuses in every language, the posts I see here in the forums every day reveal some of the finest displays of programming ignorance ever presented but luckily there are just as many bright wonderful folks who are willing to set them straight that’s why I come here. :) My 2cents.
It was broke, so I fixed it.
-
We had a requirement that needed someone to write some VBA macros in Excel (2003) yesterday, both devs on the team denied any knowledge of VB/VBA/VB.Net I gave them a choice of doing the job in VBA or documentation, we should have some great manuals for this project. I was astonished that a person who calls himself a developer has no knowledge of office or macro programming, I thought we all got dipped in that stuff at some time.
Never underestimate the power of human stupidity RAH
What kind of developer chooses documentation over development?
-
Aside from all the arguments about the faults with VBA, I really don't understand the antipathy towards it (other than from a language design POV). At the end of the day (and I don't want to rekindle the religious language wars here!) a programming language (however good or bad) is a tool - you can do a good (or bad) job with it regardless of its nature. For lots of scenarios, using the built-in (ie VBA) when producing something for a client in Access or Excel makes much more sense than developing a full-on, multi-user, mathematically proven system based around MS SQL on Server 2008 using C#/LINQ etc, especially when all they wanted was automated production of a report based on a few figures in a spreadsheet. As my father used to say: "A bad workman always blames his tools..." 8) There's far too much "over-engineering" in the software development world, it seems to me...
-
The clue is in the filename .xls. I've encountered this usage innumerable times, at various clients - I'm actually surprised its new to you. I have a vague memory it may even have been in the icon at some stage (just checked it still is - the X with one foot extended to an L).
-
A lot of devs sneer at VBA, but that's mainly because they've never seen just how bluddy useful it can be to people who USE COMPUTERS, rather than spend all their computer-time writing code or playing games. Mind you, finding a dev who can edit a document in a word-processor without screwing the settings/structure/formats up is like finding gold in your bathroom, so finding one who has had experience in making documents even more useful/functional through judicious use of VBA won't be so easy. That said, any dev who says he won't be able to work with VBA, one of the easiest languages to program in, shouldn't be allowed to work with any of the "more difficult" languages until he's proven his mastery of VBA.
I wanna be a eunuchs developer! Pass me a bread knife!
Mark Wallace wrote:
Mind you, finding a dev who can edit a document in a word-processor without screwing the settings/structure/formats up is like finding gold in your bathroom
The same is true of 99% of users who try to apply any formatting to their documents. The difference is that if you point a competent dev to the styles gallery/editor and explain that to avoid screwing the document up that they should use styles similarly to how they use basic CSS instead of font tags then they'll be able to do fancy without trouble in the future. Try doing that with an MBA or someone holding a program managment certificate. :doh:
3x12=36 2x12=24 1x12=12 0x12=18
-
The closest I ever came to VB/VBA/.NET were my (partially successful) attempts at integrating Excel table views in an application using OLE2, some 15 years ago. It was a nightmare, as all variables were declared 'Variant'. and there was no explanation at all anywhere in the documentation that told me what actual types were expected, what each parameter meant, and in what order they were supposed to be passed. There weren't even parameter names in the documentation that you could base an educated guess on, it was just trial and error! Note that I was using both the official documentation (i. e. the Excel help files) and a pair of very insightful 'behind the scenes' books about OLE2, but as I said, there were no parameter level explanations to be found anywhere at the time! Not to mention that quite a few functions weren't defined as described in the documentation, were varying dependend on the actual OS version, or delivered different results. Based on that experience you can imagine I avoided any successor of that abomination like the plague, be it COM, VBA, or .NET. (and sorry: anything that got 'Basic' in its name isn't considered a programming language by me) I realize that the documentation and the stability of the interface got to have improved in the meantime, but I still nourish a strong loathing for anything in that direction. Thankfully I was never required to touch any of this again, not even with a hot poker. So no, I do not have any knowledge of VB(A)/.NET either. I've programmed in C++ when compiling still required two steps and templates weren't fully supported, long before the time of OLE and it's successors, and I'm still programming in C++ today, knowing that most of today's C++ programs could be compiled with compilers written 20 years ago. Call me conservative if you want to, but I don't like proprietary, platform dependend languages that change every time time the OS or Office version changes.
Stefan63 wrote:
knowing that most of today's C++ programs could be compiled with compilers written 20 years ago
Wow, your usage of C++ must really be avoiding the "new" features then. Template support back then was crappy to put it mildly - and IMHO to ignore templates is to miss the one really good thing in C++. Forget the "class" in C++, its the keyword "template" that makes it powerful. There is other stuff that's changed in that time, but the template differences have affected almost every part of the standard library for the better - strings have been vastly improved, STL and BOOST all rely heavily on these. Even books like "Modern C++ Design" by Andrei Alexandrescu came out in that time frame.
-
You wouldn't hire me. I wouldn't let you. I've actually programmed about 2000 lines of it but I disavow any knowledge of it (except for here of course). ;P I know about 100 programming languages and vba is one I'm happy to put behind me.
Hello, this is the business. We have a user who needs to automate a few things in excel. You can either spend 3 months writing custom code that duplicates 20% of the functionality of spreadsheet software plus this user requirement, or spend a day writing a few quick routines in VBA. ... oh... you don't huh. That's too bad.
-
As an accountant, XL is the base level, so therefore I need people who know it. I am an XL guru, not just macros, but vba too. I only employ people who are at least macro level.
------------------------------------ I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC Link[^] Trolls[^]
LOL nobody says XL for Excel.
-
LOL nobody says XL for Excel.
-
Caught the ruse after I hit the post button... Good one :laugh: p.s been coding and writing docs for years...
I know this is rapidly heading off topic, but I love writing documentation - especially functional specs. It gives me a sandbox to think through all of the behaviors of a piece of software before I lay down the first bit of code. I'm always amazed at the necessary bits that float up while I'm writing. Writing user documentation is great, too. It helps me spot ways the app can be streamlined for usability. Documenting workarounds for bugs deep in the queue helps me sympathize with user frustration, too. "... your figures should be in the right column, but they have disappeared. This is a bug, but there is a workaround. To get the figures to display, open and close the print preview." X|
-
Stefan63 wrote:
knowing that most of today's C++ programs could be compiled with compilers written 20 years ago
Wow, your usage of C++ must really be avoiding the "new" features then. Template support back then was crappy to put it mildly - and IMHO to ignore templates is to miss the one really good thing in C++. Forget the "class" in C++, its the keyword "template" that makes it powerful. There is other stuff that's changed in that time, but the template differences have affected almost every part of the standard library for the better - strings have been vastly improved, STL and BOOST all rely heavily on these. Even books like "Modern C++ Design" by Andrei Alexandrescu came out in that time frame.
Rob Grainger wrote:
Wow, your usage of C++ must really be avoiding the "new" features then
Not at all, to the contrary. I'm liberally using templates all the time. I've expressed myself not very well it seems - I wasn't referring to the state of C++ around 25 years ago that I intially described, but to C++ compilers 20 years ago, i. e. around 1991, which were already much better and had full support for templates, with very few exceptions, and one-pass compilation. These compilers should be able to compile most if not all of the STL (although they'll likely get stumped by the boost library) Note that at that time, even though the ANSI standard for C++ wasn't released yet, most of it was already supported by compilers.
-
We had a requirement that needed someone to write some VBA macros in Excel (2003) yesterday, both devs on the team denied any knowledge of VB/VBA/VB.Net I gave them a choice of doing the job in VBA or documentation, we should have some great manuals for this project. I was astonished that a person who calls himself a developer has no knowledge of office or macro programming, I thought we all got dipped in that stuff at some time.
Never underestimate the power of human stupidity RAH
-
We had a requirement that needed someone to write some VBA macros in Excel (2003) yesterday, both devs on the team denied any knowledge of VB/VBA/VB.Net I gave them a choice of doing the job in VBA or documentation, we should have some great manuals for this project. I was astonished that a person who calls himself a developer has no knowledge of office or macro programming, I thought we all got dipped in that stuff at some time.
Never underestimate the power of human stupidity RAH
-
The single biggest problem is that VBA's IDE is a masochists paradise.
3x12=36 2x12=24 1x12=12 0x12=18
Too right. I've been tasked with working on some Access VBA code for my sins, and the IDE drives me crazy. It can't seem to tell the difference between field names (which are ALLCAPS here) and variable names (camelCase or InitialCaps depending on scope), or between names at different scopes, so the IDE just randomly chooses one and makes everything throughout your project match that. It drives me frickin' crazy - earlier I actually added a new class (Class Module), the name of which didn't overlap anything in the project, called it, ClassName and VBFA (VB Frickin' A, its new acronym) decided that that should CLASSNAME - this is a new class. It's about time Microsoft put the poor beast out to pasture and replaced it throughout the office suite with a .NET based scripting environment. That way you could use C#, Ruby, Python, or even, god forbid VB, at personal/project manager preference.
-
Rob Grainger wrote:
Wow, your usage of C++ must really be avoiding the "new" features then
Not at all, to the contrary. I'm liberally using templates all the time. I've expressed myself not very well it seems - I wasn't referring to the state of C++ around 25 years ago that I intially described, but to C++ compilers 20 years ago, i. e. around 1991, which were already much better and had full support for templates, with very few exceptions, and one-pass compilation. These compilers should be able to compile most if not all of the STL (although they'll likely get stumped by the boost library) Note that at that time, even though the ANSI standard for C++ wasn't released yet, most of it was already supported by compilers.
Really? In 1991? That's back when the latest Microsoft Compiler was C 6 (not C++ 6, Visual C++ 1.0 came out in 1992). Turbo C++ and Zortech C++ were the best compilers for DOS platform, neither of which had any support for templates at that stage. STL was still under development at the time, and AFAIK most compilers that did support templates had to be reengineered to avoid breaking, it was some years later before everything started supporting templates efficiently. I remember reading an article about template metaprogramming in, I think, Dr Dobb's, at time - the classic calculate a factorial and report it in an error message example. At that stage, none of the compilers they tried could support it. You must have been very lucky to be developing on a platform with such advanced C++ support so early, the rest of us took a fair few years to catch up. Even VC++ 6 (that 6 compilers later from Microsoft) still failed to have decent support for STL - breaking any implementation I tried, until MS released one (in a Service Pack if I remember correctly).
-
Aside from all the arguments about the faults with VBA, I really don't understand the antipathy towards it (other than from a language design POV). At the end of the day (and I don't want to rekindle the religious language wars here!) a programming language (however good or bad) is a tool - you can do a good (or bad) job with it regardless of its nature. For lots of scenarios, using the built-in (ie VBA) when producing something for a client in Access or Excel makes much more sense than developing a full-on, multi-user, mathematically proven system based around MS SQL on Server 2008 using C#/LINQ etc, especially when all they wanted was automated production of a report based on a few figures in a spreadsheet. As my father used to say: "A bad workman always blames his tools..." 8) There's far too much "over-engineering" in the software development world, it seems to me...
