Dueling Rhetoric of Clojure and Haskell • Hacker News Board

Re: Dueling Rhetoric of Clojure and Haskell

#81

Post by tome » Wed, Nov 01, 2017, 10:26 PM UTC

enugu wrote: post #80

tome wrote: post #70

Earlier quoted context omitted.

> [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…

Yes I agree. I just wanted to clear up a potential misconception.

Re: Dueling Rhetoric of Clojure and Haskell

#82

Post by taeric » Wed, Nov 01, 2017, 10:36 PM UTC

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…

Amusingly, history is showing that there are as many rewrites from type systems to no type systems as the reverse. Consider all of the things that are getting redone in the javascript world.

Re: Dueling Rhetoric of Clojure and Haskell

#83

Post by brandonbloom » Wed, Nov 01, 2017, 10:49 PM UTC

tome wrote: post #76

brandonbloom wrote: post #53

Earlier quoted context omitted.

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?

Yes, but it’s fast!

Re: Dueling Rhetoric of Clojure and Haskell

#84

Post by AnimalMuppet » Wed, Nov 01, 2017, 10:54 PM UTC

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.

He looked at the primary source, and doesn't see it saying what you claim it says. So he's asking you for where, from the primary source, you found the source for making your claim. Given that he already looked at the source you cited, that doesn't seem like an extraordinary request...

Re: Dueling Rhetoric of Clojure and Haskell

#85

Post by AnimalMuppet » Wed, Nov 01, 2017, 11:12 PM UTC

tome wrote: post #79

AnimalMuppet wrote: post #78

Earlier quoted context omitted.

> 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.

Personally, I work the same way you do. But I've heard enough people who want the faster feedback of a REPL-like environment to accept that their approach at least feels more productive to them. It may even be more productive - for them. If so, tying them down with type specifications would slow them down, at least in the prototyping phase.

Re: Dueling Rhetoric of Clojure and Haskell

#86

Post by brandonbloom » Thu, Nov 02, 2017, 12:34 AM UTC

tome wrote: post #77

brandonbloom wrote: post #52

Earlier quoted context omitted.

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?

    (require '[foo :refer [f]])
    ; edit f in foo.clj
    (require '[foo :reload])
    (f 1) ; should call NEW f.

Node doesn’t have a reload construct. If you hack it in by mucking with the module cache, you still won’t get the new f in your module’s local copy of it.

Re: Dueling Rhetoric of Clojure and Haskell

#87

Post by s4vi0r » Thu, Nov 02, 2017, 12:57 AM UTC

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…

Fwiw, the monad quote is actually pretty digestible if you know what monoids and functors are.

A functor is a container that you can reach into to perform some action on the thing inside (e.g. mapping the sqrt function on a list of ints). The endo bit just tells you that the functor isn't leaving the category (e.g. an object, in this case a Haskell type, when lifted into this functor context is still in the Haskell 'category'). A monoid is something we can smash together that also has an identity (e.g. strings form a monoid under concatenation and the empty string as an identity). So, in other words, monads are functors ('endofunctors') that we can smash together using bind/flatMap, and we have an identity in the form of the Id/Identity functor (a wrapper, essentially - `Id = A`).

Re: Dueling Rhetoric of Clojure and Haskell

#88

Post by escherize » Thu, Nov 02, 2017, 1:13 AM UTC

tome wrote: post #73

dustingetz wrote: post #64

Earlier quoted context omitted.

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 ...

Educate yourselves. https://github.com/edn-format/edn/blob/master/README.md#tagg...

Re: Dueling Rhetoric of Clojure and Haskell

#89

Post by codygman » Thu, Nov 02, 2017, 1:53 AM UTC

didibus wrote: post #35

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…

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 you rewrite with a type system. You seem to be in the camp of gradual types. Which Clojure falls more into, though experimentally. Racket, TypeScript, Shen, C# or Dart are better examples of it. make me smart enough to understand how a statement like "a monad is just a mono…

> Static types are not powerful enough to cross remote boundaries.

?

Re: Dueling Rhetoric of Clojure and Haskell

#90

Post by thinkpad20 » Thu, Nov 02, 2017, 5:09 AM UTC

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’m not a rust user per se, but I’m surprised to see it listed alongside Python and Go as a language without a lot of depth. Rust not only has quite an advanced type system (not Haskell level, but certainly the most powerful of any other language as mainstream), but it can also teach the user a lot about memory management and other low-level aspects of programming that Haskell (and many other languages) hide. I mostly write Haskell for my own projects, but one of these days I hope to get better at Rust.