- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Also, if the business logic for cancelling orders changed, then the data in that column would be WRONG. It would also get backed up to tape. Importing old data would require you to correct the values using the new business logic.
Besides which, it wastes space ;-)
Admin
...
Admin
Of course, you don't continually update the database each time you are evaluating this expression! Why the heck would you think I am saying that?
I understand that the final value for whether or not you can cancell the order is based on not only the Order Status but also some other value (as Alex points out) but that does not stop you from indicating, in the database, which order status's are cancellable as opposed to explicitly listing them out in your code!
A simple
IF (OrderStatus.IsCancellable AND ... AND ...)
does the trick. This allows you to change order status codes as needed, and as long as you maintain their attributes properly in your database, your application logic does NOT need to change. If you hard-code everything, then you need to change it everywhere and re-compile your app.
So, again, the ultimate return value from some function that determines at any point in time whether or not something might be valid certainly must occur in the application, but you should use attributes liberally in your data to keep that application logic short and focused.
As I mentioned before, see my blog entry for more details if this doesn't make sense. You might be surprised if you really stop and think how much data we often store in your code when you have a perfectly good database that does a pretty good job of storing data!
Admin
defining business rules in a language outside that of the core app is always necessary in certain fields and definitely not a wtf, unless you think teaching C# to legions of non-technical analysts is a good idea, in which case you won't be around for long.
the wtf is... where is the language? the programmer clearly knows enough about languages to write an AST, but elects not to write a parser? w. t. f.
Admin
You (among others) seem to be misreading the original comment as "IsCancellable is an attribute of an Order", which would indeed be a WTF.
IsCancellable could be stored in an OrderStatus table, in which case the original logic would change from (OrderStatus in this hard-coded set or user is privileged) to (OrderStatus has IsCancellable = true or user is privileged).
The "no one should be browsing the database" argument isn't necessarily correct, either - the company might want to customize the application logic to cover what they want to restrict - provided that only the appropriate users are given update privileges to the OrderStatus table.
Admin
Oh god, I'm having flashbacks...
I once had to write a system a where the "rules engine" was a collection of Excel spreadsheets, which we had to call (synchronously with the web request) to compute billing rates, etc.
So what happened, you ask?
Apart from sucking ass to write and piss-poor performance, the people writing the "rules" would change the structure of a spreadhseet and the system would blow up.
Good thing this was only to support the call center of large utility companies...
Admin
Not entirely nothing. The goggles will make you and your friends look bloody stupid at EBM/cyber gigs, especially when combined with hair extensions in Dayglo colours.
Admin
If you want your output to be machine readable, provide hidden tags to facilitate it - it's not like that's hard to do! Otherwise, that's no reason. It's just pure laziness, pure and simple. "1 replies" is just sloppy. Like a Pastor forgetting the bride's name at the wedding, it's just a bad idea.
Admin
Oh, dear me, thanks for the reminder.
I have a hacked-together Rails app I made for my own use. Right now, planning to recode it from ground up (this was my first Rails app so it could use some redesign now that I kind of know my way around this platform a bit) and planning some features that are cooler than liquid nitrogen.
Would be a good time to get back to Earth and think "wait, is it really necessary to have all this complex stuff here?"
The redesign also has one thing in common with this WTF here. It's an image archive program. You can add semantic metadata to images (think of "tags", but a bit more formal). Currently, there's a class and a database table for each metadata type. Thinking of moving all this to one table per all metadata types and adding a metadata language for expressing all this stuff. Now, looking at the WTF, I think I'm slowly slipping towards this "enterprise rules engine" direction. Thank heavens I'm writing this in a dynamic language, and still have a chance to make a choice whether or not to rewrite this thing in Ruby at all, or maybe the only real language that springs in mind for writing "enterprise rules engines", Lisp...
Admin
Wouldnt 1/3 in base-12 be .25?
Admin
Forget the post my brain was out to lunch...
Admin
Well, I don't think it's the fact that the idea of enterprise rules engines suck, rather that this is a remarkably idiotic implementation. There are ready made (and expensive) rules engines (they are all essentially pre-AI-Winter-style AI systems, studiously avoiding the "AI" zzubword) that do work reasonably well in my experience. e.g. SeeBeyond (at least when it first appeared, see below).
But if you are going to roll your own, for pity's sake you should be using a language appropriate for the task, such as Prolog or Lisp (as mentioned by several other posters). In fact IIRC SeeBeyond is/was originally implemented in Scheme (a Lispoid), though it quickly got a (somewhat clunkier) Java veneer for entrepriseness, and now that it's owned by Sun it's probably entirely enterprisey and java-y and sucky.
Admin
I was going to say, actually thats base b, but in fact it would be base 10. Whatever base you work in, its always base 10. Ho Hum.
Admin
No - you were replying to a post about exactly one 'program': this forum software.
If you were commenting on other programs as you now state, then your original second point is irrelevant rather that invalid.
And it is not obsessive to use proper language constructs when implementing a user interface. I'd term it more a matter of courtesy to the user and the language.
Admin
Now, by "base-60" do you mean "base sixty" in decimal or "base six zero" in some other base?
Admin
I think he means- base-(234*5)
Can you imagine learning all 60 digits for a base-60 number system? How about the times tables you learn in third grade-- you'd have to learn 1800 products!!
Admin
So... that works great if your code is only ever going to be outputting English. If your code ever needs to deal with i18n or l10n issues, then you would need seperate rules for every language (not all languages have "1" and "more than one" for their plural forms).
Admin
Admin
IMO this is largely a myth invented by programmers to make themselves seem like Mighty Wizards Dealing in Secrets that no Mortal could ever Fathom. For one thing, as this example shows brilliantly, the "business rules language" all too often becomes an overdesigned, verbose monstrosity that is far more error-prone and more difficult to learn than a sufficient subset of a modern programming language could ever be. Second, even if that does not happen,, it's more often than not still the programmers who end up maintaining the business rules, because the analysts can't be arsed.
The same thing holds true on the UI front, with stuff like JSTL that is supposed to keep website templates free of code so that web people who can't program can do the visual design of the pages.
Admin
I mean, even with ****ed up langues like Russian (which for numbers have 1, 2-5 and 6+) it's still only a double if.. regardless of how horrible the grammar is, when you're doing a simple select the choices will allways be limited as every language has some concept of 'many'.. you may have to put the entire sentence in the 'if' though, but it works, easily readable and easily modifiable.
Atleast, I know this will function easily enough for the Latin and Slavic languages, aswell as Mandarin.
Admin
Well you know, some code has to set the column in the table.
Admin
That's (part of) what gettext is for.
It's not exactly rocket science.
Simon
Admin
The current crop of rule engines (king of the rule engine hill - ILog included) have very little "AI" in it. All they provide is a performant order of rule evaluations (usually RETE) and a "humanly readable" language to express the rules with. Some faf with backward and forward chaining, but it's a far cry from Prolog (which has it's own share of warts if you want to use it as a rule engine). AI Winter certainy hasn't been kind to them.
SeeBeyond was an enterprise service bus. Very enterprisey, I might add. As far as I know, they never had a rule engine. I should know, as I'm a cerifited (certifiable?) SeeBeyond Associate Developer...
They had the balls to use Monk (a derivate of Scheme) for user-defined transformations of data. Fortunately, no user's brains exploded, as Monk is a rather castrated variant of Scheme and was used just as another procedural language, but with a lot of parenthesis.
The really WTF-worthy thing was their Java editor. They've decided that Monk was too hard and marketing needed few more words like "Java" in the brochures anyway. So they added Java transformations. But coding in Java is apparently so hard and good editors scarce, so they created their own visual editor. Where you had a nice little "try {}" button, which inserted try/catch block. And "for()" button. And "while()" button. And "Execute" button, with which you selected class/object and method to call.
Of course, this truly-enterprise editior saved code in an incompatible file format with their own version control system to discourage users from rolling in non-enterpriesy IDEs or version control systems.
Then they throw all away in version 5.0 and reimplemented the whole shebang in 100% pure Java, running on top of their own J2EE server.
Admin
Brilliant.
"programming languages are too complex, let's just have people manually instanciate a syntax tree instead !"
Then, they will realise that instead of writing all these unwieldy new, they can write their AST in XML.
Then, to simplify the syntax, they will replace XML with a language where each operation are represented by character symbols, with operands preceeding and following it, and with rules to decide in which order to evaluate them.
And then they will add an awesome new feature to explicitely defined the evalutation order: parenthesis.
Then, for more flexibility, they will add in some flow control structures.
At that point, they will have reinvented scripting languages. They will proceed to find it too complex and not enterprisey enough, and the circle of the WTF life will go on.
Admin
ACK! This WTF is horrible - this has ruined my entire week already. I cant possibly write crappier code than this if I tried.
Although, I do say that a Rules Engine is absolutely necessary in many situations. I've written Rules Engine processors for Stocks/Bonds trading companies and 10 years later, I still get compliments on the flexibility and useability of such an engine. Mind you, this is a VB6, COM object. Despite my gloating, a Rules Engine can make all the difference between having a developer chained to a "forever maintenance agreement", or having non-technical staff take full ownership.
Admin
No, you stop too soon!
At that point they'll think, "wouldn't it be really great to have this as a direct executable...?" so the original parsing tool is converted to a VM, the XML will be replaced by a bytecode compiler, and a couple of more stages are added onto the front of that chain: namely, a syntax tree parser and an XML file.
Oh wait...
Admin
Quote:
IsCancellable is an attribute of an Order Status.
Of course, you don't continually update the database each time you are evaluating this expression! Why the heck would you think I am saying that?
Ah, sorry, I read it as "IsCancellable is an attribute of Order". which wouldn't be a good idea, as I was arguing.
So yes, you're right. Order.OrderStatus could be joined against a small table that maps OrderStatus to IsCancellable. Not a bad idea.
(Actually, I would still argue that IsCancellable is an attribute of Order, not OrderStatus, but functionally dependant on Order.OrserStatus in the current business logic. In theory, it could be based on other attributes too, like what kind of shipping had been chosen, or whether it had reached some deadline or not)
Admin
I use this handy Java code in programs where I do this often:
/**
* Returns pluralized item.
* pluralize(1, "fung", "us", "i"); returns "1 fungus", whereas
* pluralize(5, "fung", "us", "i"); returns "5 fungi"
*/
public static String pluralize(int count, String item, String singularSuf, String pluralSuf) {
return Integer.toString(count) + " " + item + ((count == 1) ? singularSuf : pluralSuf);
}
</quote>
Huh? yeah. Almost a first post for www.thedailiywtf.com
pluralize(1, "m","ouse","ice");
pluralize(5, "m","ouse","ice");
Edwin
Admin
Hmm... The real question here is the definition of "IsCancellable". The whole point of having a Rules Engine is to make the implementation of the IsCancellable rule abstract. Perhaps the business requirement is something crazy like "If the User is a Manager or higher and the amount of the order is less than $X or if the User is in the Customer Service department and the order is less than $Y..."
This would make modeling IsCancellable as an attribute a little difficult.
Admin
Second, definitely LISP, with a mix of old Fortran or COBOL due to the whole "operator.xxx" deally.
Wow- fire the architect and the managers who allowed it.
Admin
IIRC, the Vb side already has it, so to be super-simple they could have simply written their engine "rules" in VB.net and used this method to execute it.
Also- they could easily have loaded assemblies at runtime and called methods inside those assemblies very simply, even in a separate appDomain ala a plugin architecture.
Or for Godsake grab python or whatever so that "you'll never have to recompile".
Why's everyone so f'ing afraid of compiling?
I've got the suspicion that this thing was made by the Hero developer of the company or maybe a Hero architect and everyone else was either too afraid to say, "I can barely comprehend these rules" or they never said anything, or more likely, it was foisted upon them.
Admin
My point isn't that you should replace a "rule engine" completely with database attributes. It's that your database should be storing as many attributes as possible for your entities to facilitate keeping these rules clear and simple. Order's have a "status" for a reason -- it means *something*. Why not create attributes defining those *somethings* in your database? Otherwise, the only time you can find out truly what an Order Status means is to examine all of the source code to see where the different codes are listed out explicitly.
Even redundant sounding attributes added to your order status table (i.e., "isDeleted" which is only set for the DELETED order status) keeps your code short and concise and eliminates the need to hardcode ID's or Codes into your application.
Admin
Of course I stop too soon, I'm no consultant or certified professional. I suck at that enterprisey coding thing :p
Admin
In my native language you never make the word plural if you say the amount of it.
Some examples:
without amount: replies, houses, apples, days, ...
with amount: 4 reply, many house, some apple, 9 day
Admin
Not quite...
person(P)
willReinventProlog(P, badly) :- not understandsProlog(P)
More or less.
Admin
They took the idea of a "New" version quite literally.
Admin
Rule engines are the brainchild of uneducated managers who think that the compiliation part is what makes changing a program so expensive. They have their merits if the surrounding language is ugly like C and the rule engine code is more readably, but in a high-level language like C#, Java, VB, Delphi etc. they are useless, dangerous() and performance-eating.
() especially dangerous if you forget to put the rules into the source code control system
Admin
While there is lots of discussion on how such a thing can be done better, did anyone notice that the block:
Is duplicated for both of these conditions?
So regardless of how it is implemented, it is still broken?
Peace!
-=- James R. Twine
Admin
So it's basically a scripting language designed by people trying to create something else?
Admin
But WillDoItBadly only applies to another proposition, not to an atom >:->
Admin
A stupid approach to a real problem. Longer reponses on my ebizQ blog. JT www.edmblog.com
Admin
japanese doesn't do pluralization at all... whether there is one or a million it still would be "fungus"... they don't have genders either... why not have English Sharp without those futilities... in my case it would be Frensh Sharp which can be even more convoluted than English...
Admin
We used to use that system for currency in the UK - we scrapped it in 1971. I was 7 years old, but still remember the lessons we were given at school in how to count money in base 10.
So, 1/3 = 1 shilling and threepence. With 12 pence to the shilling, this was equal to (1.25 * 12) = 15 pence. Shillings were divisable by 2, 3, 4 and 6, and pounds (20 shillings) were divisible by 2, 4, 5 and 10. In my grandparents' day, they still had guineas which were 21 shillings and so divisible by 3 and 7! We used that system to successfully trade and barter for a millenium, and then had to scrap it because coumputers allegedly couldn't cope.
Admin
So simple these plurals: http://www.oxforddictionaries.com/secondary/pocket_fowlers_modern_eng_usage/latin-plurals