I think it is highly unlikely that Haskell will be suitable for Windows development anytime in the near future. (By that I mean development that requires heavy use of the Windows-specific APIs). The Haskell way of thinking is so different from the way the Windows API way of thinking that it will always be an awkward boundary to cross.

So far, Haskell as been able to work its magic best in areas where it is not required to confirm to some pre-existing (usually OO) way of thinking.

So, for example, web devel has been a great place for Haskell innovation because you just need to receive and send Requests and Responses. There is nothing about http, etc, that is inherently object oriented.

For similar reasons, Haskell has been popular in finance and trading platforms where they just need to parse data and generate data.

It's unfortunate that getting SDL working on Windows is difficult -- because SDL is actually something that generally jives pretty well with Haskell. It is also somewhat ironic that Windows is often viewed as second class when it comes to Haskell support -- because the main GHC developers use Windows.

As for monads.. I think a lot of people have difficulty with them, in part, because they are actually really simple. And so people keep thinking they must be missing something.

A monad is really just some type (like, IO, Maybe, a list, whatever), and a function that glues a bunch of functions that manipulate that type together.

So, for example, IO is type that can do I/O type things (like, read a file, print a string, etc), and you use >>= to do a bunch of those things in a row. Using >>= all the time as annoying, so we use the 'do' syntax to make it easier to read.

Knowing more than that about monads can be fun, but is largely not needed for actually using them. I've know people who used Haskell for years, have written hundreds of thousands of lines of useful Haskell code.. and still couldn't really explain what a Monad is. We learn how to add and multiple numbers in grade school with out ever learning about Monoids, Rings, etc. If people taught grade-school math the way we teach intro to Monads, pretty much everyone would fail math :p

In the pre-Hackage days, I found SDL to be one of the easiest FFI bindings to install on Windows. As the SDL project supplied a DLL you could just build the binding with Cygwin, you didn't have to build the original C library with MingW / MSYS. I don't know what the situation is like nowadays.

Knowing how to use a given monad is pretty simple (well... except lists, just because you can go kinda crazy with List as Monad). Understanding why a given type forms a monad can be pretty confusing. Unfortunately, the latter is how you get the most power out of monads because you can then start thinking generally about the way you can program using only the monad interface and how various types will interact through your monad generic code.

Thanks for posting about your experience. I am one of the Leksah devs and we are always interested to get feedback that helps us make Leksah better.

There is one, Leksah which I tried, but the auto-completion and syntax highlighting didn’t work like I wanted it to work. And by that I mean it would work pretty much exactly like ReSharper.

This is good, but could you elaborate on which behaviour do you miss most from ReSharper when using Leksah? Explain it to me as if I did not have access to ReSharper (otherwise I am likely misinterpret to which bits you want and waste days making the icons look the same or something).

We have not added hlint support in Leksah yet, but it sounds like you might find hlint useful (you can "cabal install hlint" then just run hlint on your source files and it will make suggestions).

Also it would be great if you could try EclipseFP and let us know if there is any ideas you think we should borrow from there.

I think your editor is on a good way which is a very good thing. While daunting a concept for you guys, you probably are one of the very FIRST contacts with Haskell for any new coder from the windows side of things.

It's a different mindset, that of a windows developer. A windows developer will usually look for an IDE that will get things done. A one-click install. No command prompts. That being said, I'm not a typical windows guys, I have loads of (professional as well) experience using Linux, and I like Linux - but I remain firmly attached to Windows.

Anyway, I thought long and hard about why I went back to a glorified text editor instead of using Leksah. Here's what I came up with:

I couldn't find a way to rebind the build and run keys to use different combinations. Went through the menus, googled and whatnot. I am hard-wired to build on Ctr+B and run on F5. Sorry about that

When pressing Ctrl+space it would not suggest things from my own source file from my own list of functions, or that was my perception of it. In all honesty, I prefer that the dropdown window is always present when I type. But that might be just me. I can't check the behaviour right now, I don't have the editor with me at work.

The constantly scrolling window of compiler output was annoying, but I didn't dare close it, since I couldn't hover the (very nice) red underlined errors in my source code to see what the relevant problems were. This actually is an important point, you have a means of providing the error in context that the command line cannot do. Fully use this option and hide the compiler output as a default

I felt cheated out of the very cool looking dark theme that the website shows. I wanted that too, and couldn't find a way to get it instead of the plain boring white. Like knowing there is a sleek cool racecar to drive, but yours look like a volvo even though the capabilities are the same.

When making a new project, it assumed too much of a rookie. It wanted to create a workspace, and a proper cabal structured module and even some tests. I wanted none of that and it made it harder for me to get started. I ended up deleting everything that wasn't my lone source file in order to keep things I wanted to keep track of to a minimum. I'm sure that the structure is great, but it's intimidating to someone unfamiliar with Haskell.

I also had an issue with my program, being badly written and all, was trapped in some near infinite loop and wouldn't close. Maybe it was outputting shitloads of text to the console as well. Either way, I had to close the entire editor to get it to stop. That got old after a few times. It needs a way to easily kill the spawned process if you've trapped it somehow.

Thing is, that in my opinion, you should target your editor at new users of Haskell. The old foxes they already know their way around things and are probably already using a tool they are comfortable with.

When you come into Haskell as a rookie, you get the impression that there is this shadowy incomprehensible thing looming just out of sight called monads. This also makes it incredibly attractive to learn, since it's apparently so hard. I think I read this text, or skimmed it, then went back to mucking about trying things until they worked.

I'm really out to do stuff, and to take lessons home with me that will make me better at programming in general - regardless of language. If monads will help me do that, I'll learn them.

It's pretty silly, really. Monads have (perhaps undeservedly) developed a reputation as confusing and difficult to learn. They really aren't. The main problem people seem to have is that monads can't be explained by any real-world analogy the way objects can.

The simplest explanation I can give for monads is that they take a basic data type and wrap it in a computation. This results in a new type that carries around a computation (or action, if you like) along with it.

Monads are just a design pattern that let's you combine various code fragments seamlessly. Any time you have code you want to join together, you probably have a monad. Unlike other design patterns in other languages, which are typically ad_hoc or just fads, there is a mathematical reason for why monads are the "best" way to compose code.

Juicy.Pixels author here, what exactly didn't you understand in the library? I'm planning some helper functions for image writing, because they're missing for a simple use, any user input is welcomed :)

I did not understand where to look to see samples. I wanted to see how to use it to simply write an image file without doing anything difficult at all.

This should be in your readme file on github before any other text in my opinion. This is where I always look, and if there is no example there to start me off, I usually wander off somewhere else. :) Might be that githubs readme file isn't the place to look, but I know of no better place.

A good thing would be the situation where I have a [[Int]] of pixel values which are bitshifted colours RRGGBBAA and I want to save this to a file named "whatever.png". Your library looks really cool, but it talks about things I don't yet understand like MUArray or UArray. I have no clue what those are to be honest given my very limited experience, I just wanted to write a png.

What will happen when calling this function is that I will have to run across every single pixel of the image, thus breaking the (possible) laziness of the generation so for each pixel, an allocation will happen (=> huge in memory). If you used foldl somewhere to generate this list, I will somehow force a pile of thunk (a thunk is a promise something to be evaluated later), and if the image is large, blow up memory and maybe perform a stack overflow.

I also need to add functions to transform an int to a pixel, it's obvious now that you're pointing it.

I figured as much, that the lazyness would explode on you. I probably need to read up on it, I think some performance problems I've been having is due to this. I really like your short sample, it seems like this would do pretty much exactly what I want to do in a simple raytracer. Thanks!

And regarding the samples and github, If you don't store the docs on github at least add a link to the place where the documentation is found. That would have helped me out, coming from a non-haskellian environment I have no idea that Hackage is the place to look.

I hope this can give something back to the Haskell community, to give a glimpse into how a Haskell rookie perceives the ecosystem - which in my opinion is as big a factor in the success of a language as the language itself, if not more so.

I think this kind of reviews are very useful, and yours really stands out since, for once, is not charged with programming ideology/prejudice :P.

I can understand your pain with Haskell's tooling, since you come from Visual Studio world. The problem more than the lack of tools in general for Haskell, is more about the lack of tools familiar to Windows/IDE programmers. I came from a Linux/Emacs background and everything went pretty smooth, since I'm used to that kind of flow (fiddle with the command line, read man pages/manuals, repeat). Haskell could certainly do with better tools aimed to programmers with a background like yours. Also, cabal is still a bit problematic, regardless of the platform. You didn't have time to run into the dependency problems, but I can assure you they are annoying.

Don't give up, the real pleasure comes with the understanding of the more advanced concepts. imo the best resource is Haskell's IRC channel: http://www.haskell.org/haskellwiki/IRC_channel . I'm there as "bitonic" and there are loads of really knowledgeable people willing to help..

Thank you! It would be silly of me to keep any kind of prejudice or ideology when "reviewing" a programming experience. Haskell is probably an easy target, since the syntax is so very compact. I imagine it's like perl which to so many people is write only code.

Oh, I don't intend to give up quite yet. I still want do so something even more real to fully grasp a bit more of the language. I really do believe that it will make me a better coder, regardless of language.

I did go on to the IRC, and it is very helpful indeed. It's a good resource, and a friendly face to the community.

In fact so attracted that tried and failed it. Whoever put it under best places to start has a very different view of the world than mine. I still want to do it, it sounds awesome, but it is definitely not a beginners text.

The typical recommended Haskell learning path is LYAH then RWH, with whatever additional tutorials you are interested in sprinkled around. Both are freely available online. Theoretically Mezzo Haskell will be the next recommended book, but it's far from complete as of now.

I contemplated that, but since F# is much less of a pure language it would have allowed me to cheat instead of actually learning the paradigm. And Haskell seemed "cooler" for lack of a better description

Well, all things considered, ML is probably the closest thing there is to Haskell besides Haskell (not counting Miranda, which Haskell basically copied, and Haskell-grown languages like Agda and Idris)

If [a Visual Studio language extension] would exist it would have shortened my learning time considerably, taking away much frustration and wasted time.

Ouch! If you think that then you really gotta start learning to use a lightweight customizable editor like Vim/Emacs. I mean it, no trolling intended.

I was so happy each time I came back home and could leave the Visual Studio I was using at work to hack Haskell with Vim at home. With the proper plugins you can have the same productivity with a much lighter editor (not to mention the basic edition commands & shortcuts, but I will not dwell on that or else I feel someone will accuse me of proselytism ;-) ).

I am new to Haskell myself, but I would say that the best place to start with Haskell is not actually with the language itself. I think you have to start with SICP: http://mitpress.mit.edu/sicp/ and try to learn functional programming as a paradigm separately from an implementation.

I also don't really understand how an IDE can help a beginner learn a language. I have always used Vi, but my short experience using Visual Studio when I was forced to work in a Windows environment was excruciating. I found that IDEs let you write a lot of code really fast without know what the hell is going on. They are good for languages like Java where you have a ton of boilerplate but for most languages they really take you away from actually writing code.