So I gave a dev a choice yesterday
-
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...
-
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
I thought much the same until I tried to setup some numbering based on Heading levels (style-based) in Word 2007. It is possessed, despite Microsoft's protestations to the contrary (Blogs.Office.Com[^]). That they felt the need to write an article titled that way is condemnation itself. Numbers change to letters, indentation flies halfway across the page. You get it "working" save, and reopen a document to find everything screwed again. I've been using Word since Word for Windows 1.0, and VBA with it a fair few years. All all started going wrong post Word 6, when they started "intellisensing" too much - adding styles because you'd made a stretch of text bold and the like.
-
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.
-
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).
I was programming C++ code on Sun workstations starting in 1986, and even though template support was all but non-existant, the compiler prototypes provided to the research institute I was working at could indeed 'understand' some very basic template constructs. I do remember having had several discussions with a tutor about constructs the CPP frontend didn't understand which should have worked by the book. My understanding was the CPP frontend was only used in some universities at the time, mainly for educational purposes. Much later we got updates to the CPP frontend which was able to do multiple passes over the code instead of just one, and thus could recursively resolve nested template arguments. That was in the late 80s, I think about 1988-89. That version was very close to full template support. I got a new job at a software company in 1991, and the project I was working on then did liberally use templates; this was the first time I really used templates to their 'full' potential (or rather, to the limits of my uderstanding ;) ) I do not recall any restrictions on the use of templates our compilers imposed on us, that is why I say these compilers should have been able to deal with todays C++ code. (platforms were HP, Sun, and Spark workstations btw., not PCs)
-
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
I think most of these replies miss the main point - VBA is easy, whether it is ugly or not. Any developer that can't figure out how to hack up some macros in Excel isn't worth squat. It is designed to be used by non-programmers, and I know plenty of accountant types that can throw together a macro (usually starting with the record function and tweeking from there) - so if someone calling themselves a programmer cannot figure it out, they should find a new occupation.
-
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...
Yey, one can still develop against excel without using any vba at all... So, yes, I pass...
