I don’t want to publicly shame anyone so I won’t link to screenshots of the specific thread I’m talking about, but I saw a heated haskell-related argument on twitter this afternoon that I feel casts a negative light on the haskell community.
The overwhelming majority of haskell enthusiasts and professionals on /r/haskell, the #haskell freenode channel, and twitter are extremely helpful, well-mannered, and kind. Unfortunately I’ve seen two kinds of posts crop up more frequently (particularly on twitter):
1) Posts that put people down who have criticisms about haskell
2) Posts that promote haskell in a way that is condescending and arrogant
It’s great that we have so many passionate people in this community, but posting snarky 140 character snippets on twitter about how our language is better than yours or to claim that “anyone who doesn’t value <purity|static typing|other FP feature> doesn’t care about code quality and correctness” is obnoxious and hurts the cause. There is no One True Waytm to write code, Haskell doesn’t need to be aggressively sold to other programmers, and we don’t need to flame people who disagree with us about its merits and utility.
I might be preaching to the choir here, and if /r/haskell is not the appropriate venue for such a discussion I apologize. I have admired this community for a long time and want it to continue to be seen as a group of respectful and open-minded individuals.submitted by haskell_throwaway
[link] [39 comments]
On September 28 we released 3.1 of the FP Complete public services. We've discussed this a bit already, but in this blog post, we want to share some of the more technical details of what we've added.Laundry list of features
We've added a whole bunch of new features to FP Haskell Center. Here are some of the most notable:
- You can now access all features of the IDE for free
- It's faster
- More file type support: Literate Haskell, hs-boot, and C files
- Git Shell allows you to run arbitrary Git commands on a fully interactive command line
- In addition to GHCi runs of code, you can build and run binaries inside the IDE
- Ability to pass arbitrary flags to deployment builds
- View usages of an identifier
- Better support for Template Haskell-included files (like Hamlet)
- Modified data files immediately appear to your application (good for modifying a CSS file in a web app, for example)
- Better session management, including logging out of all sessions
- School of Haskell supports autorun and Disqus comments
Keep reading for a drill down of some of this list. And for some lower-level, GHC-facing bits of our work, jump ahead to the "faster" sections.Open Publish model
As announced previously, we've decided to make FP Haskell Center even more open. Since our 3.1 release, all IDE features are turned on for all users, with and without a paid account.
The new FPHC terms & conditions no longer restrict the free community version to non commercial use. Even anonymous users can access the full spread of features in the IDE, from type checking to executable generation, and even Git repositories (though you'll definitely want to log in to be able to use that properly).
There are two distinctions between our community and paid licenses now:
Commercial licenses provide more compute power.
Under community licenses, all commits made in the IDE will be published. Similar to the GitHub model, free projects are open projects. You'll need a commercial license for private projects, which can still be acquired by contacting FP Complete Sales. So now when you commit, you'll see this message:
Committed changes are public
Any new commits are now made public and will make your project public. Existing private projects will not be published until you make a new commit.
NOTE: If you have an existing project with commits, it will remain private until your next commit.
Additionaly, there are now no restrictions on how you license your published code. This means that although you give others the right to view your published code, they receive no implicit license to distribute your code or use it in derived works. You can still explicitly license your code under an open source license if you choose.Autorun active code samples
Based on feedback (mainly from Edward Kmett), there's a new directive in the code fence syntax in School of Haskell posts, which will auto-run the code snippet when the page loads. This will be especially nice for showing graphical web pages or to begin an interactive process. The code is written as:``` haskell active autorun main = print "Hello, World!" ```
And that will result in something like this.School of Haskell improvements
The School of Haskell now supports adding Disqus comments to your own tutorials (yet again suggested by Ed). It looks like this.
To enable this, go into your account settings under “Profile” and you can choose:
☑ Use site default (currently: no comments)
☐ Disable comments
☐ Use FP Complete's Disqus account
☐ Use your own Disqus account
Disqus account ID: [ ]
To use your own Disqus account, hit the “Use your own Disqus account” checkbox and put your account id in the box. Then go into your Disqus site settings under the “Advanced” tab and add fpcomplete.com under the “Trusted Domains” text box.GHC 7.8, new libraries
We've updated our default compiler version to GHC 7.8. We still provide a 7.4 environment, but it is considered deprecated, and we recommend users upgrade to 7.8. In addition, as usual, we've updated our library set to the newest versions of upstream packages, and will begin releasing unstable package snapshots next month.Defer type errors
Together with GHC 7.8 come some new compiler features. For the most part, these are simply available to you without any IDE support. We added one nifty feature though: You can now defer type errors using the checkbox in the Messages tab:
☑ Enable suggestions ☑ Enable warnings ☑ Defer type errors
This will change type errors into warnings which are instead thrown at runtime. A very useful way to keep getting type information when you have a simple type error elsewhere in the code.
This plays in very nicely with the new Type Holes feature. Now you can program Python in Haskell!Improved root & filtering
In the “Root & Filtering” tab in Settings, there is a way to change the root directory of your project, this is similar to doing a cd in your terminal. This is useful if you have several projects in one repository and you want to just compile the modules within one directory, rather than everything in the whole repository.
You can also ignore certain files using the blacklist input, e.g. src/Main.hs will hide that file from the list. This can be useful for hiding things from compilation.
This feature is still considered experimental.Faster
You should notice a definite improvement in responsive in the IDE. We've actually implemented many different changes to make this happen. Our network communication layer, for example, has less overhead involved, by removing some unnecessary parsing from our reverse proxy machines. We've also refactored quite a bit of our async architecture to provide better concurrency for backend actions.
However, the biggest change comes to how we interact with GHC. We use GHC for a few different things in the IDE:
- Type checking code
- Provide information on identifier locations, types, usages, etc
- Generating and running bytecode
Those first two bullets dovetail together rather nicely, though the second can take more time than the first. However, the third point doesn't play so nicely with the other two. The issue is that, while GHC is running the bytecode, it can't continue to compile new code. And this is definitely something we want to allow. For example, a common use case it running a web application in the IDE, while continuing to hack on it while it's running in the background.
Before the 3.1 release, our solution was to have three copies of GHC running for each project: one to do a quick typecheck, one to extract type information, and one for running code. This meant you would get error messages quickly, but couldn't always get type information right away. It also meant your project required much more memory, which overall slowed things down.
Our new architecture involves just a single GHC process running for each project. We load code into this process, and it typechecks, extracts information, and generates bytecode, all at the same time. The trick is what happens when you press run? We would like to use the bytecode already available in the current GHC process, without tying that process up on just running the bytecode.
The solution we ended up at is calling forkProcess. However, it wasn't quite as simple as that. To quote forkProcess's documentation:
forkProcess comes with a giant warning: since any other running threads are not copied into the child process, it's easy to go wrong: e.g. by accessing some shared resource that was held by another thread in the parent.
Sure enough, we ran into exactly this bug almost immediately. And fortunately, we have some very good news to report: it's fixed! You can see more information in GHC trac tickets 9295 and 9296 (and check Phabricator for some great reaction gifs). These changes have been merged upstream into GHC. Since writing those patches, we've stress tested our IDE significantly, and have no longer been able to reproduce any forkProcess bugs, which looks incredibly encouraging.
Note, though, that there are still some issues around forkProcess. If you're planning on using it in your own code, you should be aware that you can still run into problems, especially with multithreaded code.
One other change we made was switching to a dynamically linked GHC process. We'd wanted to do this for a while due to improved memory usage. Ultimately, we had to make the switch due to a bug in C static initializers. Now we get the nice benefit that separate processes on the same machine can share memory space for their dynamic libraries.
Post by Joe Armstrong of Erlang fame. Leader:
Why do we need modules at all? This is a brain-dump-stream-of-consciousness-thing. I've been thinking about this for a while. I'm proposing a slightly different way of programming here. The basic idea is:
- do away with modules
- all functions have unique distinct names
- all functions have (lots of) meta data
- all functions go into a global (searchable) Key-value database
- we need letrec
- contribution to open source can be as simple as contributing a single function
- there are no "open source projects" - only "the open source Key-Value database of all functions"
- Content is peer reviewed
Why does Erlang have modules? There's a good an bad side to modules. Good: Provides a unit of compilation, a unit of code distribution. unit of code replacement. Bad: It's very difficult to decide which module to put an individual function in. Break encapsulation (see later).
First, sorry if this is an inappropriate post for this sub. I wasn't sure from looking at the guidelines... hopefully any answers I get to this question will be useful to other Haskellers like me; I feel like there are a lot of us out there.
Recently, I've been on the hunt for a new job. I am not specifically looking for a Haskell dev position, but I list Haskell on my resume anyway. I have no professional experience with it, but I have put a fair amount of my own time into learning it and I think it's made me a better software developer overall. I like to show that I take interest in the craft outside of my 9-5 job.
My question is, how should I represent my Haskell ability? I'm quite comfortable with the following things:
- Pure/impure code, immutable data structures and referential transparency.
- Lazy evaluation and infinite lists.
- Higher-order functions, lambdas, currying, function composition, point-free style.
- The basics of the type system: data, newtype, and type declarations. Algebraic data types and pattern matching. Type signatures and type variables. Typeclass definitions and implementations. At this point I am usually able to correctly write the type signature for fairly complex functions without loading my code into ghci and cheating. :)
- Basic data structures and their strict/lazy versions: Lists, Vectors, Maps (tree- and hash-based variants), Sets. Have implemented relatively advanced data structures myself (binomial heaps and octrees to name a few).
- Maps, folds, unfolds, list partitioning (head, tail, takeWhile, dropWhile, and so on).
- Use of recursion (where the above functions aren't applicable) and dynamic programming techniques.
- Functors and the basics of the Applicative style.
- Basic monads: IO, Maybe, Either, State, ST, List, etc.
- Do-notation and monadic maps and folds.
- Basic creation and use of monad transformer stacks.
- Creation of monadic DSLs (magical!)
- Numeric types and bit manipulation.
- Designing small to medium-scale projects.
Here's what I'm not comfortable with and/or have no experience with:
- Implementing my own monad transformers and having them integrate nicely with mtl and others.
- Parallel/concurrent programming and synchronization constructs (in Haskell).
- Lenses and Arrows: I have no idea what these things are!
- Code profiling and management of strict memory constraints with lazy evaluation.
- Efficient implementation of immutable data structures. I don't know what's involved here, but I suspect that I am still doing things "the dumb way".
- Advanced type system stuff, like "kinds" and the use of language extensions (I usually keep trying to compile and add all the extensions it suggests until my code works...)
- I still sometimes get confused when I run across really bizarre types.
- Analysis of the intermediate code generated by the ghc stack during compilation.
- Real large-scale design.
- Doubtless many rarefied concepts I'm not even aware of.
So, you get the idea. The coolest thing I have made in Haskell is probably a PL/0 interpreter (using simple AST traversal), which included a monadic parsing DSL that I implemented from scratch based on my experience with parsec in "write yourself a scheme", but this was a fairly trivial project that only took me a few days' worth of free time. I've also done a few other things in that vein and a copious amount of Euler problems.
So, my question is, where am I on the Haskell developer totem pole? On my resume I claim to be "proficient" in it, by which I mean that I have some idea of how to build a reasonably complex thing without making too many stupid errors or dumb design decisions along the way.
Basically, I want to know if "proficient" is an overstatement. :)submitted by the_great_ganonderp
[link] [7 comments]
So, every year, as many know, we run a very successful google summer of code, where we get lots of students to build lots of awesome infrastructure. Students are supposed to propose what they want to do, and then we accept it. However, we need to help steer students to good proposals.
Historically, we've had a number of ways of organizing such proposal suggestions.
The longest running has been our GSoC trac (https://ghc.haskell.org/trac/summer-of-code/). As one can see, it tends to fill up with old proposals and spam, and so doesn't work great as a resource. It also needs a fair amount of attention and "gardening" anyway.
Another effort was /r/haskell_proposals. But it turns out the reddit format is sort of miserable for a number of reasons, including that old things get archived and unvotable/replyable, there's no good way to organize them, and things sort of die. Also, lots of proposals are not well-vetted, and so they range between the useful and the weird.
So in recent years, folks have started writing good comprehensive blog posts, which have in turn led to good projects. Johan Tibell's have been exemplary in this regard: http://blog.johantibell.com/2013/04/haskellorg-gsoc-ideas.html and http://blog.johantibell.com/2014/03/google-summer-of-code-projects.html for example.
So I want to throw open the issue for discussion -- what is the right way to organize high-quality suggested GSoC proposals? And, since I suspect that any good way will also require gardening, maintenance, and even active solicitation of good ideas, who is interested in helping to step up and organized this portion of the process?submitted by gbaz1
[link] [3 comments]
The data science domain has been traditionally dominated by Fortran, and more recently Python and R. Lately a new language called Julia has developed a buzz in that community, particularly among Python programmers. Julia was developed academically as a multi-paradigm language focusing on high performance. Since Haskell has a similar "origin story" 20 years ago (except obviously not multi-paradigm) and designed by mathematicians, why isn't Haskell a significant contender in the data science space, and why didn't it fill the niche that Julia is attempting to fill? The Python community could just as "easily" embrace Haskell as embrace Julia.submitted by RaymondWies
[link] [103 comments]
My future employer (I will be the only developer there) is considering whether or not to allow me to use Haskell at work. One certain condition is that I need to be able to give them the resumes of at least 5 other Haskell programmers, ideally ones in the Atlanta area or in the United States. They want this so that if I died, someone could take over. If anyone would be willing to send me their resume, you can send it to email@example.com. I would appreciate it a lot, and if we need more Haskell devs in the future, we would go to your resume first. Thanks.submitted by andrewthad
[link] [66 comments]