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

71–80 of 107 posts

Re: Dueling Rhetoric of Clojure and Haskell

#71

Post by tome »

dboreham wrote: post #51
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…

>"a monad is just a monoid in the category of endofunctors" Once I discovered the Monad thing in Haskell has pretty much nothing to do with the Monad in Category Theory, everything made much more sense. As a bonus I now (sort of) understand Category Theory. Much the same as Relational Databases have not very much to do with Relational Algebra.

This is a very important point although I would slightly tweak this

> the Monad thing in Haskell has pretty much nothing to do with the Monad in Category Theory

to "the Monad thing in Haskell is a very simple special case of the Monad in Category Theory". Thinking you have to "learn category theory" before you can use a Monad in Haskell is like thinking you have to learn this

https://en.wikipedia.org/wiki/Function_space#Functional_anal...

before using a function.

Re: Dueling Rhetoric of Clojure and Haskell

#72

Post by tome »

mitchty wrote: post #56
kreetx wrote: post #34

Earlier quoted context omitted.

No, not " thinks it's clever", but overly clever, yes, often.

I tend to ignore 99% of the clever haskell stuff and get by just fine in Haskell. I keep learning about stuff like GADTs and whatnot, but they're more like the top of the tool drawer special tools than the ones you break out every day. I think people learning/using haskell tend to go for crazy generalized code first, versus what gets me to a minimal working thing that I can expand/change out later. Or I just suck at…

> Or I just suck at haskell

You suck at Haskell about as much as Don Stewart :) In this talk he describes how he builds large software systems in Haskell and eschews complicated type system features

https://skillsmatter.com/skillscasts/9098-haskell-in-the-lar...

Re: Dueling Rhetoric of Clojure and Haskell

#73

Post by tome »

dustingetz wrote: post #64
GreaterFool wrote: post #13

Earlier quoted context omitted.

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.

Then I think you're really going to need to educate us about what EDN really is ...

Re: Dueling Rhetoric of Clojure and Haskell

#74

Post by tome »

dustingetz wrote: post #69
tome wrote: post #68

Earlier quoted context omitted.

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

You know John De Goes is a massive Haskell proponent, right?

Re: Dueling Rhetoric of Clojure and Haskell

#75

Post by tome »

dustingetz wrote: post #67
tome wrote: post #65

Earlier quoted context omitted.

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.

You're not arguing particularly convincingly ...

If you want to explain what an edn really is the I'm happy to listen.

Re: Dueling Rhetoric of Clojure and Haskell

#76

Post by tome »

brandonbloom wrote: post #53
bad_user wrote: post #47

Earlier quoted context omitted.

GHC's repl is completely fine. The thing with dynamic languages is that the development style is basically println-driven. It goes like this: because you can't keep anything longer than a 1-page script in your head and because you can't remember the APIs of other people and hence you can't trust anything you write, in order to keep some sanity, you have to execute every freaking line of code that you write in order t…

These are old tired arguments. I prefer being forced to keep my program simple by making complexity intolerable over encapsulating it. Your preference may differ. I find I have to refactor my dynamically typed programs less frequently than my statically typed ones. Your mileage may vary. No amount of type safety will prove my game is fun, or that my user can understand the UI. I want fast iteration times, since I can…

> since I can’t wait on the compiler to test a new enemy behavior or GUI layout.

Clojure is compiled, isn't it?

Re: Dueling Rhetoric of Clojure and Haskell

#77

Post by tome »

brandonbloom wrote: post #52
tome wrote: post #45

Earlier quoted context omitted.

If no other language has any functionality similar to how Clojure does things then I think we'll need references to explanations or videos before we can even begin to understand your claims!

Clojure is following in the tradition of lisps that do this right. The important bit is the extra indirection on top-level names. I wrote more about it here a long time ago: https://www.brandonbloom.name/blog/2012/12/21/the-nodejs-rep... Also interesting is the other end of the spectrum: Forth. Instead of mutation, offers snapshots and restores of the “dictionary”. See this video: https://youtu.be/mvrE2ZGe-rs

I don't fully understand what you're getting at. It would have been nice to see no examples with code entered at a REPL and the results, in both JS and Clojure, say.

Are you saying that you want to be able to make bindings that are refreshed on REPL reload? For example if I have a file that contains

    x = 1
and in my REPL I write

    y = x + 1
then I change my file to say

    x = 10
and reload the REPL then y is 11?

Re: Dueling Rhetoric of Clojure and Haskell

#78

Post by AnimalMuppet »

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…

> Static types allow you to find errors with your program before execution and that is very important.

It depends on how valuable it is in your situation to be able to run a program that contains type errors.

Sometimes it's a net win. If I'm prototyping an algorithm, and can ignore the type errors so I can learn faster, that's a win. If I'm running a startup and want to just put something out there so that I can see if the market exists (or see what I should have built), it's a net win.

Sometimes it's a net loss. If I'm building an embedded system, it's likely a net loss. If I'm building something safety-critical, it's almost certainly a net loss. If I'm dealing with big money, it's almost certainly at least a big enough risk of a net loss that I can't do it.

Forget ideology. Choose the right tools for the situation.

Re: Dueling Rhetoric of Clojure and Haskell

#79

Post by tome »

AnimalMuppet wrote: post #78
hristov wrote: post #21

Earlier quoted context omitted.

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…

> Static types allow you to find errors with your program before execution and that is very important. It depends on how valuable it is in your situation to be able to run a program that contains type errors. Sometimes it's a net win. If I'm prototyping an algorithm, and can ignore the type errors so I can learn faster, that's a win. If I'm running a startup and want to just put something out there so that I can see…

This is a rather glib response. Of course one should choose the right tools for the situation. Personally if I'm prototyping an algorithm I'd rather do it with types so I don't write any code that was clearly nonsense before I even tried to run it.

Re: Dueling Rhetoric of Clojure and Haskell

#80

Post by enugu »

tome wrote: post #70
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 us…

Yes, sure, monads, applicatives etc. have plenty of applications beyond IO, which is part of why keeping that abstraction separate from any particular use is of value.

My point is that this doesnt have much to do with static typing vs dynamic typing per se, as we dont check them statically. They are just important examples of an interface with implementations for many data types, which can be useful even in a dynamic language like Clojure. People who write a parser in a dynamic language might benefit from learning about distinction between applicatives and monads.

Post reply on HN