Hacker News new | ask | show | jobs
by paulddraper 3435 days ago
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.

4 comments

I think Smalltalk machines did it, and so maybe did Lisp machines. Intersystems is doing something similar, partially, with M (their version of Mumps).
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.
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.

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...
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.

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.
C# really tries hard at that fwiw
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.