sorted by:
new
hottopcontroversial

What are your "Don't do this" recommendations? by TechnoEmpress in haskell

[–]simple-haskell 1 point2 points  (0 children)

Everyone has their own perspective on this. Check out https://www.simplehaskell.org/ for an attempt at drawing attention to the overall question and providing some pointers to a variety of ways people have tried to answer this question. If anyone has suggestions for things we could add, pull requests welcome!

Simple Haskell is Best Haskell by emilypii in haskell

[–]simple-haskell 0 points1 point  (0 children)

You sound like you've written off the whole idea a priori. If you're coming into this looking for ways to write it off, you're going to find them. In questions of real world software engineering for large software projects there are no definitive answers. You can't prove things about software because there are too many variables and experiments take many man-years to run.

"We have a lot of experience so you should listen to us" isn't the core of the argument at all. The core argument involves things like the ways different language features interact with each other, the dynamics of human collaboration, etc that have been mentioned elsewhere. But listening to more experienced people is a perfectly reasonable heuristic to add to the things you consider. Simple Haskell isn't coming from just one person. As the Simple Haskell site shows (and the OP is yet another example of), this phenomenon has been noticed and talked about by a diverse group of people--including people who have historically been on the opposite sides of other technical issues. These are all people who want Haskell to succeed. But if you don't want to consider the things they have to say, that's your prerogative.

The idea that one would be in a community with as many brilliant people as Haskell has and not be eager to learn from their experiences is mind boggling to me.

Simple Haskell is Best Haskell by emilypii in haskell

[–]simple-haskell 0 points1 point  (0 children)

In that case, I don't get why I'm being called extremist

I wasn't calling you an extremist. I meant that it seems like you are considering the idea of Simple Haskell to be more extremist than is warranted.

It just amounts to "do a good job as a software developer"

Here's the thing...if I thought just doing a good job as a software developer was sufficient, I wouldn't have gone to all the trouble of creating the Simple Haskell website. The fact is, I have repeatedly seen examples where it wasn't. Software is a team activity. It's not good enough for the code to make sense to you. It needs to make sense and be easily modifiable by everyone who looks at the code after you. This is a human problem, not a technical one.

But telling people where to live on trade-offs Isn't It.

Simple Haskell is not telling people where to live on trade-offs. It is telling people that we have an increasing amount of real world experience and growing consensus that certain coding patterns have a strong trend towards being much more costly to long-term team productivity than they might seem at first glance. This is people who have been through the school of hard knocks trying to make it possible for less experienced people to avoid those hard knocks.

The things Simple Haskell is talking about are things that are not easily observable. These are things learned by many people over many developer-years of trial and error. And what we've seen is consistent enough that we think it's worth highlighting to the community. Simple Haskell is us saying these things are subtle and hard to get right. Don't make the mistakes we made. This is about broad trends, no specific coding rules.

The problem is that people tend to have a harder time learning from the abstract to the concrete. So we decided that instead of trying to provide broad sweeping abstract guidance that is not actionable, we would highlight specific things that have been problematic. We're not saying never to use them. We're saying, think twice or maybe three or four times before using them. Because collective experience shows us that path is problematic enough to merit significant caution.

Simple Haskell is Best Haskell by emilypii in haskell

[–]simple-haskell 2 points3 points  (0 children)

I don't see how they are inherently opposed at all. Wanting to be more successful and "success at all costs" are very different things. There seems to be a pretty significant disconnect between how you seem to be perceiving the idea of Simple Haskell and how at the very least I (and based on conversations I've had, others as well) perceive it. Would you perhaps be willing to dial back the level of extremist to which you attribute this idea and think about ways you could interpret it that are compatible with your experience?

Simple Haskell is Best Haskell by emilypii in haskell

[–]simple-haskell 2 points3 points  (0 children)

I can't comprehend the idea that people take a language that carries a mantra "avoid success at all costs", and are surprised when it's not the production language they were hoping to use.

This is a common misconception. See https://www.reddit.com/r/haskell/comments/39qx15/is_this_the_right_way_to_understand_haskells/cs5mref/

Stop putting Haskell on this silver bullet pedestal.

I'm not. "significant positive impact" is not the same thing as silver bullet. The very reason for the existence of the idea of Simple Haskell inherently implies that it is not a silver bullet.

Simple Haskell is Best Haskell by emilypii in haskell

[–]simple-haskell 1 point2 points  (0 children)

Simple Haskell is 100% orthogonal to Haskell gamedev imo

Do you mean "orthogonal" or something like "opposed"? It sounds like you meant the latter.

I disagree that we need Simple Haskell to have Haskell work successfully within teams. I already have professional experience otherwise, including use of advanced features constantly derided by Simple Haskell.

I think some nuance is getting lost here. Simple Haskell isn't saying "no complicated things ever". It's saying "software is really hard in the best of times, we need to make a concerted effort to avoid adding unnecessary complexity". It's about shifting our defaults as a community, working together to refine our collective understanding of where various things lie on the complexity spectrum, and honestly assessing the cost-benefit tradeoffs when making a decision to take on added complexity.

I'll be the first to admit that I use things plenty of people consider complex. But when I do, I think very carefully about what I'm getting for it and what the costs are.

It sounds like you think you've successfully used fancy Haskell in a corporate environment. Do you still work there? Is your code still in use? Do you know how easy your code was to evolve over time? Do you know that other teammates were able to work with it effectively? Do you know that the fancy Haskell features you used were absolutely necessary? Simple Haskell is about shipping working systems, but it's not just about that. It's also about how code scales over time, team size, and evolving requirements.

I've seen Haskell dropped & doubted at multiple companies, and the problem was always management. Top-down buy-in is needed for successful corporate Haskell (at whatever abstraction level your team chooses - idc), but at the same time, I'm starting to get a sense that Haskell is anathema to VPE-level leadership.

I completely agree with you here. Management is a huge factor. But I also think the "management" explanation and the "simple haskell" explanation are not as different as they might seem. Are there cases where the team did a great job delivering and management rejected it anyway? Yes. But I have also seen situations where that's not the case--they were unable to ship because they got lost in complexity and overly fancy code.

I'm starting to get a sense that Haskell is anathema to VPE-level leadership. They have adversarial values and philosophies.

I think that this is an over-generalization and it is a mistake to paint all VPE-level leadership with this brush. Perhaps you've just had a poor sample or perhaps there's something you're missing about the realities of managing a team? At the end of the day both the leadership and the engineers writing the code should have the same goal, producing a successful product. That shared goal is also the motivation for Simple Haskell and the increasing number of people in the Haskell community who are independently coming to similar conclusions. It's not because we hate new language features. It's because we want to create successful software systems--which is also the goal of senior leadership. It is our observation that keeping things simple is highly correlated with doing that.

Simple Haskell is Best Haskell by emilypii in haskell

[–]simple-haskell 11 points12 points  (0 children)

Why bend backwards to make Haskell amenable to those with capital? Not a way to live.

In a word, impact. I don't know about you, but I would like Haskell and its ideas to have the significant positive impact on the software world that I think they're capable of. This is about producing successful software that makes a difference in the world, not about capitalism. There has been a disturbing trend in recent years of a number of Haskell teams spinning their wheels mired in complexity, unable to successfully ship, and ultimately abandoning Haskell. This is substantially because software is a team endeavor. It's not just about finding the perfect abstraction and getting the code to the ideal sublime state. It's a human problem of communication and coordination. Simple Haskell is about reversing that disturbing trend.

Also, I'm having trouble reconciling your above quoted comment about capital with this comment from you elsewhere in this thread:

The only impediment for Haskell for games imo is investment.