Hacker News Reader

Comment by tome | Hacker News Reader

As a Haskell proponent I'd be really interested to hear specifically what it is that you'd like to do in Haskell but can't.

View on HN

Write a program that anyone can read. Haskell inevitably ends up looking more like a mathematical equation than the simpler constructs people are more used to finding in languages like Clojure.

That may or may not be so (my contention is that it is not so) but that's another debate.

The question I'm interested in finding the answer to is specifically what important things you can do in Clojure but not Haskell because of Haskell's static types.

What can I do in Haskell that I can't do in Clojure, because of Clojure's dynamic typing?

If you want to add static typing, you're looking for a contract library. Some are runtime, some use the macro system to get compile-time checking. (In fact, core.typed looks almost exactly like Haskell type definitions.)

If you miss Haskell's pattern matching, you can find it at core.match.

You want monads instead of variadic functions? Nothing easier.

Laziness is a lambda away.

Clojure, and so many similar dynamic languages have the power to give you the safety of static typing, if and when you want it. But they don't require it of you.

In some cases this can be bad, when you don't think through your data structures enough.

In other cases, it can be good because you don't need to think as much as you put things together, and can go back and expand later.

I think every language has a time and a place, for the right purpose.

> What can I do in Haskell that I can't do in Clojure, because of Clojure's dynamic typing?

You are making a false equivalence here. This thread started with the implication that the flexibility of dynamic languages is more useful than anything static typing can give, and questioning the grounds for that is not the same as asserting the opposite.

I question whether one is better than another.

If Haskell's type system paths the way for the programmer to implement, innovate, and create, then there is no reason for change.

The same for Clojure, or any other.

I merely answered a question on Haskell's capabilities with a personal anecdote. Haskell has been hard for the teams I worked with, replacing it with Clojure enabled others to reach their potential.

But, as for my personal belief on whether static or dynamic typing is better? Different projects have different requirements, as do the hands that craft them.

> What can I do in Haskell that I can't do in Clojure, because of Clojure's dynamic typing?

Also an interesting question, but, again, not equivalent to the one that I asked! joncampbelldev very specifically said that Clojure gives him more flexibility than Haskell. I'm asking for specific examples, otherwise how else can I improve Haskell or its documentation to be more appealing to fans of dynamic languages?

Ah, I've said too much in such a debated area, and clumsily.

Dynamic types give their power in what they can change. I do not know how easily this can be done with Haskell, but I expect a different pattern, or a more convoluted approach would be needed, but something like this:

    (defun greet
      ([:bob] "Hey bob")
      ([x] (str "Greetings, " x)))

So far, something familiar. But where's the dynamism? Let's grab a macro, so that we can do this:

    (addmatches! greet :chef-matches {:before :beginning}
      ([:emeril] "Love the zest")
      ([:child] "First, we baste the chicken!"))

Which we can have later use in other conditionals, as well as the corresponding macro removematches! (These macros come from a library, but are not difficult to implement).

Why would one ever want such a thing? It allows for the creation of a self-modifying parser, for one. Removes a lot of boilerplate for another.

I'm afraid I've never been able to understand macros. What does this do? Is it something like

    greet :: String -> String
    greet "bob" = "Hey bob"
    greet x     = "Greeting, " ++ x

    addmatches :: (String -> String) -> String -> String
    addmatches f = \case
        "emeril" -> "Love the zest"
        "child"  -> "First, we baste the chicken!"
        x        -> f x

If so, you'd have to design it slightly differently to do removematches in Haskell, I guess.

Well, it modifies greet in place.

And this:

    greet :: String -> String

Wouldn't really be writable by a human, because:

    x -> f x

Can represent any two expressions, for example:

  (addmatches! greet :chef-matches {:before :beginning}
    ((list? x) :sym) (comment Boolean -> Symbol)
    (list (apply greet x)) (comment Function -> Recursive...))

addmatches! isn't a separate function. Basically, at compile time, a macro is given the raw untyped tokens from Clojure's parser, and can run all of Clojure's features against them. The *match! macros don't exist at runtime.

Haskell is very readable if you learn to understand the type declarations, which are nicely set on their own line above every function definition. Haskell allows very general type declarations, but ideally once you've gotten your program running, you go back and make the types more specific. Anyone reading it can then see exactly what the whole codebase does without even reading the functions.

I'd be even stronger. Haskell's the most readable language I've ever used, and I was an early (ish) adopter of Python mostly because of readability.

Can you link to a small Haskell code base or single file that you believe is "more readable" than any other language?

I'll link to some of my own code, since I know it better than any other

https://github.com/tomjaguarpaw/haskell-opaleye/blob/master/...

For someone who knows Haskell idioms this is extremely readable compared to functionally equivalant code in another language.

this is like 90% `data` and `case`. show me a language where type declaration and case statements aren't readable.

> this is like 90% `data` and `case`

Welcome to the world of Haskell! Sum types aren't even available in C, C++, C#, Java, Python, Ruby, JavaScript, ..., so I think you're just proving my point for me.

no i'm not. you cherry picked. tell me how readable this module is

https://github.com/databrary/databrary/blob/master/Databrary...

with gems like

https://github.com/databrary/databrary/blob/master/Databrary...

and

https://github.com/databrary/databrary/blob/master/Databrary...

and

https://github.com/databrary/databrary/blob/master/Databrary...

and

https://github.com/databrary/databrary/blob/master/Databrary...

You can write unreadable code in any language. "Look, here's some unreadable code in your language" doesn't tell us much of anything.

That said... looking at your first example, it's really not that bad. It could probably be rewritten to be quite a bit clearer, but even knowing nothing about the library or surrounding context, it doesn't take me that much thinking to work out what's going on:

We have a dictionary implemented as a sorted list of pairs, and a list of records we want to update that dictionary with (after some transformation).

If there are no records, we give back the dictionary unmodified. If there is no dictionary, we build one out of the records. If there is both a dictionary and a bunch of records, we do a recursive merge of the two - compare the heads of each list, cons the smaller on the result of the appropriate recursive call.

> you cherry picked

That's exactly what I was asked to do!

For posterity, here's some very readable Haskell that has less data and case:

https://hackage.haskell.org/package/turtle-1.3.6/docs/src/Tu...

How easily extendable is that without the original source (e.g. when using as a library)? From what I can see it looks like if you can't edit the case statements you can't extend the functionality (e.g. expression problem stuff).

However, I'm not a haskell pro, so I don't know if I'm just missing the obvious here.

Very easy! And that's (one reason) why it's written the way it is. Any PrimQueryFold can be extended to a fold on a type which extends PrimQuery with additional constructors.

Readability is nice, but it is not the most important thing; I think what matters more is being able to reason about whether it is correct - there's lots of ways code can look about right on a first pass while hiding subtle bugs. I do not know whether Haskell is actually superior in this regard, but it seems to be motivated by the right concerns.

From the type perspective, one challenge is processing data where you don't know and don't care what types and what structure parts of that data will have.

One domain is deserialization of json or xml in a way that's agnostic to the structure of any extra data that I'm not explicitly referencing. For example, if I want to take a structured message (json or xml), do computation on parts of that message (so I need to decode these parts to "normal" data structures), and create a modification of the original message where my results are added but everything else is unchanged.

The last time I had to do this it was a bit painful as the serialization/deserialization libraries (I don't even recall which I used in the end. aeson? I tried a bunch.) expected me to know/define the whole structure if I wanted to properly serialize the updated data afterwards, and would break whenever the an updated api started returning a different message structure than expected (e.g. added new fields).

Perhaps I didn't find the right tools/approach to do this, but it's a rather common need and doing the same is quite trivial in python/javascript/etc.

Be able to clearly reason about the space complexity of code.

Even quite short parts of code can have an unexpected (at least unexpected to me) explosions of thunks, and it's quite difficult (at least to me) to find out where/how strictness markers should be added so that the code wouldn't generate the totally unneeded gigabytes of temporary data that I see in the memory profiler.

It's quite easy to reason about the correctness and results of Haskell code execution, but it's hard to reason how exactly that code will be executed in ways that have an extreme effect on performance - not tenfold, but e.g. exponential relative to dataset size.

Another worthy topic of debate that is completely unrelated to my question. Types and laziness are independent -- at least to the degree needed to provide an answer to my question.

> Types and laziness are independent

I think they are directly linked. If I have to worry about arbitrary types, my code can never be robust for the environment it runs in without raising some generic exception. This is the lazy approach. In a dynamic language, everything can be boxes to a static list of flexible types and is by default, meaning my code is succinct. This doesn't address the question (which is a strawman), but is the heart of the debate about static vs dynamic typing. Getting things done faster (with some guarantees) vs many guarantees (but not all) at a slower rate of progress (because you have to essentially duplicate code at a higher level, that the dynamic interpreter is already doing).

I can't actually understand anything you've said. You are using this definition of lazy, right? https://en.wikipedia.org/wiki/Lazy_evaluation

That's not true. When the language is lazy, you can't give a different type to one expression that's lazy and one expression that's strict. You can write hacks into the language that tell the compiler to evaluate certain expressions strictly, but you can't capture this in the type system when the language is lazy by default. On the other hand, this is perfectly possible in a strict language.

Firstly, that falls under my "at least to the degree needed to provide an answer to my question" rider. Secondly, no you can't type the values but you can type the consumers of the values, i.e. the functions: http://h2.jaguarpaw.co.uk/posts/strictness-in-types/

Ah, didn't realize the original question was limited to comments on dynamic typing. Regardless, that's a clever article, and an interesting tradeoff.

Exploratory coding that doesn't require tree-shaking refactors when a type needs to change.

"The spec changed, and I now have to be able to handle geese, where I originally typed for ducks."

There are ways and tools to minimize the impact, but it's still a lot extra overhead to think about and deal with.

Aha! The first reply that actually provides an answer to my question. Many thanks. Could you say any more about this, or perhaps provide an example? Its hard to know what you mean.

EDIT: Attempting to answer my own question, perhaps it occurs when you define a product type with a constructor

    data Foo = Foo bar baz

and then you want to add a new field to Foo

    data Foo = Foo bar baz quux

All your explicit uses of Foo in construction and pattern matching have now broken.

Open type variation require existential types. Not the easy types people are used to.

Could you explain what you mean by "open type variation"? Google's throwing up nothing relevant ...

polymorphism?

I don't think that can be it. Polymorphism doesn't require existential types!

Closed polymorhpism can always be pattern-matched but it requires modifying all matchers. Open polymorphism is the default in OO interfaces: you can always implement a new type by adding code locally.

Since existential types can be monomorphised and compiled to binary code allowing type-safe plugins.

Yeah, I was referring to polymorphism as we have in OO, where old code can call new code. I didn't even know "closed polymorphism" was a thing (is it equivalent to algebraic types?).

I'm not precise anymore with jargon concerning polymorphism (it's all the same to me), which I probably shouldn't do. I consider two factors: first closed/open (or finite/arbitrary) of 'remembering' an erased type, and second the sugar for nested 'remembering'. Almost all languages have both (open and closed) as either built-in, as a library or as a design pattern for that language. It boils down to either a tagged union or a function pointer. And both can be transformed to the other if needed.

Assembly, C have tagged unions & function pointers. Java has visitors, instanceOf, reflection. C++ has visitors, boost::variant, dynamic casts, mach7. Haskell has ADTs, pattern matching, existential quantification, Dynamic. Rust has pattern matching, traits, Any. Python, javascript, lua, lisp are dynamic, it's easy enough to create both.

I think it refers to open unions, which are types specified with some constructors that might have additional constructors defined later. As you say, Google is curiously reticent, but see, for example, p. 60 of http://www.seas.upenn.edu/~cis500/cis500-f06/ocaml-book.pdf .

Sorry for the confusion, JadeNB is correct: open type unions. For when you want plugin-like code without significant recompilations.

OK, fine. Well in Haskell we have Dynamic. Of course matching on a Dynamic may fail, but that's OK because the basis for comparison is untyped languages! Matching on types can always fail there too.

With Dynamic, yes, but not with existential quantification. The type is a proof the type-class is implemented.

I also didn't yet know Dynamic, thanks. I'm not that fluent in fp.

I've not found an elegant way to express in Haskell what can be expressed trivially with modules and functors in SML/OCaml.

Another interesting point that is not relevant to the question I asked, which was about dynamic typing!

Reply on news.ycombinator.com