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

61–70 of 107 posts

Re: Dueling Rhetoric of Clojure and Haskell

#61

Post by dustingetz »

enugu wrote: post #57

Watching Hickey's talk, many of the complaints seemed to be valuable, but they didnt seem to be about static types . Rather, it was about some problems with existing data types locking one into a rigid data model when the domain is constantly expanding. This post by DeGoes makes the same point. http://degoes.net/articles/kill-data The default model of algebraic data types is too inflexible. There are different extens…

OMG thank you for that link DeGoes nailed it.

Data is just information, it doesn't care about it's implementation and is portable across platform and language.

You can attach your monads to an #error value when you parse it. Or not, if you happen to parse it in Python.

Re: Dueling Rhetoric of Clojure and Haskell

#62

Post by kreetx »

Xephyrous wrote: post #58
jstimpfle wrote: post #36

Earlier quoted context omitted.

> That said, Python is also smarter than me. The possibilities with monkey patching and duck typing are endless. Don't do it, 99.9% of the time. It's that simple. There is seldom a reason to use more than just defs - and a little syntactic sugar (like list comprehensions) just to keep it readable. Even the use of classes is typically bad idea (if I do say so). Just because: there is no advantage to using it, except w…

Classes definitely give you a lot of rope to hang yourself with (metaclasses, inheritance, MULTIPLE inheritance), but they have their place. I'll usually start with a function, but when it gets too big, you need to split it up. Sometimes helper functions is enough, but sometimes you have a lot of state that you need to keep track of. If the options are passing around a kwargs dictionary, and storing all that state on…

Yup, this open field to do whatever with meta classes, inheritance, properties, etc. was what hanged my interest. Since all this "multiple meta monkey patching" was possible, there was no way of telling (for me) what's a good way to implement something in an elegant way. Simple was not good enough, but complex had no rules.

Re: Dueling Rhetoric of Clojure and Haskell

#63

Post by dustingetz »

tome wrote: post #49

What's really sorely lacking from these discussions is concrete examples of functionality that's easy to write in Clojure and hard in Haskell. I don't mean functions like `assoc-in`. I mean real functional parts of programs.

It's about the way you think, not about what you can and can't do. Haskell lets you safely think the really complicated types needed to do programming with zero effects; you couldn't think those thoughts without Haskell because the types we use today are too complex. Clojure encourages you to think in terms of data, to push as much logic as possible out of the code and into the data, and then write simple programs to transform that data.

http://hyperfiddle.net/ (my startup) is an example of a data driven system. Hyperfiddle itself is implemented as a large amount of data + 3000 loc to interpret it. If the system is only 3000 loc, you're really not at the complexity scale where all that category theory gymnastics really pays off.

Re: Dueling Rhetoric of Clojure and Haskell

#64

Post by dustingetz »

GreaterFool wrote: post #13
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…

It's a little bit more than just a cute intellectual puzzle. One could build an efficient EDN library based on that or very similar type. See Haskell's JSON library: https://github.com/bos/aeson/blob/master/Data/Aeson/Types/In... > though the Clojure expressions are a little leaner Yes they are. The price is complete lack of type safety. And the benefit is an insignificantly small reduction in boilerplate code. The n…

EDN is not JSON. EDN is Extensible. OP has everyone in this thread arguing about a strawman.

Re: Dueling Rhetoric of Clojure and Haskell

#65

Post by tome »

dustingetz wrote: post #48

EDN ( Extensible Data Notation) is extensible in userland, which is the whole point of it. This is JSON plus some extra types. . . . r/clojure on JSON vs EDN: https://www.reddit.com/r/Clojure/comments/6gytlf/json_vs_edn... Transcript of Rich Hickey EDN talk which OP obviously hasn't seen: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... Transcript of Rich Hickey talk OP linked, C-f "edn": https://githu…

Would you care to expand on that? It's not clear what you mean, neither from your comment nor the linked Reddit post.

> Transcript of Rich Hickey talk OP linked, C-f "edn":

What do you mean? There are these three occurences of "edn", none of which is enlightening.

* That's great, I'll start shipping some edn across a socket and we're done.

* How many people ever sent edn over wire? Yeah

* So the edn data model is not like a small part of Clojure, it's sort of the heart of Clojure, right? It's the answer to many of these problems. It's tangible, it works over wires

It sounds like he mostly cares about edn because of wires.

Re: Dueling Rhetoric of Clojure and Haskell

#66

Post by tome »

tome wrote: post #46
bad_user wrote: post #42

Earlier quoted context omitted.

Being able to work with "Any" implies either working with Strings (since you can encode anything in strings) or it implies a memory unsafe language (e.g. working with void* in C) or it implies subtyping and hence an OOP language. But OOP subtyping is already about solving polymorphic call sites at runtime. And because you carry a vtable around for every instance, thus objects being tagged with their classes, you can…

> No, you cannot do ": Any" in Haskell. https://hackage.haskell.org/package/base-4.10.0.0/docs/Data-...

On second thoughts I think kod used Any to mean something like Dynamic and bad_user assumed Any meant a top type, something like I believe Scala has.

Re: Dueling Rhetoric of Clojure and Haskell

#67

Post by dustingetz »

tome wrote: post #65
dustingetz wrote: post #48

EDN ( Extensible Data Notation) is extensible in userland, which is the whole point of it. This is JSON plus some extra types. . . . r/clojure on JSON vs EDN: https://www.reddit.com/r/Clojure/comments/6gytlf/json_vs_edn... Transcript of Rich Hickey EDN talk which OP obviously hasn't seen: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... Transcript of Rich Hickey talk OP linked, C-f "edn": https://githu…

Would you care to expand on that? It's not clear what you mean, neither from your comment nor the linked Reddit post. > Transcript of Rich Hickey talk OP linked, C-f "edn": What do you mean? There are these three occurences of "edn", none of which is enlightening. * That's great, I'll start shipping some edn across a socket and we're done. * How many people ever sent edn over wire? Yeah * So the edn data model is not…

You have the primary source right in front of you!!!!!!!! What do you need me to explain it worse for? Print out the damn paper, sit down with a highlighter and read. FFS.

Re: Dueling Rhetoric of Clojure and Haskell

#68

Post by tome »

dustingetz wrote: post #63
tome wrote: post #49

What's really sorely lacking from these discussions is concrete examples of functionality that's easy to write in Clojure and hard in Haskell. I don't mean functions like `assoc-in`. I mean real functional parts of programs.

It's about the way you think, not about what you can and can't do. Haskell lets you safely think the really complicated types needed to do programming with zero effects; you couldn't think those thoughts without Haskell because the types we use today are too complex. Clojure encourages you to think in terms of data, to push as much logic as possible out of the code and into the data, and then write simple programs to…

That's not especially convincing to me. Haskell also encourages me to "think in terms of data, to push as much logic as possible out of the code and into the data, and then write simple programs to transform that data.".

Re: Dueling Rhetoric of Clojure and Haskell

#69

Post by dustingetz »

tome wrote: post #68
dustingetz wrote: post #63

Earlier quoted context omitted.

It's about the way you think, not about what you can and can't do. Haskell lets you safely think the really complicated types needed to do programming with zero effects; you couldn't think those thoughts without Haskell because the types we use today are too complex. Clojure encourages you to think in terms of data, to push as much logic as possible out of the code and into the data, and then write simple programs to…

That's not especially convincing to me. Haskell also encourages me to "think in terms of data, to push as much logic as possible out of the code and into the data, and then write simple programs to transform that data.".

c-f "degoes" in this thread

Re: Dueling Rhetoric of Clojure and Haskell

#70

Post by tome »

enugu wrote: post #57

Watching Hickey's talk, many of the complaints seemed to be valuable, but they didnt seem to be about static types . Rather, it was about some problems with existing data types locking one into a rigid data model when the domain is constantly expanding. This post by DeGoes makes the same point. http://degoes.net/articles/kill-data The default model of algebraic data types is too inflexible. There are different extens…

> [Monad's] motivation is purity.

This is not true and it's important to clear up this misconception lest anyone thing "the only good reason to use monads in Haskell is because it's a pure language".

* The use of monads in functional programming arose purely technically as an innovation in denotational semantics

* Then someone noticed you could use it to wrap up IO purely in Haskell

* Then it was noticed you could use it for all sorts of other stuff besides dealing with IO in a pure language.

Monads are only a little bit related to purity.

Post reply on HN