Hacker News Reader

1. I don't think they define too many specialized operators personally; Haskell's heritage is more "mathematical" than many other languages so it makes sense that many variables are single letters and operators are defined with symbols instead of reallyLongAndDescriptiveName. It's part of learning the idioms of the language.

2. They should never use the same symbol. As the parent said, if you want the generalized notion of a monoid then use that (<> or mappend), otherwise each library should not be conflating its instance of a TypeClass with other libraries' instances of a TypeClass - it is confusing and you end up with stuff like:

    import Some.Lib as L
    import Some.Other.Lib as OL
    
    (L.+) 2 3
    (OL.+) "2" "3"

vs.

    import Data.Monoid
    
    (Sum 2) <> (Sum 3)
    "2" <> "3"

Which is inevitable for some libraries (Fay for example re-defines a lot of Prelude functions) and sometimes accidental; but it is confusing and bad design unless you define a way to generalize it (Monoids!).

5. Data.Aeson uses ByteStrings for the JSON serialization, when encoding/decoding you provide your own instance defining the Types (can be Text/String/ByteString) so I don't understand your gripe here; Text.Regex shouldn't be used for Data.Text, that's what this package is for: http://hackage.haskell.org/packages/archive/text-icu/0.6.3.5...

When you want to encode and decode JSON data of unknown format then you need to use the encode and decode functions directly which operates on ByteStrings. You really don't want to create a new record for each possible kind of JSON data container you have.

text-icu is an experimental 3rd party binding and doesn't work like pcre anyway. It's not something you would use over Haskell's standard library regexp support, so you still have to deal with X number of different string types.

True re: encoding or decoding; but it does make sense to me to keep it in ByteStrings as that is an efficient representation - from ByteStrings you can do what you want with it (convert it to Text).

I personally haven't used the Text.ICU package but I know many, big, packages that retain the "experimental" flag. So that shouldn't necessarily deter usage; just because it's 3rd party doesn't mean it's bad either - many fundamental components of the Haskell ecosystem are 3rd party! There are also many libraries that implement bindings - I don't necessarily see why that is a bad thing either; obviously a pure Haskell approach would be nice but in some cases it does defeat the purpose to reinvent something.

What I do agree with you on, though, is the lack of clarity in what should be used. I think the Haskell Platform is a good start in that direction but there are few docs written on "this is how you deal with strings and unicode in Haskell and all the libraries we recommend for it".

The good news is, this language has the capability to serve both the research needs of academics and the practical needs of implementers; so uncovering this stuff is very good.

2. Enough languages don't conflate ring addition and string concatenation (in TIOBE order: C, Obj-C, PHP, Visual Basic (somewhat), Lisp, Ada, MATLAB, Lua). Furthermore, there are at least two "sensible" monoids on numbers (sum and product), but just one for strings (concatenation). `+` implies something more specific than a generic monoidal concatenation operator. Though I think `++` was a poor choice, one of many in the standard Prelude.

And Perl AFAIR.

2. They are not even remotely the same operation. ++ appends to a list, + sums two numbers. You wouldn't expect an Integer in, say Java, to have an append method, would you?

1. I would not say that HXT is important to the Haskell ecosystem. Lens, yes. Arrows, maybe. The lens library has a lot of infix operators, but they were carefully designed in a structured way. Once you understand the naming patterns you're good to go, and you will be able to figure out the operators you need by construction according to the convention.

1. I don't know that I would consider any of the 3 you mentioned as being so important to the haskell eco-system. Does anyone use Arrows? Lens is new, and there is widespread "whoa that is way too many operators dude" reaction to it. It is not widely used yet at all.

2. Because they are not the same operation. The fact that some languages make them the same operator is not an indication that doing the wrong thing is good. And I do not believe most mainstream languages make that mistake. Again, there is a name for the general concept of "things with an identity and some form of append operation". The name is monoid, it defines the exact operator you want: <>

5. I don't see the problem here. Of course aeson encodes to and from bytestrings, json specifies an encoding already. The entire purpose is to take data, and encode it as a bunch of bytes. You shouldn't be trying to split encoded json as if it were a string, so what is the issue? Your contrasting it with python weakens your point, as it makes it clear that haskell only has one more option than python does.

> Does anyone use Arrows?

Yes, every day! Specifically (&&&), (*), first and second.

[Edit: that's supposed to be three stars, but some of them were eaten by Markdown]