In my experience, it just makes workflows more difficult since you now need to create custom editors, linters, formatters, testing frameworks, etc. You need a whole new ecosystem before you can truly become productive on top of learning an entirely new syntax.
We've been using our own "Visual SDK" to build large parts of MintData for the past few years.
It's 100% written in TypeScript/React, using decorators (cough: annotations!) and allows us to:
1) add new spreadsheet functions in TypeScript
2) wrap any React component
3) we get the auto-magic property panel UI "for free" & it instantly talks to/from the spreadsheet
For our cloud/backend imperative layer:
4) we use our own real-time stream processor (think: Apache Storm but minus the Clojure stacktraces)
5) the SDK lets us quickly write flow blocks in Java using annotations & connect to all sorts of enterprise-y systems (SQL/NoSQL stores, Queues, File Systems, etc)
@slifin -- in terms of engineers writing & selling those layers, we're open to it -- ping me if you have ideas & we can give you access to the docs & SDK.
--
[1] I'd put a link here, but the flamethrowers have come out on this thread :)
Card carrying member of the disagree-club here (malleable clan), but I think it's a tall order to ask users to write procedural code.
Tools that are:
(1) declarative by nature (HTML, DSLs)
(2) based on direct manipulation (PSA: we're lucky to have Bret Viktor on this planet)
is what will win out in my opinion.
Or will we be writing procedural code 30, 50 years out? :)
--
[1] YMMV, founder of https://mintdata.com here, where we recently opened public access & are seeing the above come true.