Entity is part of the documented language -- we've standardized the representation of millions of real-world things. Looking up properties of Entities and parsing text into Entities depends on Wolfram|Alpha, just like the ServiceExecute function relies on Twitter and Facebook to work, and just like Graphics relies on a front-end executable to actually render.

These aren't libraries as you might call (say) core.logic in Clojure, because Entity and co integrate tightly across the rest of the language, and because they all share the same System namespace. They aren't quite DSLs either, because if they were the entire language would be a DSL -- rather the language is symbolic, which gives it some properties in common with DSLs.

If there is nomenclature that is different or new, it is mostly because the language is different. The only thing I can't defend is the pure in our "pure functions". They're not pure functions, they are lambdas.

Thank you for your reply.

Looking through examples, it still appears very much that domain specific calls were added to the very flexible language typically used in Mathematica to essentially extend computation to these new domains using domain specific widgets. (Also, some exchange data types.)

I'm still having trouble seeing how this is a radical departure from say, embedding a bunch of domain specific tie ins in a Lisp using macros (or similar constructs) to get a similar syntax across them.

I get that the constructs are likely tightly integrated, but I guess I'm still not seeing where it's more than a framework for dealing with particular classes of data running on top of a programming language that targets a hosted run time with a database of facts.

I'm not saying that this isn't a useful thing, and entirely worth it for well curated data. As I mentioned, I pay for essentially that service targeting a database about social media. I'm just trying to see if there's something key to understanding the features that I'm missing.

If you'll excuse one quasi-dig: it can sometimes be hard to see what something really is and what its use cases are through the hype and marketing.

Have you actually used the computable data functionality in Wolfram products?

If you think its a matter of just connecting to a standard database, you are missing the whole point.

People in the data business tell you cleaning and preparing the data is 80% of the work. Wolfram has done that for you. And then taken it farther: integrating it directly into language constructs.

I think SW's post did a poor job of explaining these capabilities, but in some domains this integration totally trounces what is possible in other systems. A great example of this is how GeoGraphics works:

http://reference.wolfram.com/language/ref/GeoGraphics.html

Notice how semantic entities like countries and landmarks are interoperable with the graphics language.

I think we're operating on a different definition of "language". Unlike natural languages a programming language has extension points to define new vocabulary, it doesn't mean that all available words are part of the language. Otherwise it's like saying that everything that is in perl's CPAN is part of the language.

Usually there is a distinction that's made where the language is the syntax + the semantic defined by the compiler or the runtime. Then comes the standard library, then comes the user libraries. The "wolfram language" seem to mash everything together into a single thing.

In what way is anything in that example different than say, a DSL implemented in Lisp macros connected to a database?