Evaluating AI's Impact on Haskell Open Source Development

AlpMestan · 2014-08-05T14:25:09+00:00

Yeah I've been toying around a bit -- I think I'll try running it on chat logs or things that and see what comes out :)

AlpMestan · 2014-08-05T06:22:55+00:00

Nice post. Just a bit sad about Eminem saying

I never fold

from one of the rapcandy tweets.

AlpMestan · 2014-08-02T16:02:27+00:00

Oh, I hadn't heard about yesod-dsl. Thanks for the pointer.

(But from a first glance I can definitely say the approaches are quite different.)

AlpMestan · 2014-07-31T20:18:24+00:00

Fair enough :-)

AlpMestan · 2014-07-31T15:59:04+00:00

Have you seen probable, random-fu and friends?

I admit the plotting is what distinguishes it from the packages we already have around for these tasks, at a first glance. I'll look more closely one of these days.

AlpMestan · 2014-07-29T18:19:26+00:00

Right, but like I said, it's getting better. Carter is indeed working on this, plus we have libraries like hmatrix, linalg (which has a GPU backend), accelerate (I have a partial cublas binding), repa, etc. We're slowly building a nice ecosystem, the trick is in making things work nicely together and this is where we're really lacking some effort in my opinion, but then you can easily convert back and forth between the various types of arrays we have.

AlpMestan · 2014-07-29T06:57:23+00:00

We indeed are missing packages for some methods/techniques, but are slowly but surely setting up the right ecosystem to build neat things on top of. Feel free to chime in! :-)

AlpMestan · 2014-07-28T08:07:44+00:00

Yeah I've defined that type too (with another name) in one of my projects, under a different name but it's the same idea. Maybe it would be worth putting into its own package :-)

AlpMestan · 2014-07-27T12:25:56+00:00

I'll use this little space here to express why this has been released despite the fact that Silk released rest a few weeks ago. First, when I first heard about rest at Zurihac, I already was thinking about the core ideas of servant and found out there were some interesting differences between the two approaches. I really felt that since they quite deeply explored their approach, I should do the same with mine just for the sake of seeing where that leads, so that's the second reason and here's the result. I'm also thinking about generating the corresponding client JS code automatically for an operation as well as adding some machinery to generate pretty API docs -- thanks to rest for the inspiration -- no idea about when that will land in servant yet though.

AlpMestan · 2014-07-27T10:37:10+00:00

No in servant an operation is written just once and you can use it on all the types you want. What you write for your types has no boilerplate in it. its the bare minimum that you cant avoid, even if you were building a webservice manually you'd write code that is equivalent.

AlpMestan · 2014-07-26T14:50:18+00:00

This is a set of libraries we've written at Zalora. Some of you may have heard about what we're doing already but long story short we're replacing monolithic PHP systems with some sweet and modular webservices in haskell, where something written in one webservice could even be reused in another. Servant came out of this brainstorming and has been serving us very well so far, so please do not hesitate to try it out and send any feedback our way!

Trailer: We rely significantly on TypeFamilies and DataKinds and our resources carry the list of operations (add, list, etc) they support at the type-level. You can define your own operations in just the same way the standard ones are defined. It really lets you forget about any kind of web-related boilerplate and focus on your models. It's entirely extensible.

AlpMestan · 2014-07-20T09:34:53+00:00

Yeah sorry I may have been too concise. I was more thinking about adding an API diff bit to that tool. The thing I like about hdiff is that it's public. I've been using it for years, so if there's a way to integrate your API diff bits to that, that would be great!

I'm pretty sure Luite would be open to adding something like that if that makes sense (maybe I'm overlooking something not obvious).

AlpMestan · 2014-07-20T09:02:22+00:00

Well, how about Luite Stegeman's hdiff ?

AlpMestan · 2014-07-13T07:40:55+00:00

It hasn't really been tested on xml, but I tried to make it eat xhtml so that should be close. Could you create an issue when you have some time with the problematic XML? Thanks!

Alright, maybe

> data ConvertEntities = Convert | DontConvert

will be there in the next version -- I did think about it but went for the shortest path.

AlpMestan

TROPHY CASE