• (cs) in reply to SilverDirk

    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 ;-)

  • (cs)

    Operands.IsEqualTo

    ...

  • (cs) in reply to SilverDirk
    SilverDirk:
    Quote [Opera style]: ------------------ IsCancellable is an *attribute* of an Order Status. If you have a table defining your order statuses (hopefully, if you are using foreign keys and all of them other fancy database features) then that is where it belongs. Not in your code, not in an XML file, not anywhere else. ------------------

    Um, wrong. If you store isCancellable as a column then it will need to be updated any time any of the fields it depends on are modified. This means any rearrangement of the DB, any rollback-type stuff, and just plain any operation affecting this order will also need to run the logic of updating the IsCancellable field. Thats just asking for a bug.

    IsCancellable is a calculated attribute. It should not be stored as a constant value. It should be added to a view via a stored procedure, or remain in the logic of the program. It IS application logic, afterall. Noone should be browsing the database and saying "well, I think this one should be cancellable, so I'll set that to true".



    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! 

  • orbis tertius (unregistered)

    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.

  • (cs) in reply to SilverDirk
    SilverDirk:
    Quote [Opera style]: ------------------ IsCancellable is an *attribute* of an Order Status. If you have a table defining your order statuses (hopefully, if you are using foreign keys and all of them other fancy database features) then that is where it belongs. Not in your code, not in an XML file, not anywhere else. ------------------

    Um, wrong. If you store isCancellable as a column then it will need to be updated any time any of the fields it depends on are modified. This means any rearrangement of the DB, any rollback-type stuff, and just plain any operation affecting this order will also need to run the logic of updating the IsCancellable field. Thats just asking for a bug.

    IsCancellable is a calculated attribute. It should not be stored as a constant value. It should be added to a view via a stored procedure, or remain in the logic of the program. It IS application logic, afterall. Noone should be browsing the database and saying "well, I think this one should be cancellable, so I'll set that to true".



    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.

  • (cs) in reply to Zapper

    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...

  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    The goggle are a no-op and do nothing.


    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.

  • Benjamin Smith (unregistered) in reply to Goplat
    Goplat:
    Bus Raker:

    The real WTF is that the forum software says '1 Replies'

    Haven't they heard of:

    caption = (replies = = 1 ? "Reply" : "Replies");

     


    Obviously you still understood that there was one reply even though the plural was used. Why add extra complexity to the software for no benefit?

    For some programs, choosing between singular/plural nouns automatically can actually be detrimental because it makes the output harder to be parsed by other programs.



    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.
  • (cs) in reply to VGR
    VGR:
    There's a name for this:  Second System Syndrome.


    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...

  • (cs) in reply to an(on)im(o)us
    Anonymous:
    In base-12, 1/3 would be 0.4.

    Not to mention that 1/5 = 0.24312431_

    We should use base-60, or base-420



    Wouldnt 1/3 in base-12 be .25?

  • (cs) in reply to zamies
    zamies:
    Anonymous:
    In base-12, 1/3 would be 0.4.

    Not to mention that 1/5 = 0.24312431_

    We should use base-60, or base-420



    Wouldnt 1/3 in base-12 be .25?

    Forget the post my brain was out to lunch...

  • blah (unregistered)

    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.

  • No way am I saying. (unregistered) in reply to kipthegreat
    kipthegreat:

    Bus Raker:

    I'd better go home ... 1/3 = .3333_

     

    In base-12, 1/3 would be 0.4.


    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.
  • (cs) in reply to Goplat
    Goplat:


    I said "some programs", not THIS program. For being so obsessive about language use, you sure are terrible at reading.


    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.




  • (cs) in reply to an(on)im(o)us
    Anonymous:
    In base-12, 1/3 would be 0.4.

    Not to mention that 1/5 = 0.24312431_

    We should use base-60, or base-420

    Now, by "base-60" do you mean "base sixty" in decimal or "base six zero" in some other base?

  • a really good counter (unregistered) in reply to Otac0n
    Otac0n:
    Anonymous:
    In base-12, 1/3 would be 0.4.

    Not to mention that 1/5 = 0.24312431_

    We should use base-60, or base-420

    Now, by "base-60" do you mean "base sixty" in decimal or "base six zero" in some other base?



    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!!

  • Charlie (unregistered) in reply to Bus Raker
    Bus Raker:

    The real WTF is that the forum software says '1 Replies'

    Haven't they heard of:

    caption = (replies = = 1 ? "Reply" : "Replies");

    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).

  • (cs) in reply to Goplat
    Goplat:
    Obviously you still understood that there was one reply even though the plural was used. Why add extra complexity to the software for no benefit?

    For some programs, choosing between singular/plural nouns automatically can actually be detrimental because it makes the output harder to be parsed by other programs.

    <font size="5">I</font> guess that's what XML was originally intended (data transfer, that is.).

  • (cs) in reply to orbis tertius
    Anonymous:
    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.


    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.
  • (cs) in reply to Charlie
    Anonymous:
    [..] 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).

    But that's up to the translater isn't it? A general grammar system is hell, but nobody expects that to be perfect anyways. Given that *somebody* will translate this by hand, it's imo the most elegant practice.

    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.

  • jk (unregistered) in reply to Jeff S

    Well you know,  some code has to set the column in the table.

  • (cs) in reply to Charlie
    Anonymous:
    Bus Raker:

    The real WTF is that the forum software says '1 Replies'

    Haven't they heard of:

    caption = (replies = = 1 ? "Reply" : "Replies");

    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).



    That's (part of) what gettext is for.

    It's not exactly rocket science.

    Simon
  • (cs) in reply to blah
    Anonymous:
    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)

    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.

    Anonymous:
    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.

    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.
  • (cs)

    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.

  • (cs)

    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.

  • (cs) in reply to Zlodo
    Zlodo:
    ...

    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.


    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...
  • (cs) in reply to Jeff S

    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)

  • Edwin (unregistered) in reply to kipthegreat


    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

  • Brian (unregistered) in reply to SilverDirk

    SilverDirk:

    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)

    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.

  • bob jones (unregistered) in reply to Volmarias

    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.

  • bob jones (unregistered) in reply to Pyromancer

    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.

  • (cs) in reply to Brian
    Anonymous:

    SilverDirk:

    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)

    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.



    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. 
  • (cs) in reply to ithika

    Of course I stop too soon, I'm no consultant or certified professional. I suck at that enterprisey coding thing :p

  • selo (unregistered) in reply to Bus Raker
    Bus Raker:
    Goplat:
    Bus Raker:

    The real WTF is that the forum software says '1 Replies'

    Haven't they heard of:

    caption = (replies = = 1 ? "Reply" : "Replies");

     


    Obviously you still understood that there was one reply even though the plural was used. Why add extra complexity to the software for no benefit?

    For some programs, choosing between singular/plural nouns automatically can actually be detrimental because it makes the output harder to be parsed by other programs.

    Guess you weren't a computer science / English literature double major.  It is true the English language isn't very efficient.  I definitely recommend inventing a new language .. we'll call it English Sharp, without pluralilty and conjugation.  While we're at it we can stop using this primitive base 10 crap, with factors of 2 and 5 and move on to the more efficient world of base 12 with factors of 2,3 and 4.  The combined paper savings of calculating 1/3 = 4 rather than 1/3 - 3.3333 will save at least 10% of our national forests. 


    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
  • jesuswaffle (unregistered) in reply to Peter Amstutz
    Anonymous:
    And I was going to add to that, "those who do not understand Prolog will reinvent it, poorly."

    Person(P)
    UnderstandsProlog(P, false) :- and(WillReinventProlog(P), WillDoItBadly(P))

    See?  Much clearer.

    Not quite...

    person(P)
    willReinventProlog(P, badly) :- not understandsProlog(P)

    More or less.
  • (cs)

    They took the idea of a "New" version quite literally.

  • (cs) in reply to AndrewVos

    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

  • James R. Twine (unregistered)

    While there is lots of discussion on how such a thing can be done better, did anyone notice that the block:

    new EreRuleAtom
                (
                  order.OrderStatus,
                  Operands.IsNotEqualTo,
                  OrderStatus.Approved
                )

    Is duplicated for both of these conditions?

    <FONT color=#008200>order.OrderStatus != OrderStatus.Approved
    order.OrderStatus != OrderStatus.Canceled</FONT><FONT color=#008200></FONT>

    So regardless of how it is implemented, it is still broken?

    Peace!

    -=- James R. Twine

  • Martijn (unregistered) in reply to sacundim

    So it's basically a scripting language designed by people trying to create something else?

  • James (unregistered) in reply to Peter Amstutz

    But WillDoItBadly only applies to another proposition, not to an atom >:->

  • James Taylor (unregistered)

    A stupid approach to a real problem. Longer reponses on my ebizQ blog. JT www.edmblog.com

  • Carlos Ferreira (unregistered) in reply to kipthegreat
    kipthegreat:
    Goplat:
    Bus Raker:
    The real WTF is that the forum software says '1 Replies' Haven't they heard of: caption = (replies = = 1 ? "Reply" : "Replies");  

    Obviously you still understood that there was one reply even though the plural was used. Why add extra complexity to the software for no benefit?

    For some programs, choosing between singular/plural nouns automatically can actually be detrimental because it makes the output harder to be parsed by other programs.

    Choosing singular/plural nouns makes users less inclined to think that the program was written by retarded people.  Besides, it's not like it's hard to do.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);  }  /**    * Pluralizes a term that you only need to add an "s" to.    */   public static String pluralize(int count, String item) {     return pluralize(count, item, "", "s");   }   And I also have my much simpler PHP version that will work with integers or floating-point numbers, and doesn't require overloading:function pluralize($count, $item, $singular_suf='', $plural_suf='s') {  return "$count $item" . ($count == 1 ? $singular_suf : $plural_suf);}It would be trivial to internationalize this as well (well, at least to a language that uses a suffix.. there probably are languages that don't do pluralization that way.. but I've never had to code to support one so I don't know).

    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...

  • Jack (unregistered) in reply to Bus Raker

    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.

  • Grammar Pedant (unregistered)

    So simple these plurals: http://www.oxforddictionaries.com/secondary/pocket_fowlers_modern_eng_usage/latin-plurals

  • Person (unregistered) in reply to craig bowes
    Comment held for moderation.

Leave a comment on “The Enterprise Rules Engine”

Log In or post as a guest

Replying to comment #68743:

« Return to Article