Hello, I've considered myself a member of the Haskell community for well over four years now. What's struck me about the community – since the stumbling start four years ago – is how incredibly warm and welcoming it is. I've always been received with open arms, however dumb I've felt at the time, and people have helped set me straight.
I'd like to keep this quality be one of the pillars of the community. And to a large degree, it is. I don't have any experience with the mailing list, but the IRC channel is really friendly.
However, I've increasingly heard people complain how this subreddit is hostile toward beginners, elitist and other bad things. Recently have I, too, recognised some ways in which beginners get told off. The most recent example is this question on how pattern matching works which at the time of writing has 0 points. The question is polite and friendly, and the author is thankful for the help they get.
I understand it is hard for communities to remain patient with beginners as they grow in size, simply because the beginner section grows fastest of them all. But can we please try to at least not downvote or be unfriendly to beginners?
This subreddit has no rules against beginner questions in submissions. So understandably, beginners will ask here because nobody in /r/learnprogramming knows anything about Haskell. Can we make a collective effort to welcome the beginners with open arms, like I was welcomed four years ago?
As a tutor, I've learned the concept of what I'll for lack of a better word call an "accurate" question. An accurate question is a question that shows a student has understood what they have been told and that they are curious about the ramifications of the concept. Those questions are not necessarily well researched, but they indicate a good learning spirit and they often lead to very interesting discussions.
As a practical example, a student who has just learned about time dilation (i.e. time goes slower as you go faster) might ask "will time go backwards if you go fast enough?" It is a completely unresearched question (the answer is one Google search away) but it shows the student is curious and it shows they have an understanding of the concept of the speed of passage of time decreasing. Follow-up discussions include what it means to go faster than light, what would happen if you would go faster than photons and look back (you'd be seeing "old" photons, in other words travelling back in time?) and why it's impossible to go faster than the speed of light. It's not necessarily a "good" question, but it is an accurate question.
I commonly see accurate questions being almost ignored in comment threads here. Why not upvote them? They often lead to good discussion!
If we don't want beginner questions, we should probably institute rules against them, and redirect them to somewhere else in the sidebar.
Thanks for taking time to hear out my opinion.
TL;DR: Good questions are good questions regardless of how basic they are. Stop downvoting them – it makes beginners think they are unwelcome.submitted by kqr
[link] [67 comments]
Some while ago I was getting frustrated because I couldn't quite get hoogle to work the way I wanted (link) which eventually lead to me writing my first little haskell tool which perhaps might be useful for others as well:
You can use it to create a default.hoo database for all packages used in your cabal project. By default hoogle first searches the current directory for the database file. This way you can perform a search with the scope of your project which I personally find quite useful.
As noted before its my first haskell project so I am certain there are many things that can be done different or better. Suggestions and pull requests are of course more than welcome.
Thanks.submitted by __gilligan
[link] [1 comment]
I'm watching a Haskell tutorial video explaining pattern matching and I'm completely lost. Can someone give me a layman's terms definition explaining what it is and what it does?submitted by ProbablyALinuxUser
[link] [8 comments]
Which Unit Test framework do you use for Haskell, and why? Thanks for your input.
I'm pretty new to testing frameworks in general, but I'm going to give a shot at Test-Driven Development. I'd like a solid, flexible API upon which to build a Unit Test framework for my new project. In particular, I'd like to easily integrate QuickCheck tests with it at a later date. What should I use?
Edit: These are some great suggestions, and I'm going to look into each of them in more detail. Thanks, much.submitted by jpaugh
[link] [7 comments]
FP Complete is looking to expand its Haskell development team. We’re looking for a Haskeller with a strong background in web UI development. This position will encompass both work on our core products- such as FP Haskell Center and School of Haskell- as well as helping customers develop frontends to their Haskell applications.
We will want you to start right away. The will be a contractor position, full time for at least 3 months, with the intention to continue long-term on a more or less full-time basis. Additionally, while the main focus of the position will be UI development, there will be many opportunities to expand into other areas of focus.
This is a telecommute position: you can work from home or wherever you choose, with little or no travel. Location in North America is ideal; you will work with colleagues who are on North American and European hours.
- Strong Haskell coding skills.
- Ideally: experience with both Yesod and Fay for server and client side coding, respectively. (Perk: you’ll get a chance to work with the authors of both tools.)
- Experience deploying applications into production, especially at large scale, is a plus.
- Ability to interact with a distributed development team, and to manage your time without an in-person supervisor
- Ability to work with clients on gathering requirements
- General source control/project skills: Git, issue tracking
- Ability to communicate clearly in issues, bug reports and emails
- Proficient on a Linux system
- Plus: experience with deployment, Docker, and/or CoreOS
Please send resume or CV to firstname.lastname@example.org. Any existing work- either a running website or an open source codebase- which you can include links to will be greatly appreciated as well.
I've heard that my previous blog post has caused a bit of confusion, as sarcasm doesn't really come across in text very well. So let me elaborate (and of course, in the process, kill the joke):
Some years back, Erik found a case that was quite difficult to implement using enumerator. After we cracked our heads on it for long enough, some of us (I don't actually remember who was involved) decided to work on a new streaming library. That library ended up being called conduit (thanks to Yitz for the naming idea). It turns out that most people are unaware of that history, so when at ICFP, I casually mentioned that Erik was the cause of conduit coming into existence, some people were surprised. Erik jokingly chastised me for not giving him enough credit. In response, I decided to write an over-the-top post giving Erik all credit for conduit. I say over the top, since I made it seem like there was some large amount of blame being heaped on as well.
So to be completely clear:
- Erik and I are good friends, and this was just a bit of an inside joke turned public.
- No one has said anything offensive to me at all about conduit. There are obviously differing opinions out there about the best library for a job, but there's nothing offensive about it, just healthy discussion around a complicated topic. My purpose in making a big deal about it was not to express frustration at anyone attacking me, but rather to just play up the joke a bit more.
My apologies to anyone who was confused, upset, or worried by the previous post, it was completely unintentional.
LinkedIn job ad link for openings for severalenthusiastic great Haskell developers (geoloc. globally) atSwedish spin-off Functor Group with subsidiaries + threeScala developer (geoloc. Sweden) with spear-edge / verystrong qualifications and high-end indus
A coworker & I were discussing cabal & sandboxing today and he pointed me to a blog post on setting up a Haskell environment. In it the author states, with much finality:
You should never use cabal sandbox. That way, you will only compile each needed library once. - http://yannesposito.com/Scratch/en/blog/Safer-Haskell-Install/index.html
Now, I understand his point, that you'll save time by having each library compiled globally instead of locally. But, some time ago (probably around cabal 1.15, 1.16 or so) when I was first getting started with Haskell, I remember trying to install Yesod. It didn't take long to delve deep into dependency hell with conflict after conflict. As a beginner this was extremely frustrating. I saw a post somewhere with an introduction to cabal-dev and started using sandboxing with that. Of course when cabal 1.18 came out with sandboxes built in, I upgraded immediately.
I have never had a single dependency conflict issue with cabal since switching to sandboxing. I actually use "sandboxing" now on every platform I develop on (Ruby's bundler with the "--path" option, virtualenv with python, node because npm). Since making this switch, I can honestly say I spend almost no time whatsoever mucking with my environment. I never run into packaging issues on any platform, and if I go away from a project for 6 months, it still works the same when I come back to it.
I've found sandboxing to be tremendously beneficial for me. I can understand why someone might want to avoid it if they don't like the time it adds to installs. For me it's worth it, but it might not be for everyone else.
Given all that, when I see someone say something like "You should never use cabal sandbox" it makes me question whether I'm missing something. Is there some reason besides time that I wouldn't want to use sandboxing? Is it somehow broken or does it cause problems I just haven't ran into yet?
EDIT: See comment below for a clarification on what the aforementioned blog post was referring to. If the author reads this, sorry for hastily criticizing your post, keep up the good work!submitted by joefiorini
[link] [15 comments]
George Monbiot writes stirring stuff on indy. Well-reasoned and well-documented.Imagine the question posed the other way round. An independent nation is asked to decide whether to surrender its sovereignty to a larger union. It would be allowed a measure of autonomy, but key aspects of its governance would be handed to another nation. It would be used as a military base by the dominant power and yoked to an economy over which it had no control. ... Most nations faced even with such catastrophes choose to retain their independence – in fact, will fight to preserve it – rather than surrender to a dominant foreign power....The fears the no campaigners have worked so hard to stoke are – by comparison with what the Scots are being asked to lose – mere shadows. As Adam Ramsay points out in his treatise Forty-Two Reasons to Support Scottish Independence, there are plenty of nations smaller than Scotland that possess their own currencies and thrive. Most of the world’s prosperous nations are small: there are no inherent disadvantages to downsizing.
Remaining in the UK carries as much risk and uncertainty as leaving. England’s housing bubble could blow at any time. We might leave the European Union.
How is the argument altered by the fact that Scotland is considering whether to gain independence rather than whether to lose it? It’s not. Those who would vote no – now, a new poll suggests, a rapidly diminishing majority – could be suffering from system justification.System justification is defined as the “process by which existing social arrangements are legitimised, even at the expense of personal and group interest”. It consists of a desire to defend the status quo, regardless of its impacts. It has been demonstrated in a large body of experimental work, which has produced the following surprising results.
System justification becomes stronger when social and economic inequality is more extreme. This is because people try to rationalise their disadvantage by seeking legitimate reasons for their position. In some cases disadvantaged people are more likely than the privileged to support the status quo. One study found that US citizens on low incomes were more likely than those on high incomes to believe that economic inequality is legitimate and necessary.
It explains why women in experimental studies pay themselves less than men, why people in low-status jobs believe their work is worth less than those in high-status jobs, even when they’re performing the same task, and why people accept domination by another group. It might help to explain why so many people in Scotland are inclined to vote no.
To deny this to yourself, to remain subject to the whims of a distant and uncaring elite, to succumb to the bleak, deferential negativity of the no campaign, to accept other people’s myths in place of your own story: that would be an astonishing act of self-repudiation and self-harm. Consider yourselves independent and work backwards from there; then ask why you would sacrifice that freedom.Scots voting no to independence would be an astonishing act of self-harm
A yes vote in Scotland would unleash the most dangerous thing of all - hope
(Monbiot is also the author of Heat, my favorite book on climate change.)