[achikin]

I think nowadays people spend too much time learning new tools and too less time doing something really valuable using that tools. I wish I had only one language, so I can concentrate on more interesting things rather than learning yet another random set of operators and library function's names.

[paulddraper]

While using fewer, better languages for more is fantastic, I doubt you really want a single language.

Try replacing shell, Structured Query Language, and C with the same language. I won't say that it can't be done, but I think you'll lose a lot if you succeed.

[cema]

I think Smalltalk machines did it, and so maybe did Lisp machines. Intersystems is doing something similar, partially, with M (their version of Mumps).

[jononor]

I'd hope that with embedded DSLs we can get closer. People are already doing lots of it in Haskell, including domains you listed. Of course there is always the risk that one invents an "inner language" with poorer semantics and tools.

[eru]

Haskell is a pretty good host for DSLs. But if you want to go lower level than Haskell, you have to essentially write compilers for your embedded DSL rather than the usual interpreters.

And of course, Haskell's type system is not endlessly flexible (yet..). Eg Haskell still struggles expressing relational programming or linear types / uniqueness.

[jononor]

Yes the low-level DSLs tend to become their own compilers. But the good thing is that they as a side-effect also have an API, so they can hopefully be reused for new DSLs. Interoperability of different DSLs does not neccesarily follow though, unfortunately...

[eru]

Yes. And of course, you still need to write a decent compiler to produce decent code.

The situation is similar to Lisp macros: yes, you can implement Prolog in Common Lisp in a few lines, but no, it won't be a fully featured and fast production system, unless you actually put in the work. (Paul Graham's 'On Lisp' makes these excellent points in the chapter on the Prolog interpreter.)

Of course, you might want to go all the way to dependent typing. I think one of Ysabelle or Idris actually compile to 'low-level' languages like Haskell by default?

The main benefit I would like to see in Haskell is totality / termination of programs by default, and hiding Turing completeness behind something like unsafePerformCompute. Similar, we could split IO into IOReadWrite and IOReadOnly.

The former would be the same as the old IO, the latter's actions could depend on the environment but wouldn't be allowed to influence it (or weaker: would at least require idempotence?)---thus allowing more scope for optimization and human understanding when reading code.

[lmm]

I think you gain more than you lose. (For myself I have replaced shell, SQL, and C when it doesn't have realtime requirements (which is most of the time) with Scala FWIW). Language boundaries are really high-overhead, and most of the time being able to use the same tools and libraries everywhere more than makes up for a language not being quite as good a fit.

[ktRolster]

C# really tries hard at that fwiw

[voltagex_]

It's interesting, but you can get caught out easily - especially when using LINQ to SQL without knowledge of what's happening on the database side.

I also don't think anyone's programming "just" C# - I'm a web dev, so I'll do Javascript, Razor, HTML, C# and SQL as the situation requires.

There's also a huge difference between programming ASP.NET Web Forms and the latest version of WebAPI.

[preordained]

I'm with you. A standard set of languages/tools would be great, so you don't have to pay a cognitive overhead cost every time before you dive in. It's fatiguing. It adds up. I much more enjoy the act of programming than learning a new tool or language....and then getting on with the real work.

Pipe dream, it would seem, but: I feel like the energy spent picking up new things could be used so much better going deeper and building more with established tools--tools hardened by collective reuse.

[tlarkworthy]

I am sick of having to rewrite difficult data structures. I though if haxe could compile libraries I might never have to. But maybe just doing everything in rust might be a better approach?

[solidsnack9000]

It would be nice if you could "auto-export" from Rust. The pieces of the puzzle are something to generate a C API from a module's public API -- without `extern` declarations -- and then something to turn that API into Ruby, Python, Swift, Node, Java, Go, &c.

Clang modules are the beginning of something for the latter task. SWIG also has a lot of ideas that are usable -- and SWIG can handle the API description having classes and methods, since it handles C++. Though I would hesitate to make C++ headers the lingua-franca of code.