サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
www.snoyman.com
Haskell base proposal: unifying vector-like types Published March 16, 2021 DISCUSSION I've opened up a Discourse thread to discuss this post. I'll likely respond to comments here and on Twitter, but I'd like to move towards using the more official discussion channels when possible. One of my greatest hopes for the Haskell Foundation is already beginning to be realized: better communication. I'm a
Haskell: The Bad Parts, part 2 Published November 9, 2020 If you didn't see it, please check out part 1 of this series to understand the purpose of this. Now, for more bad parts! Partial functions (in general) Laziness very likely belongs in this list. My favorite part of criticizing laziness is how quickly people jump to defend it based on edge cases. So let's be a bit more nuanced before I later
Haskell: The Bad Parts, part 1 Published October 28, 2020 There's a popular book called JavaScript: The Good Parts. And there's a common meme around the relative size of that book versus JavaScript: The Definitive Guide. Haskell is, in my opinion, a far more well designed and coherent language than JavaScript. However, it's also an old language with some historical baggage. In many ways, it's a bl
Introducing the Rust crash course Published October 18, 2018 I'm announcing an upcoming series of blog posts, which I'm calling the Rust crash course. In this blog post, I want to explain: Why I'm interested in Rust Why I'm writing up this series Who this series is for My intended flavor for the series Some examples of Rust gotchas I want to cover I'm getting to work on this series due to increase
RAII is better than the bracket pattern Published October 8, 2018 I recently wrote an FP Complete blog post entitled ResourceT: A necessary evil. I had a line in that post I wanted to expand upon: I believe this is an area where the RAII (Resource Acquisition Is Initialization) approach in both C++ and Rust leads to a nicer solution than even our bracket pattern in Haskell, by (mostly) avoiding th
Many people in the community have seen the SLURP proposal. Some people have asked my opinion. Some others have made some... let's say colorful statements about my noninvolvement in the discussion. Let me set the record straight right now on why I've avoided the topic. The authors showed me the proposal before it was published, and I told them at that time I would not support it. I've also told the
What Makes Haskell Unique Published December 17, 2017 I gave a talk today at the F(by) 2017 conference in Minsk, Belarus. The conference was great, I would definitely recommend it in the future. Thank you very much to the organizers for the opportunity to present on Haskell. I prepared for this talk differently than I've prepared for other talks in the past. I'm very comfortable writing up blog po
Better Exception Messages Published February 16, 2017 Better exception messages Let's write a really silly, highly inefficient (my favorite kind!) program that connects to multiple HTTP servers and sends a very simple request. Using the network package, this is really straightforward: #!/usr/bin/env stack -- stack --install-ghc --resolver lts-8.0 runghc --package network -- -Wall -Werror import Co
This is a short follow-up to my blog post about mapM_ and Maybe. Roman Cheplyaka started a discussion on that post, and ultimately we came up with the following implementation of mapM_ which works for all Foldables and avoids the non-tail-recursive case for Maybe as desired: mapM_ :: (Applicative m, Foldable f) => (a -> m ()) -> f a -> m () mapM_ f a = go (toList a) where go [] = pure () go [x] =
Functors, Applicatives, and Monads Published January 3, 2017 This content originally appeared on School of Haskell. Thanks for Julie Moronuki for encouraging me to update/republish, and for all of the edits/improvements. NOTE Code snippets below can be run using the Stack build tool, by saving to a file Main.hs and running with stack Main.hs. More information is available in the How to Script with
There was an image that made the rounds a while ago. The joke being: haha, Haskell is only for super-geniuses like Einstein. There's lots to complain about in this chart, but I'm going to pick on the lower-right corner. Specifically: Haskellers don't use Haskell because we think we're Einstein. We use Haskell because we know we aren't. When I speak to Haskellers, the general consensus is: "I'm not
Haskell's Missing Concurrency Basics Published November 16, 2016 I want to discuss two limitations in standard Haskell libraries around concurrency, and discuss methods of improving the status quo. Overall, Haskell's concurrency story is - in my opinion - the best in class versus any other language I'm aware of, at least for the single-machine use case. The following are two issues that I run into
There's no point being coy or saying anything but what I actually believe, and saying it bluntly. So here it is: The haskell.org committee has consistently engaged in tactics which silence the voices of all non-members, and stacks the committee to prevent dissenting opinions from joining. I've said various parts of this previously. You may have heard me say things like the haskell.org oligarchy, r
このページを最初にブックマークしてみませんか?
『www.snoyman.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く