Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dueling Rhetoric of Clojure and Haskell

tech.frontrowed.com

Post reply on HN
Print view View original

21–30 of 107 posts

Re: Dueling Rhetoric of Clojure and Haskell

#21

Post by hristov »

dukerutledge wrote: post #7
bpolverini wrote: post #6

The dueling rhetoric is the same rhetoric that has been around for decades: Some people really feel type systems add value; others, feel it's a ball and chain. So which is it? The answer is probably "yes." We should all believe by now since history has proven this correct. Most of the time you start with no type system for speed. Then you start adding weird checks and hacks (here's lookin' at you clojure.spec). Then…

I'd gladly storm into the breach with you :) Hopefully we all agree that static types and dynamic types are useful. Those who use hyperbole are attempting some form of splitting. I think the point where we disagree is what the default should be. The truth is this discussion will rage on into oblivion because dynamic types and static types form a duality. One cannot exist without the other and they will forever be ent…

Well, I think that static types are much more useful than dynamic ones. Static types allow you to find errors with your program before execution and that is very important. And if you are going to go through the effort of defining types, it is much better to use static types because then you get this additional error checking. Furthermore, with static types the compiler can help in other ways, e.g. by organizing your data in memory much more efficiently.

I am not sure what you mean when you talk about the duality of static and dynamic types. One can exist without the other and most statically typed languages either forbid or strongly discourage dynamic typing.

Re: Dueling Rhetoric of Clojure and Haskell

#22

Post by brandonbloom »

platz wrote: post #18
brandonbloom wrote: post #11

EDIT: deleting this post because it was needlessly counter-inflamatory.

No need for typeclasses/existentials. That is trying to approximate some typed/untyped middle ground. You would just use 'dynamic' if you want true dynamic behavior

The Edn type given here is closed. That's a correct definition of Edn, which is a closed sum. Edn accomplishes extensibility via the Tag type. However, not all Clojure data is Edn. In order to implement the clmap and clget functions with their full generality, they need to support an open set of types. For example, both `#inst "..."` and `(eval '(Date. ...))` are separate types: TaggedLiteral and java.util.Date respectively.

You need either Dynamic or existentials because Clojure enables you to pass data structures between two functions expecting collection elements of differing capabilities without either A) whole program / inter-module analysis or B) an O(N) type translation.

Re: Dueling Rhetoric of Clojure and Haskell

#23

Post by marcosdumay »

kreetx wrote: post #8
bpolverini wrote: post #6

The dueling rhetoric is the same rhetoric that has been around for decades: Some people really feel type systems add value; others, feel it's a ball and chain. So which is it? The answer is probably "yes." We should all believe by now since history has proven this correct. Most of the time you start with no type system for speed. Then you start adding weird checks and hacks (here's lookin' at you clojure.spec). Then…

The fact that Haskell is smarter than me is exactly why I have been keeping at it! There is no fun left if you know all the overarching principles of a language, and you realize it still doesn't solve your problem. This happened to me when learning Python, this is also why I don't really look at Go or Rust. They're good languages, I might use them at a workplace someday, but you can get to the end of their semantics,…

I love how I just keep learning Haskell, and keep improving, despite how much I already did it.

That said, Python is also smarter than me. The possibilities with monkey patching and duck typing are endless. But differently from Haskell, Python is not a good teacher, so I tend to only create messes when I go out of the way exploring them.

Re: Dueling Rhetoric of Clojure and Haskell

#24

Post by brandonbloom »

emidln wrote: post #20

Fwiw, you can map over Maps and Strings in clojure: (map identity "foo") ;; a seq for String is its chars ;=> (\f \o \o) (map identity {:foo :bar}) ;; a seq of a Map is the ;; pairs of key/values ;=> ([:foo :bar])

And get works on more types, like vectors. It also returns nil instead of throwing:

    cljs.user=> (get [:x :y :z] 1)
    :y
    cljs.user=> (get 5 :x)
    nil

Re: Dueling Rhetoric of Clojure and Haskell

#25

Post by marcosdumay »

wellpast wrote: post #2

> Much of the rhetoric that is currently flying around is a false dichotomy. The author here is missing the rhetoric. The rhetoric is not about the programming language but about how we should be doing information processing. Except that the author isn't missing that point: > In Haskell we typically “concrete” data with record types, but we don’t have to. Great. That is the dichotomy. And it's not a "false" one. This…

> This is the question: should we be "concreting"?

At some point your program has to do some specific task over some specific kind of data. Maybe you wanted to ask when should we be concreting?

Re: Dueling Rhetoric of Clojure and Haskell

#26

Post by platz »

brandonbloom wrote: post #22
platz wrote: post #18

Earlier quoted context omitted.

No need for typeclasses/existentials. That is trying to approximate some typed/untyped middle ground. You would just use 'dynamic' if you want true dynamic behavior

The Edn type given here is closed. That's a correct definition of Edn, which is a closed sum. Edn accomplishes extensibility via the Tag type. However, not all Clojure data is Edn. In order to implement the clmap and clget functions with their full generality, they need to support an open set of types. For example, both `#inst "..."` and `(eval '(Date. ...))` are separate types: TaggedLiteral and java.util.Date respe…

Right.

Re: Dueling Rhetoric of Clojure and Haskell

#27

Post by brandonbloom »

platz wrote: post #10
christophilus wrote: post #3

I wanted to like Haskell, but just never could get to the point where I enjoyed using it. It always felt messy and complicated to me. I think the language extensions were a contributor to these feelings. I also felt as if I spent more time wrangling with the type system than actually solving my business problems. Yet I really do like Clojure, F#, and PureScript. There's an experimental C++ back-end to PureScript now…

I am unconvinced of the practical utility of what row types give you for the added complexity. The proposal to remove the Eff type (going back to IO) from purescript is telling

It's not surprising though, since usefully typing control effects with delimited continuations would require at least answer type polymorphism, but even more usefully something like session types.

Re: Dueling Rhetoric of Clojure and Haskell

#28

Post by dukerutledge »

hristov wrote: post #21
dukerutledge wrote: post #7

Earlier quoted context omitted.

I'd gladly storm into the breach with you :) Hopefully we all agree that static types and dynamic types are useful. Those who use hyperbole are attempting some form of splitting. I think the point where we disagree is what the default should be. The truth is this discussion will rage on into oblivion because dynamic types and static types form a duality. One cannot exist without the other and they will forever be ent…

Well, I think that static types are much more useful than dynamic ones. Static types allow you to find errors with your program before execution and that is very important. And if you are going to go through the effort of defining types, it is much better to use static types because then you get this additional error checking. Furthermore, with static types the compiler can help in other ways, e.g. by organizing your…

I'm speaking about a philosophical dual.

For example: http://www.taoism.net/ttc/chapters/chap02.htm

Re: Dueling Rhetoric of Clojure and Haskell

#29

Post by weavejester »

wz1000 wrote: post #9

A dynamically typed language is a statically typed language with precisely one type. It is extremely easy to use haskell in "dynamic mode". Just use `ByteString`(or Data.Dynamic for safety/convenience) for all your data. Types just present a way to encode some statically known guarantees about the structure of your data/code. You are free to not encode any properties if you want to. But it is very rare that the data…

"A dynamically typed language is a statically typed language with precisely one type."

You still have types; they're just not checked at compile time.

Re: Dueling Rhetoric of Clojure and Haskell

#30

Post by dualogy »

christophilus wrote: post #3

I wanted to like Haskell, but just never could get to the point where I enjoyed using it. It always felt messy and complicated to me. I think the language extensions were a contributor to these feelings. I also felt as if I spent more time wrangling with the type system than actually solving my business problems. Yet I really do like Clojure, F#, and PureScript. There's an experimental C++ back-end to PureScript now…

> There's an experimental C++ back-end to PureScript now [0]. I wonder if that will ever be a viable production target?

Obligatory reminder to anyone enjoying PureScript so much they want to compile it to executable binaries for their backend work (instead of Node or such) --- I'm still hacking along on my PureScript-to-Golang trans/compiler (GH to follow in profile if interested). Unlike most alternative backends (to date) it's not a parallel fork of the purs compiler but works off the official purs compiler's `--dump`ed intermediate-representation files. Seemed more tractable to me to do it that way.

Post reply on HN