If DMN just wanted to be a requirements-gathering notation along the lines of BPMN 1.x, DRDs and decision tables would be enough.  (And unfortunately, to many decision management vendors and consultants, those are enough!)  But DMN has higher aspirations.  Like BPMN 2.0, it seeks to unify modeling and execution in a single language, accessible to business people but powerful enough to handle real-world decision logic.  In the end, DMN had to invent that language, called FEEL.  Having used it a bit, I can say that it accomplishes those goals.  It is reasonably business-friendly and at the same time, quite powerful.  Now the only challenge is to get DMN vendors to support it.

FEEL is not a programming language, just an expression language.  The best explanation of what that means comes from Michael Kay writing about XPATH 2.0, a similar expression language:

Every expression takes one or more values as its inputs, and produces a value as its output…. One of the things an expression language tries to achieve is that wherever you can use a value, you can replace it with an expression that is evaluated to produce that value…. This property is called composability: expressions can be used anywhere that values are permitted.

A FEEL expression is a formula that produces a value.  FEEL expressions can reference variables, but unlike a programming language, FEEL cannot create variables.  It is like the language used in Excel formulas, which is a far simpler thing than javascript or VBA, which are used in Excel macros.  For that reason, I say it is indeed business-accessible.

FEEL defines just a few datatypes: string, boolean, number, and a few date, time, and duration types.  These types can be restricted to enumerated values or ranges, and can be combined to form complex data structures.  FEEL variables may include lists and tables, as well.  FEEL provides a large number of built-in functions and operators.  For example,

Order.Item
[price >= 10]

means from a table Order, select all rows (Item) with a price greater than or equal to 10.  In addition to table queries and joins, FEEL expressions can do iteration, datatype validation, list sorting, and lots of other powerful things.  FEEL expressions can invoke reusable functions, like

paymentAmt(principalAmt, ratePct, termMonths).

What that means is that instead of handing off iteration to BPMN and handing off queries to SQL, DMN logic can do the end-to-end decision logic itself.  So why aren’t DMN vendors rushing to support it?

Basically, it’s too much work.  No Java or javascript libraries for it exist yet, so the vendors would have to parse the FEEL expressions and do the translation themselves.  Better to wait for someone else to do it.  Naturally, they say, “Our customers aren’t asking for it.”  AS IF!!!  It’s not like the expression languages used in first-generation DMN tools are more powerful than FEEL.  In fact, just the opposite.

Eventually it will happen.