You are correct, but you are probably being downvoted because it is difficult to relate to your point of view.
How many “sub-Turing-complete” languages can you list?
Note “sub-Turing-complete” may not be the right term to use for all languages that do not admit general recursion. There is a particularly interesting subset of total languages for which the preferred term is “languages with control over non-termination”.
There aren't many popular non-Turing-complete languages because most language designers are stuck in a cycle of redesigning Algol and Lisp for the umpteenth time. Very few new mainstream languages have anything new to say that applies to anything outside writing simple algorithms or gluing libraries together. Scala, Ruby, D, Rust, CoffeeScript, Clojure... I could go on. They're all just rehashes of the same ingredients. Why this is the trend I'm not sure, but I bet it's related to the fact that these same languages try to position themselves as complete ecosystems, rather than simple tools which form but part of an engineering solution.
There's been some promising movement recently in the direction of DSLs. Reactive programming seems to finally be gaining popularity, which allows us to replace gobs of glue code with simple declarations. Erlang's OTP has been gaining popularity too, allowing declarative design in the large.
> Very few new mainstream languages have anything new to say
> these same languages try to position themselves as complete
> ecosystems, rather than simple tools
This is where you answer your own implied question. Tools designed to excel at a singular task to the exclusion of general-purpose tasks will necessarily attract a comparatively niche audience. Tools designed for more general applications will attract people doing more general tasks, which is a more "mainstream" audience by definition.
Yes, it is an unfortunate catch-22. I think the secret is that, due to their simplicity and analyzability, it's possible to make extraordinarily powerful DSLs that can truly excel at their tasks in a way that general-purpose languages can not.
SQL is a perfect example of this. The fact that it is (barring recursive CTEs) not Turing-complete is what permits very intelligent automatic query optimization. I can write simple, clear, concise, performant SQL code that blows the pants off anything I can do without extraordinary effort in a general-purpose language. It is this that has made SQL so indispensable and enduring a tool.
Or you can get both with a powerful general purpose language subject to easy analysis and supporting DSL's. What I can do with that will blow the pants off your SQL. Matter of fact, I can start with a DSL for clarity/automation, manually optimize it if I choose in same language, and (if Scheme) compile that all the way down to logic gates. That's power right there.
I'm not really sure the point of your post. Why should I roll my own relational query engine in Scheme when I can use one with hundreds of man-years of development, and thousands of man-years of testing behind it, like PostgreSQL?
Also, I sincerely hope you're not trying to synthesize ASICs out of code from a language with constructs like call/cc.
I am an EE. I have designed fully-synthesized ASICs in Verilog for money. If you ignore the simulation constructs of Verilog (which you should, if you're designing something to be synthesizable), Verilog is a purely declarative reactive language, and a damn good one at that. (Verilog, BTW, has stratified programming-in-the-large constructs.)
You can't synthesize "functional programs"; there's no analogue of recursion in hardware. You can only synthesize things that happen to look like functional programs because they're written using sexprs and macros and expand out to a static circuit graph which is exactly what Verilog is.
I guess it would be more accurate to say, when I was trying to learn Verilog, people I knew tried to convince me to abandon Verilog in favor of Haskell flavors. This gave me the (perhaps false) impression that this was common practice.
It's not common but many swear by it in form of Bluespec: a Haskell extension/modification for HDL with RTL output. Look them up. Further, dig in the CHERI project for their processor source as it's Bluespec for a security-enhanced, MIPS64 processor which might give you a good idea about what the language is like. Very real-world project. Already runs capability-secure FreeBSD. Most newcomers' Verilog projects are less complicated. :)
Also you might find Synflow's HDL interesting. It's on my backlog as I'd rather get diverse and experienced HDL users to put it through the paces. They have several, non-trivial IP for sale that they coded in it and for cheap, too.
Note: DDD scheme also supported call/cc. :P It wasn't in the final circuit, though, except as an execution feature.
"You can only synthesize things that happen to look like functional programs because they're written using sexprs and macros and expand out to a static circuit graph which is exactly what Verilog is."
Oh, come on, that's kind of cheating as you could say the same about almost any level of abstraction. You might as well say you can't synthesize the Verilog constructs: you just synthesize something that looks like it into a connection of analog transistors that it actually is. Yet, if you can use that model and it works, then it's a meaningful thing to say you can synthesize/use such a model to get X done with Y benefits instead of hand-stitching cell libraries and gates. Likewise, the more functional (or other) alternatives to Verilog with their advantages so long as they deliver on them in the field.
For my examples, SHard is a research prototype that works on some, limited examples. DDD was used on numerous real-world projects while the spin-off was still in business. Gone now. Bluespec is still kicking ass in industry. So, Bluespec at the least proves out the concept and its advantages over Verilog.
They have a great hardware synthesis tool now that costs low, five digits. Just for math-style algorithms rather than arbitrary programs. Prototype algorithm is Matlab language, then deploy to HDL with plugin.
You talk about Scala and Clojure, yet they agree with you about the advantages of DSLs, which is why both promote their features as DSL-building toolkits, and there are plenty of modules for those languages that provide DSLs.
The thing with DSLs is that almost by definition, unless you're building something almost cookie-cutter, you can't build a whole system with a single one. So Scala and Clojure are supposed to be the common ground in which you use and connect the programs made in these DSLs. Of course, since these are internal DSLs, it's often hard or impossible to isolate the code written in the DSL from the rest of the program, so it's hard to apply optimizations and such, but you still gain the code reduction that you talk about.
>Of course, since these are internal DSLs, it's often hard or impossible to isolate the code written in the DSL from the rest of the program
Exactly, but that is also why you lose basically all advantages of DSLs. I don't think internal DSLs deserve to be called DSLs at all. They are simply libraries that tend to use a lot of operator overloading.
The whole point of DSLs is to formally restrict what a given expression could possibly mean. That's what allows inference, optimization and sensible error messages that use the terminology of the DSL and not that of some underlying much more general language.
I'm not sure if these are strictly non Turing complete or not but they are designed to do one thing only and they are still quite mainstream: makefiles, shaders, flex and yacc. SQL has already been mentioned, other database query languages are usually even more restrictive.
How many “sub-Turing-complete” languages can you list?
Note “sub-Turing-complete” may not be the right term to use for all languages that do not admit general recursion. There is a particularly interesting subset of total languages for which the preferred term is “languages with control over non-termination”.
http://www.cse.chalmers.se/~nad/publications/danielsson-sema...
https://personal.cis.strath.ac.uk/conor.mcbride/TotallyFree....
https://github.com/mietek/total-functional-programming