Hacker News Reader

Comment by ojnabieoot | Hacker News Reader

I am personally not a huge fan, but like many statically-typed functional languages, Haskell is great for

- creating new programming languages and DSLs

- problems in finance, energy, medicine, etc., that are more correctness-sensitive than performance-sensitive (it is widely used in Bitcoin brokerages / exchanges / etc, and in general blockchain technologies)

- highly-concurrent scenarios that would otherwise involve a lot of painful management of threads/locks/etc

Facebook’s Haxl is a good example of software that uses Haskell effectively: https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...

View on HN

I'm not a big fan of DSLs. Yes, they allow for convenient notation to express things within specific domains, but they also create more barriers. It is both more impressive and more useful if one is able to create abstractions in mechanical sympathy with idiomatic uses of existing languages. Of course, this is harder to do.

I think DSLs are a bit of a lazy cop-out.

This is not a new idea. The myth of the tower of Babel and the observation that by creating lots and lots of communication barriers and interfaces, you lose the ability to coordinate major efforts is indeed very old.

I disagree. DSLs give you a new set of primitives which is more suited to the problem domain and makes it harder to make mistakes by accidentally encoding things which don't exist in the problem domain.

Of course, just making a DSL isn't enough. Some DSLs are badly designed and inelegant, or their features do not compose well with each other. But a well designed DSL can be a thing of both beauty and clarity.

I think this shouldn't be surprising as even modern programming languages are DSLs of a kind when compared to machine code.

>DSLs give you a new set of primitives which is more suited to the problem domain and makes it harder to make mistakes by accidentally encoding things which don't exist in the problem domain.

But domains are interrelated. If there is no common set of primitives upon which various different domain abstractions are built, then you have to relearn absolutely everything for each domain, even things that are not domain specific at all.

You end up with a huge number of special cases. Mistakes are made because only very few people will be able to remember all the semantics of all the DSLs they need for their work.

I agree, and that's why DSLs are not magical pixie dust and have to be used with taste and judiciously. But in cases where they do work, they are strictly better than free form code, IMO.

Designing good DSLs is hard. If you recommend that people construct DSLs to solve their problems they will. Most of the time these DSLs will not be good and they will present either barriers or bottlenecks.

The reason DSLs often become a problem is that people often do not think about the cost of maturing and maintaining them.

I've seen this happen quite a few times. Someone gets the idea that "we need a DSL for this". It is implemented, but the resources and time to do a proper job isn't there so the documentation, tooling and roadmap is severely lacking or entirely absent.

More requirements are uncovered and development becomes hampered by what the DSL can express or how it is implemented. If you are really unlucky, the original architect leaves or loses interest. I've seen entire products grind to a halt for 6 months because the only person with deep understanding of a DSL on which everything hinges has left the company.

DSLs, like any programming language in general, can be useful. But they are expensive pieces of software to write and maintain and not the "easy solution" that people tend to be misled into thinking that they are. And if expense is spared in their making, it has to be paid for later in troubles encountered further down the road.

Haxl is actually an example of "the more impressive and more useful" approach: it is an abstraction embedded within a Haskell library, that allows you to express your "intent" in simple, standard Haskell code, decoupled from the way this intent will be reached (i.e. the execution is determined/optimized by the library)

Haskell allows this to be done in a way that makes if very hard for the user to break this abstraction (the type system will prevent you from doing this), while still allowing the full language power of Haskell to be used.

> It is both more impressive and more useful if one is able to create abstractions in mechanical sympathy with idiomatic uses of existing languages.

... so, EDSLs?

Many of those communication barriers and interfaces are a feature, not an obstacle.

For example, in a typical enterprise application it's good to know that SQL queries and web resource access control (two typical DSL uses) cannot interfere with one another accidentally.

SQL is a DSL that is fairly heavy in that a lot has been invested in it over multiple decades. (It even has extensions or outgrowths that turn it into more of a general purpose language)

This results in ample tooling, lots of documentation, multiple implementations, some of which are really good and a lot of community knowledge.

One may like or dislike SQL, but it is undeniable that it is useful to and mastered by a great many people.

Most DSLs have few or none of these properties. In some environments DSLs tend to be presented as something you can create casually. That it is a lightweight solution. And what starts as a small solution can often grow - usually to a point where not having put in a lot of work in the basic design will make the language unsound.

I don't think DSLs are a lightweight solution at all. I think that giving inexperienced programmers the idea that DSLs are is something they ought to be designing probably isn't helpful.

> problems in finance, energy, medicine, etc., that are more correctness-sensitive than performance-sensitive

What does correctness-sensitivity mean in this context and how is it missing from a language like Python for example?

It means that the type system is flexible enough to encode specific domain logic in a way that can be verified by the compiler (and therefore always be correct at runtime unless there is a bug in the compiler). Likewise, it means that plainly incorrect domain logic (eg due to a typo) is far less likely to occur than in a Python program. Some of this can be encoded by statically typed languages like C (“the average of an array of floats is a float”) but not all of it (“given a function that maps floats to floats, applying that function to an array of floats returns an array of floats”).

Python of course has none of this (“this average function actually returns the string ‘fix me!’ on some inputs because the programmer forgot to fill in and else branch”). Mypy is a useful tool but it doesn’t stop type-incorrect code from being executed and isn’t as powerful as Haskell. Likewise, the Haskell compiler certainly doesn’t catch everything, but it does completely eliminate many common Python bugs.

There is obviously a “spectrum” since no general purpose language has a truly rigorous type system.

Idris is not rigorous enough?

The compiler and type system allows you to more robustly encode and enforce correctness. Even as someone who's written relatively little Haskell compared to Python, knowing that I can run it and it's not going to break in some weird, unexpected way is a fantastic feeling. If I had to write something that needed to be logically "bulletproof" and correct, I'd feel orders-of-magnitude more comfortable writing it in Haskell/Rust than Python. Python has too much magic, too many ways to do something unchecked, too many ways to work-around some issue. It's too easy to write poor, difficult-to-comprehend/maintain code in Python, at least with Haskell/Rust I can re-factor something and _know_ that I didn't break anything or change any behaviour - the latter especially is straight up not a guarantee I could make with Python in my experience.

Reply on news.ycombinator.com