Argument against business process expression languages

After a long awaited vacation, I'm back in office, It has been a refreshing experience. The next thing I see is myself getting invited into a meeting room and being shown assigned to a team dealing with work-flows. These are my first thoughts after looking at what I have in my plate...

The most interesting thing about workflow software, is the ability to plug-in custom rules. They are highly configurable and customisable. Typically every workflow consists of series of acitivities with transitions connecting them. There are business rules written on top of these, which essentially dictate the life-cycle of the flow. In addition to this, there is a provision for forms (for user interaction). There is a strong constraint (what can/not be done) on the usage of these. These contracts/interfaces are designed for the most specific purpose of writing/wiring processes and come with a GUI designer. This provides superb illustration of what is happening where. So what is that, which struck a wrong note?

The entire suite is designed with the noble intention that non-techie folks can use them. So the language is designed to be declarative (in the sense you specify what is needed and don't dictate how it is accomplished). There is an editor which assists in writing code using this syntax. This whole thing assumes that programing in general purpose languages is tricky and meant for programmers alone, (Utterly wrong IMO). Any imperative language is same in the sense, you have assignment, conditional and looping constructs. Some are better in that they provide rich data structures and memory management. A language meant for writing rules tries to emulate these in a more elaborate form. Did the authors ever heard about 3rd generation languages like BASIC and COBOL? They were supposed to be user friendly (read like english).

I have to strongly disagree with the 'noble intention', one may ask why?, the answer: I am not a business analyst and I am being asked to fix defects in code written with myriad syntax! If it were so easy in the first place, the analysts themselves would fix them, why me? Isn't it the case where magic turns into mayhem? Why invent a language instead of specifying a framework with a strong contract?

I may be complaining out of frustration, but I am not yet speaking of my inability to customise the UI, or introduce some kind of pattern for the sake of consistency. Understanding a moderately large workflow (not authoring) itself is taxing. I will probably need another break, so when is my next vacation...