dpratt71

> which string type do I use?

I think this issue is way overblown. The reasons for choosing a particular string representation in Haskell are analogous to the reasons to choose among e.g. byte arrays, streams, string builders, etc. in mainstream programming languages.

> Which prelude?

There is a standard prelude. Unless you actively choose another one, that's the one you'll get.

> Which compiler extensions?

If you want to use certain advanced language features, enable the appropriate extensions.

> Which testing library?

Many mainstream programming platforms (e.g. .NET) have multiple popular testing libraries to choose from. Is this a bad thing?

Various parts of an algorithm/procedure are related to each other in various ways. Sometimes those relationships describe a sequence. Other times they do not. For me, this is the essence of functional programming: a means to describe how the many small parts of an algorithm are related to each other in the whole (in a natural way).

If the computation truly is one that is most practically described as a sequence of steps, that is easy to do. In fact, in some sense this is what the infamous "Monad" concept is all about.

I don't think it makes sense to characterize Haskell as "big" on this basis, because 1) it is trivial to define an operator in Haskell, so there's bound to be a lot of them and 2) even the "standard" operators typically have a simple definition (e.g. https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/...).

There is no mention of starvation in the title of the article nor in the text. I'm not sure why it's in the title of the submission. There is a link to a related article "2009: Ala. Sheriff Jailed For Starving Inmates". I assume it's the same article referenced in this article:

"In 2009, then-Sheriff Greg Bartlett of Morgan County was briefly tossed in jail after acknowledging that he had personally profited, to the tune of $212,000, from a surplus in the jail-food account. Prisoners testified about receiving meager meals."

Still, I don't see the justification for the use of the word "starvation" in that context, either.

This reminds me that we had a cat that developed diabetes. Besides the usual treatment, we changed the cat's diet "radically". Eventually the cat no longer required insulin shots, i.e. it was "cured". I remarked to my wife at the time that maybe the reason T2 diabetes is considered incurable is that it's all but impossible to get humans to radically change their diet.

As we have recently adopted TypeScript, this is a nice affirmation, but preventing bugs is only part of the benefit and I'm not sure it's the most important part.

TypeScript, in conjunction with a code editor that supports it, significantly improves the code editing experience. Sometimes I still have to chase down documentation, examples, etc. to figure out how to use something, but it happens far less often. In general, I feel like I can code faster and with more confidence.

I assume all this is also true of Flow, though I've never used it.

TypeScript is certainly not flawless and there are tradeoffs. But this is not a good argument against TypeScript. The point of TypeScript and any other statically typed programming language is to have type checking performed statically, that is before the code is actually translated into machine instructions and run.

Here is something I think we are close to agreement on. Companies have made food more addictive, cheaper, more shelf stable in a variety of ways, to the detriment of nutritious food and consumer health in general. But unless we put the focus on the real issues with modern food, I don't think we will see much if any progress. In fact, I suspect that food companies and food scientists are up to the challenge of making food that is just about as cheap and addictive and shelf stable as the current stuff is without using any "artificial" chemicals. I mean, when "nitrate free" bacon can be sold that is, in fact, chock full of nitrates, the possibilities are endless.

When people refer to "chemicals" in food, without distinguishing what type or category of chemicals, I tend to assume that they have an agenda of frightening an uninformed populace or that they are a member of that uninformed populace themselves.

What is "he" right about, exactly? You say "yes they can be useful", but that's not the impression I get from OP. I am also confused because the very quote OP is responding to states that "...type systems are not enough to prevent all the problems in logic and programming...". Do you consider that acting like type systems are a cure-all?

It could be at least argued that type systems aren't very effective at reducing meaningful bugs and/or aren't worth the costs they impose, but you went way beyond that argument. As I see it, the only way you can believe that "nothing suggests that type systems...can be improved to be practical at preventing bugs" is because you have willfully ignored or completely discounted every bit of evidence you've encountered that suggests otherwise.

I know that mice have been used very successfully to study many diseases and conditions that can also affect people. But are mice a good human analogue when it comes to diet?

I don't have time to find citations at the moment, but I seem to recall that the original studies linking consumption of saturated fat with...bad things (high cholesterol, etc.) were originally done with mice and more recent studies involving actual humans have failed to find a connection between consumption of saturated fat and the aforementioned bad things.

There is a fellow by the name of Jon Harrop who has in times pasted "showed up" when Haskell came up for discussion. To say that he does not like Haskell is putting it mildly. I have the impression that the mere existence of Haskell is a personal affront to him.

What struck me about your post was how much it sounded like something he would write, in particular the interpretation of facts (a strictness pragma was recently introduced to Haskell) in the most extremely negative way possible (said pragma is admission that Haskell's default evaluation strategy is simply "wrong").

If you are not he, you should look him up, as I expect you two (?) would get along fantastically.

I bought a T-fal "professional" 8" non-stick skillet about a year and a half ago. I do a poor imitation of Jacques, complete with metal fork, several times a week. The skillet has held up.

I'm not a math guy either and I did indeed find it difficult to penetrate the inner sanctum of Haskell for this very reason. I won't say I've completely succeeded in that effort, but I've come quite a long way.

I'm fairly certain that in this context, non-determinism means that there can be more than one answer/result.

I think it could be argued that the behavior you ascribe to humans exists for the same reason that some dogs chase after cars. That is, it is an ingrained behavior that tends to enhance our survival and is sometimes expressed or triggered in contexts where it doesn't really make sense.

In truth, I believe that life has a spiritual dimension, that my life has purpose, blah blah blah, but I find it useful on occasion to temporarily 'forget' that I believe such things.

Why would bees willingly share with humans?

That makes sense, thank you.

Does someone want to take on the challenge of explaining the basics of this to a lay person? For starters, I don't understand the relationship between the scatter plot and the contour plot. I would guess that the blue (?) dots relate to the darker areas of the contour and the red dots to the lighter areas.

<> is a placeholder for an operation (a function, really) taking two inputs, mempty is a placeholder for a special value, and x and y are placeholders for arbitrary values. If you can find something that fits the pattern, then it is a monoid. Such as where <> is addition, mempty is 0, and x and y are numbers. Or where <> is string concatenation, mempty is the empty string, etc.

Yes, although there is also https://en.wikipedia.org/wiki/Hague_Adoption_Convention

How about a really long comment instead? :)

This was our second adoption. The first was for an infant. We planned for another infant adoption for #2, but several things conspired to change that.

The first of those was that the political winds in country of child #1 had changed such that the adoption programs in that country were practically at a stand-still. So we looked around. I believe that Ethiopia was the only other place we could adopt from due to our age/income/etc.

For our first adoption, we were given a referral. Basically, this is your child, take it or leave it. For our second adoption, we were given a video of all the children in the orphanage...oldest first. We were told that the orphanage would only house children up to age 12. And we learned that the prospects for children who had "aged out" were not very good.

So we decided to adopt one of these older children. And since we had clearly lost our minds, we called the adoption program director and asked her for advice. She said that she always gives people the same advice: "If you can possibly adopt two children at once, do it". We were obviously completely out of our minds, because we took her advice.

Of course it was very challenging at times, especially at first, for both us and them. But I am so glad we took that advice. The feeling of isolation that children in these situations have to face...it's probably the hardest part for them. And it makes sense to me that in any situation, no matter how hard, it's much easier when there is someone in your same situation you can talk to about it.

We are in contact with many other families who have adopted older children. It seems obvious to us that our girls have dealt with those challenges better than most.

There is a documentary that aired on PBS, "Girl, Adopted" about a girl adopted from the same orphanage as our girls at around the same time. I could definitely identify with a lot of what is depicted in that program, but...I think it was just a bit harder for Weynsht and her family than it was for us. Alas, it isn't free ($10 for streaming/download): http://www.girladopted.com/

Not exactly, but...we adopted two thirteen-year-old girls from Ethiopia. They're 24 now. One of the best decisions of my life.

In everyday English, when someone mentions sugar, they are probably talking about sucrose aka 'table sugar'. And you are correct that sucrose consists of a glucose and fructose molecule bonded together.

In a more...official or scientific context, "Sugar is the generalized name for sweet, short-chain, soluble carbohydrates, many of which are used in food." as Wikipedia puts it. That means that sucrose, glucose and fructose (and many others) are all considered to be sugar.

Maybe I missed the point, but you seem to be implying that you need to eat things with sugar mentioned on the label on a regular basis to keep your brain functioning normally.

I think SQL is a far leakier language than Haskell in terms of the correlation between code and performance, but it seems to have achieved a measure of success even in situations where performance is critical.

Indeed. There is something very familiar about the tone and content of these posts from haskeldownvot5. There was another individual that achieved a degree of infamy within the Haskell community for posting similar screeds to various forums. The claims that the Haskell community can't accept criticism, the accusations of the same 'lying' about performance, the referring to 'lazy evaluation' as though it were a carcinogen, the aspersions cast against the education of various individuals, both specific and non-specific...yes, all very familiar.

I think there's some interesting psychology at work here. haskeldownvot5 is clearly inviting downvotes by his/her choice of username as well as the contents of his/her posts, but I think haskeldownvot5 has managed to convince himself/herself that there is some cabal within the Haskell community that is responsible for the downvotes. There must be a name for the phenomenon where an individual brings things upon themselves and then uses the criticism/persecution they receive as evidence to the fact that they were right all along.

I started to read the first article, but I got confused, so I watched the video. The latter is probably a poor substitute for the former, but assuming the video is accurate (as well as my understanding of it):

Insulin sensitivity seems to recover once the high-fat diet has been curtailed. That makes it a bit different from the usual course of insulin resistance, no?

Along the same lines, it seems to me that a LCHF (low carb, high fat) diet may solve its own problems. What I mean is that while the body may be slow to respond to blood sugar spikes, that situation should be occurring infrequently, if ever.

On the other hand, it makes me wonder if "part-time keto" may be worse than the alternatives. In a situation where you switch from keto to...whatever, I picture fat-laden cells unable to deal with the sudden onslaught of sugar.

I'm a self-taught programmer. I started with Pascal (what seems like an age ago), then C, then VB5/6, then C# and JS and a bunch of other programming languages. At this point I felt like I could pick up about any mainstream programming language very quickly.

And then I tried to tackle Haskell. That was about five years ago, and I think I'm still at beginner/intermediate level with it. But I realized something. These days I have a career and family. Back when I was learning Pascal, I had a lot more time and mental focus on my hands. All the programming languages I've learned since (besides Haskell) were not much different than Pascal, not fundamentally so.

Haskell is fundamentally different. I definitely feel like my past programming experience helped me learn Haskell faster than if I had no experience, but that past experience was also a handicap. I had to discard a lot of assumptions and get to a more basic mindset of what the art of programmming entails. And like a lot of other folks, I found it to be a very rewarding (and useful) experience.

Maybe there is some deep mathematical reason why 'return' is named as such, but I suspect the person who gave it that name was trying (perhaps a bit too hard) to make monadic code appear even more like the imperative code to which most of us are accustomed.

More or less by coincidence, 'return' tends to appear in the same places you would see the 'return' statement in C and derived languages. But the purpose of the 'return' function in Haskell is quite different from the 'return' statement.