LukeHoersten

I've found the exact opposite to be true. With Postgresql, for example, strong types can be enforced through the entire application stack using tools like Opaleye. Check out composite types in Postgres and Opaleye to see what I'm talking about.

I know John W from the Chicago Haskell group. He's great. Nothing more to say really. Perfect choice for the role.

I switched to Lyft after having a verbally abusive driver. Uber support kept giving me canned responses. Finally I got a human over email and asked if I and my wife could be blocked from the driver. They said no, just cancel the ride if I see him again. I don't know what my wife is supposed to do. Lyft has a noticeably higher quality driver base. I highly recommend Lyft.

Pusher is doing some awesome stuff with Haskell! They run a lot of the bitcoin exchange web socket APIs on their infrastructure. I'm sure they have other users too. Cool stuff.

Definitely a generalization but I think that's how it's viewed by many from 30k ft. I should have made it clearer that I was making an observation about a perception not my own views.

Bitcoin is a solution. Ethereum is an experiment. Both noble pursuits.

Agreed. http://www.chicagotribune.com

Thanks for htop!

It's unfortunate how many CS graduates I talk to who haven't heard about this pretty simple concept. It's the kind of thing you get once you hear it and it's important to be aware of. Fortunately, many CS graduate do learn this as well.

Great questions! I think you're right this is a tooling issue. Haskell has valgrind-like heap/memory analysis built right in but not much for thunk-based memory allocation. Neil's article is really about Haskell's thunk analysis specifically and I imagine we will see some valgrind-for-thunk tools come out of this discussion.

Completely agree. Laziness has too many benefits not to justify the added complexity of thunks and thunk-based space leaks. If you don't agree, don't use Haskell =)

As someone who's programmed extensively in Haskell, Java, and C++, I would say each of these languages have their own problems regarding memory. Write a decent sized Java application and you will have a ton of memory usage and perhaps space leaks as well. In a moderately complex C++ application, even the best C++ devs will have memory and space leaks.

I think the key here is that Java has JProfiler. C++ and C have Valgrind. Haskell has a heap profiler built right into the compiler. But Haskell doesn't have any specific tools for thunk memory profiling. The discussion in the community is now around building tools and automating this process. It's not like this is a fundamental issue.

Languages that have complex threading and locking also have to have more complex tools to debug these issues (ThreadScope in Haskell, VTune in C++).

What I'm trying to do is put these issues into context. It would be easy for a Python dev with the GIL to scoff at the complexities associated with C++ or Java threading and this is akin to what many do when looking at laziness. Laziness is a feature that comes with it's own types of bugs and we simply need tools to manage and track down those bugs.

The breakthrough with Neil's post is that even with current tools we now have a way to track thunk-based space leaks in Haskell and ideas for some more automation on the way.

I wonder if these features will be available for Google Inbox on iOS.

Impressive work and explanation regardless of the language being used but the code does look particularly simple and elegant.

This is such a cool project as a whole. The domain, the simplicity of the project (curl wrapper), the fact that the homepage is basically a man page, the simple auth. It's just an awesome concept and really well done.

Usually it feels like companies open source projects are kind of lame or just to look fashionable. These projects are extensive and awesome. I love the personal projects section at the bottom of the page. You can see why Stripe is so successful. They truly have a dev culture and that's a lot more than most companies that just say they have a dev culture. At Stripes scale and size that's a big success.

There are many routers out there that fit the bill of what you're looking for. I think Google's aim here is for the generic consumer that has wifi signal problems but doesn't want to fiddle with it. This seems more a competitor to Apple products than tri-band, WRT-ready routers. You're right though, it doesn't (can't?) compete in that space.

Thanks for combining these images. The red square was really clever for peripheral vision identification of the image.

I agree with a lot of what you said here. Weirdly, they went sans-serif with the 'i' and serif with the comma. I'm personally a fan of commas, semicolons, and quotations having the same visual flavor and the Hack changes went farther from that.

Totally agree. You don't have to build a whole new tool just to try out this new method of editing code. I use both ParEdit and SHM from time to time and they work really well but it's a departure form muscle memory to say the least.

Emacs has structured-Haskell-mode designed after paredit mode as well. (shm they call it)

When I read about topics in which I have first hand experience, I feel The Economist does an excellent job of portraying the facts and different perspectives. This almost never happens in any mainstream media, especially regarding technology and trading. Therefore, I trust The Economist on topics in which I don't have first hand experience. They rarely let me down. I hope this continues and it seems they believe it will only improve.

This is awesome. I've never heard of PLEAC before but it's exactly what I want to see when starting a new language. Idioms and best practices are much easier to grasp when factoring out superficial differences.

I actually like the symbolic function names. They're a pattern and method to them that once you learn it, it's super convenient. Perhaps it just needs more obvious documentation.

Totally agree on the runtime exception issue. I feel like even Java with it's typed exceptions are better. With a Haskell function I have no idea what exceptions it will through and worse, if it's in IO, I have no idea what async exceptions it could throw.

I've been using hg-git for years for almost all my git contributions. Works well.

Some really exciting updates in here. It seems that while Git is popular for open source projects (thanks to GitHub), Mercurial is popular for internal repos and companies. That's personally how I use it.

I've been going a step further than this. Not only revision controlling my dotfiles but also using Ansible to automate the process of installing all the apps I want, getting the environment in order, etc. Emacs and Mercurial have both changed my programming life and I think Ansible is a new addition to that group.

I've been using Ubuntu Mono for years and absolutely love it. Consolas and Roboto look nice as well though.

My buddy works at YouTube on the player and I asked him this same question. Basically he said there's resistance to changing too much on the interface in order to not mess with success. The good news is, they know the issue(s).

You're right I think ide-backend provides almost all of this. It was all working in FPComplete's web IDE. I think Chris Done is working on emacs integration with ide-backend.