EDIT: deleting this post because it was needlessly counter-inflamatory.
Dueling Rhetoric of Clojure and Haskell
11–20 of 107 posts
Re: Dueling Rhetoric of Clojure and Haskell
#12I 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
Do row types add a lot of complexity?
Re: Dueling Rhetoric of Clojure and Haskell
#13> 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 number of bugs I've seen where somebody would "get" a number that turned out to be a string or string that turned out to be a number...
Re: Dueling Rhetoric of Clojure and Haskell
#14A 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.
While technically true, saying this is about as useful as saying "You can do anything in any Turing-complete programming language."
Re: Dueling Rhetoric of Clojure and Haskell
#15A 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. While technically true, saying this is about as useful as saying "You can do anything in any Turing-complete programming language."
The point is, types give you an option to encode invariants at compile time. You can choose to use this to your advantage, or not use it at all(use ByteString for everything).
With dynamic types(or just one type), you don't even have the option to do this.
Re: Dueling Rhetoric of Clojure and Haskell
#16Earlier quoted context omitted.
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
Do row types add a lot of complexity?
I think they add more complexity if you have to track and spell out each effect that is being added or removed from the stack
Re: Dueling Rhetoric of Clojure and Haskell
#17Earlier quoted context omitted.
> A dynamically typed language is a statically typed language with precisely one type. While technically true, saying this is about as useful as saying "You can do anything in any Turing-complete programming language."
The point is, types give you an option to encode invariants at compile time. You can choose to use this to your advantage, or not use it at all(use ByteString for everything). With dynamic types(or just one type), you don't even have the option to do this.
Except I really don't have that choice because the language and library design matters. If I chose to use ByteString for everything, I'd first have to implement Tcl in order to get anything done.
But, yes, you're right, most dynamic languages lack good tools for stating invariants and checking them early. I would like to see that change. However, I'd rather the solution account for runtime dynamism, extensibility, and partiality. We're _slowly_ getting there with more and more advanced type system features. It's time to take that knowledge and repackage it at the foundational level of typed languages.
Re: Dueling Rhetoric of Clojure and Haskell
#18EDIT: 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
Re: Dueling Rhetoric of Clojure and Haskell
#19The 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,…
The fact that Haskell is smarter than me is exactly why I have been keeping at it!
I tend to think of Haskell as an eccentric professor.
Sometimes it's brilliant and what it's developed lets you do things that would be much harder in other ways.
Sometimes it just thinks it's clever, like the guy who uses long words and makes convoluted arguments about technicalities that no-one else can understand to look impressive, except that then someone who actually knows what they're talking about walks into the room and explains the same idea so clearly and simply that everyone is left wondering what all the fuss was about.
Re: Dueling Rhetoric of Clojure and Haskell
#20Fwiw, 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])