papsosouid

See, this is exactly the sort of ridiculous, reactionary nonsense at the heart of these crusades. No, touching someone's shoulder is not rape. You may define yourself as the moral minority, selflessly protecting everyone from imaginary evils, but your opinion is a tiny, minuscule, insignificant minority. Virtually everyone disagrees with you.

The kickstarter was for publishing a book, not paying someone to assault people.

How about the millions of people who didn't complain? Just because a handful of people who literally spend their entire lives seeking things to be offended by complained about something, doesn't mean their opinion is the majority, or more valid than anyone else's.

>You do not get to treat a group of people as property for thousands of years

Ignoring the fact that your scenario is absurd hyperbole, and men had things just as shit as women did, the you in question wasn't involved. Nobody in this discussion ever owned a woman. Pretending they committed some horrible crime to justify your prejudice is pathetic.

Lots of girlfriends of 5 years would say the answer to that question is "yes, absolutely".

It doesn't matter where it is, or how often it is. People don't want both sides, they want to be outraged.

I don't even know what anything in your post means. You are correct that haskell is not an OOP language. You are very confused beyond that point.

Wait, are you saying you don't know anything about haskell at all? Then why are you making claims about what it can't express?

Huh? How is:

    Monad m => Int -> m Bool

not nominal subtyping in action? Any type you create a Monad instance for will be accepted, so subtyping. You have to actually make it an instance of Monad, it can't just have the structure of a monad, so nominal.

It is also rather broken, and the author doesn't appear to care. I'd second the suggestion to avoid it.

Unfortunately, I don't know of anything. http://database-programmer.blogspot.ca/ is good for learning about how to use a database as a database instead of a persistent hash table, but it doesn't really address the why of it so much.

I understand optimizing haskell is a harder problem, but I don't mean producing optimized binaries, I only need to do that once in a while. I have to compile it thousands of times while developing, and turn off optimizations there since it is just a waste of time. But non-optimizing ghc is still incredibly slow. Wasn't yhc much faster than ghc back when it existed? Surely it must be possible to make ghc fast enough that development isn't seriously hindered?

How is laziness making ghc slow? Completely strict code doesn't compile any faster, and writing completely lazy ocaml code doesn't compile any slower. How would purity make compilation slower? I want specifics here because it is a specific, factual claim. My opinion on frameworks was left somewhat vague as it is simply my opinion and I had no reason to think anyone wanted more specifics on it. I'm happy to be more specific if you like, what did you want to know?

You are going to have to be detailed and specific if you want that statement to be taken seriously. Ocaml is very obviously quite similar to haskell. What specifically is so much more work about compiling haskell? And why does only GHC suffer from this extra work while other compilers were able to compile haskell code in reasonable time and space?

It seems like snap is headed in the yesod direction. By that I mean the "faithfully replicate the mistakes of php/mysql worst practices as interpreted by rails", not the "conflate type safety with DSLs". Happstack doesn't appear to be overly damaged by phpisms, but happstack-foundation isn't useful for a lot of people because it uses acid-state for storage. Also, HSP is terrible and using it should be a criminal offence. So you basically have to build your own collection of stuff as you go on top of snap or happstack-server and the various glue packages for happstack.

I don't buy the "but the compiler is working hard" excuses for ghc's horrible performance. Ocaml is a similar language, and it compiles similar projects in 1/10th the time, and in 1/20th the RAM. It is a huge issue on large projects, waiting 30 seconds for a single line change to compile is brutal, and that 30 seconds ends up being 5 minutes because you get distracted while waiting.

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.

1. What library are you complaining about? Haskell has a pretty small, well established set of operators. If a library is defining more operators than you like, then don't use it. That is no different than a library defining functions with names you don't like, it happens in every language.

2. Why on earth would string concatenation be the same operator as addition? That isn't the same operation. I want to know if I used + that I have to have gotten a number, or else it won't compile. Getting a string would be very unhelpful. If you just want any monoid, then there is a generic operator for that, it is <> or mappend.

5. The different types are for different purposes. String is a list of chars. You use normal list functions on it. Bytestring is not a string, it is an efficient container for storing bytes. It is used for things like networking. Text is an encoding aware, efficient representation of strings. Use this for text data. There is an IsString typeclass for generic functions that operate on any type that can behave like a string.

7. I've always heard the exact opposite from everyone, and my experience has also been the opposite of yours. The only other computer related community I have seen that is as helpful as haskell is postgresql.

Records are annoying, but can be worked around. The compiler is incredibly slow and uses tons of RAM (I need 2GB to compile my simple little web app for example). The slow compile times can start to really kill productivity on large projects. The web frameworks are all pretty focused on trying to reproduce industry worst practices rather than doing things right, so if you are doing web development and you don't want your app to be a mess, you are kinda on your own. That's pretty much it.

edit: to clarify on the web thing, when I say "on your own" I mean you won't be able to get much from existing tutorials and examples since you will want to do everything differently. Not that you will have to write your own framework.

You do realize you are saying "skeptics are skeptical" right? They don't suddenly become monsters when that skepticism is towards feminist mythology instead of christian mythology.

Being a skeptic means you are someone who is skeptical. It does not come with a membership to a club. Just because you dislike some other people who are skeptical, does not mean skeptics are bad and you need to stop being one. I am sure you dislike some people who wear pants too, but you continue to wear pants anyways.

All that said, his assessment of the people he dislikes is incredibly superficial and childish. What exactly was the point that you hoped to make by posting it?

>Robin Milner. A theory of type polymorphism in programming. Journal of Computer and System Sciences, 17:348-375, August 1978

It is in the top 5 and yet none of the go developers will acknowledge that it exists.

Cross browser compatibility is fine without putting in javascript (which people frequently fail to test cross browser and ends up being wrong and broken). Modern browsers get the best experience, old crap browsers get a degraded but still functional experience. You don't need to try to make everything the same everywhere, just make it work everywhere.

Except that the form is already validated client side by the input elements, that's the point. It doesn't make any sense to validate it twice client side.

>Devs should still rely on validation scripting prior to a form submission (js)

Why? Adding redundant code that doesn't solve a problem is always a bad idea.

You mean "most desktop browsers are fairly useless". Go complain and get them to fix it. Html5 inputs are very old, there is no excuse for "modern" browsers not to support them. It is much better for users if they get the same, consistent date picking widget everywhere, rather than a different, partially working maybe sometimes javascript version on every site.

Wow. Apart from how terrible that is, I am pretty impressed at the hypocrisy. "Stop using logic to try to shut down discussion. On an unrelated note, stop talking because misogyny/islamophobia/SJW nonsense."

>Generics are used to defer type setting from compile time to run time, allowing for flexible, yet type-safe constructs.

No. Some languages implement it that way, but nothing about the concept involves moving anything to run time. In languages with reasonable type systems, there is no run time involvement at all.

>I fail to see how saying that one likes replacing callbacks with channels translates to saying Go is "perfection incarnate".

It isn't. It is saying "I don't realize that this is actually worse than what lots of languages provided before go even existed, so I think it is awesome". Which is the point of the blub response. Go isn't interesting, it is blub.

Unfortunately, that is their thought process. I find it hard to believe Rob, Russ, etc actually genuinely have never heard of ML, but everything they ever say on the issue suggests that is the case. And when people keep showing them "hey look, this problem was solved 30 years ago!" they just outright ignore them and don't acknowledge it.

>I'm not sure what your point is, whether you think go is simple and powerful like lisp, or the new java

Really? I find it hard to believe you can't tell what is intended. It certainly is applicable to the article, as the article can be summarized as "I've moved up a language on the blub line, and now my old perfect language is clearly inferior, but my new blub is perfection incarnate".