Popularizing Haskell through easy web deployment(blog.begriffs.com)
blog.begriffs.com
Popularizing Haskell through easy web deployment
http://blog.begriffs.com/2013/12/popularizing-haskell-through-easy-web.html
7 comments
I don't get the appeal of an IDE in Haskell development. You can download the Haskell platform on haskell.org. In the case of Windows or OS X, it takes a few mouse clicks, and on Linux you launch a package manager to install it.
There may be some benefits of using whatever FP Complete offers, but if anyone is struggling with getting Haskell set up on his computer with the official releases, then that person might need to acquire some other skills first before delving into the world of pure functional programming.
There may be some benefits of using whatever FP Complete offers, but if anyone is struggling with getting Haskell set up on his computer with the official releases, then that person might need to acquire some other skills first before delving into the world of pure functional programming.
Your post implies that the main reason people would use an IDE is because they are having trouble getting non-IDE tools for the language setup.
Of all the benefits I've heard ever used to sell IDEs, that's got to be the least common. Usually, things like syntax highlighting and error detection as you type, project management tools, version control integration, autocomplete, documentation/API tooltips, debugger integration, etc. are the advantages.
Some of those might be less relevant to Haskell than to, say, Java/C# style languages, but some of them would still be useful.
Of all the benefits I've heard ever used to sell IDEs, that's got to be the least common. Usually, things like syntax highlighting and error detection as you type, project management tools, version control integration, autocomplete, documentation/API tooltips, debugger integration, etc. are the advantages.
Some of those might be less relevant to Haskell than to, say, Java/C# style languages, but some of them would still be useful.
My impression is certainly that IDEs are aimed at beginners and users of more 'complex' languages like Java. (Case in point: Java has DrJava and other beginner IDEs, as well as IDEs for professionals like IntelliJ.)Indeed, I was referring to the the claim of the OP that "you don't need to mess with setting things up", which, to me, seemed to imply that it was a significant hurdle to get started with Haskell using an editor and ghci.
Syntax highlighting is part of any editor that is aimed at programmers, the interpreter does a great job highlighting errors, version control is done with git, and there is plethora of documentation on Haskell available too. Normally, ghci satisfies that need as well.
Syntax highlighting is part of any editor that is aimed at programmers, the interpreter does a great job highlighting errors, version control is done with git, and there is plethora of documentation on Haskell available too. Normally, ghci satisfies that need as well.
IDEs exist because they give you the full, bidirectional power of the compiler at your fingertips as you type, complete with annotations, jump-to-definitions and other code navigation, and syntax tree transformations (as opposed to just textual ones). If you think syntax highlighting, version control integration are top features you are sorely mistaken.
The fact is, you CAN do many of the things an IDE can do without one; its just generally harder, less discoverable, slower, takes longer to master, and for no real benefits. I would rather have a text box pop up saying exactly what types something has, and all the documentation about those types, and where it is defined in code, directly within my code in 0.1 seconds, then have to go and run some grep or hoogle search or whatever.
The fact is, you CAN do many of the things an IDE can do without one; its just generally harder, less discoverable, slower, takes longer to master, and for no real benefits. I would rather have a text box pop up saying exactly what types something has, and all the documentation about those types, and where it is defined in code, directly within my code in 0.1 seconds, then have to go and run some grep or hoogle search or whatever.
Type safe refactoring is a big reason to use an ide over just an editor.
I write scala in an IDE and I am not a beginner
Scala is arguably part of the group of 'complex' languages I mentioned. Besides, the Scala worksheet functionality in Eclipse is really neat, which is another reason to consider using an IDE for it.
> I don't get the appeal of an IDE in Haskell development.
Code completion, syntax checking, looking up documentation, setting up projects and makefiles, code re-factoring, etc... Granted, Emacs and VIM will do most of this, and the language's tools will do the rest, but some people like having everything in one convenient package...
Code completion, syntax checking, looking up documentation, setting up projects and makefiles, code re-factoring, etc... Granted, Emacs and VIM will do most of this, and the language's tools will do the rest, but some people like having everything in one convenient package...
Installation hardly counts as a success when you're playing with a new language. An IDE that can make intelligent suggestions would make Haskell much, much more approachable.
> nicely structured codebases whose language helped prevent a jumbled undocumented mess
What makes one think that any language can prevent "a jumbled undocumented mess"?
What makes one think that any language can prevent "a jumbled undocumented mess"?
Nothing can prevent a undocumented mess, but certain factors can help mitigate it. For example, most people in Haskell write the type declarations for their top-level functions, which certainly helps. Also, because you need to be honest about side effects in Haskell, if you see Vector a -> Int -> a, you know there are no side effects and so you can be pretty damn sure that this is an indexing function.
Not just is that function pure, but free theorems indicate that the only way you can get an a is by using the Vector that goes in. Sure, it could ignore the Int - we don't have linear types, afterall - but it really does narrow down the "what could this do?" options.
For those interested, ocharles is talking about Theorems for Free![1] by Phil Wadler. Also be sure to check out his 24 Days of Hackage 2013.
[1] http://ttic.uchicago.edu/~dreyer/course/papers/wadler.pdf [2] http://ocharles.org.uk/blog/pages/2013-12-01-24-days-of-hack...
[1] http://ttic.uchicago.edu/~dreyer/course/papers/wadler.pdf [2] http://ocharles.org.uk/blog/pages/2013-12-01-24-days-of-hack...
I believe no language can prevent a "jumbled undocumented mess", but it a language can get pretty far just by making paths to make documented and clear code easier than paths to no documentation and jumbled code.
It sounds like a thinly-veiled quip against duck typing.
Type systems are self-documenting? (Or, Hindley-Milner type systems are self-documenting?)
Type systems are self-documenting? (Or, Hindley-Milner type systems are self-documenting?)
Oh yes! My favorite part of Haskell's type system is it's documentation purpose. It doesn't cover intent very well, but it's quite frequent that I can reason about the entire purpose and functionality of a function just by looking at its type. This documentation is guaranteed to never go out of date.
I feel that while type information is useful, some of the more advanced libraries have signatures that are very difficult to reason about.
Disclaimer: Didn't write read a lot of Haskell so it may be just that.
Disclaimer: Didn't write read a lot of Haskell so it may be just that.
Definitely. It can go VERY overboard at times, and that's part of Haskell style, writing code that makes intelligible types appear. It means that both the compiler and your users will have an easy time with your code. Most of the best libraries are pretty good about that.
It's also a familiarity thing. The most complex signatures require some practice before they're easy to digest.
It's also a familiarity thing. The most complex signatures require some practice before they're easy to digest.
See, the issue I have with this is that in my own experiences with other language, this is almost never a problem. I don't need to know "what" something is doing, I need to know "why" the developer did it that way. Haskell seems like it goes out of its way to obfuscate intent with heavy abstraction, avoidance of semantic variable names, and sometimes avoidance of variable names entirely. That seems like exactly the sort of code that I find least comprehensible...
By "what" I mean semantically what---I need to know that this function turns a Tree into a List or a Person into a String. I find this information very useful as it's fairly non-operational. Usually functions are further documented with a bit of intent information.
The avoidance of variable names is hard to judge until you program in Haskell a lot. Variables (or "points") tend to just be used to wire pipes together. These variables are rarely used more than a line or two after their definition and thus short names emphasize this local context.
When people write code that involves variables naming mutable cells or long-lived context they provide long, descriptive names. I don't think anyone disagrees about the utility of that. It's just a rare style in Haskell.
The avoidance of variable names is hard to judge until you program in Haskell a lot. Variables (or "points") tend to just be used to wire pipes together. These variables are rarely used more than a line or two after their definition and thus short names emphasize this local context.
When people write code that involves variables naming mutable cells or long-lived context they provide long, descriptive names. I don't think anyone disagrees about the utility of that. It's just a rare style in Haskell.
Calling it "self-documenting" might be a bit of a stretch, but I can assure you that having type information in the absence of comments helps a lot -- the base level of no documentation is much easier to work with.
What gave PHP its boost was a pervasive mod_php, and an instant change-file/see-change cycle.
mod_buildpack?
mod_buildpack?
Not sure if it's related (not a web developer), but here it is anyway: http://nixos.org/~eelco/mod_haskell/
For me, the biggest issue to learning Haskell is once programs progressed to a certain level of complexity, the sheer amount of types that got thrown at me made my head hurt. I could deal with pure functions, IO, monads (I even like monads), even mutable variables and arrays weren't too bad. But the types, so many types and types of types... It seemed every value that was meant to represent anything had its own type and reasoning about what function to use on what type was too much.
Maybe I'll revisit it one day, but that was my pain point...
Maybe I'll revisit it one day, but that was my pain point...
The more software you write in it the more that stuff becomes second nature (unless you're a library writer in which you have to reason about your types very carefully).
Two, well, issues from my experience with gitit (great software by the way): compilation may take huge amounts of RAM compared to what the webapp itself will later use -- it is likely that one will need to use some other, metal machine for building. Also, Haskell is doing idle garbage collection which eats CPU even when nothing is happening, and this may become a less or more painful surprise. It can be turned off, though.
I don't have any specific info about what the parent post was talking about, but for those that were curious about Haskell's garbage collector in general (like me), here is a Stack Overflow link with some explanation:
http://stackoverflow.com/questions/15236238/current-state-of...
And here is the GHC (Haskell compiler) docs on controlling the garbage collector:
http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/runti...
http://stackoverflow.com/questions/15236238/current-state-of...
And here is the GHC (Haskell compiler) docs on controlling the garbage collector:
http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/runti...
> idle garbage collection ... Eating CPU when nothing is happening .. Painful surprise
Wait, what?
Wait, what?
Cool. Does Haskell have a great web development tutorial out there that could use this?
The "book" for Yesod framework is quite like a walkthrough - http://www.yesodweb.com/book
The Happstack tutorial [0] is pretty great and I just put together a bare-bones compiling Happstack server [1]. That might be a great way to start. Happstack is a fairly unopinionated web package, so there's a bit of elbow grease needed still, but it's my favorite.
[0] http://www.happstack.com/docs/crashcourse/index.html
[1] https://github.com/tel/happstack-heroku-test
[0] http://www.happstack.com/docs/crashcourse/index.html
[1] https://github.com/tel/happstack-heroku-test
I wrote a tutorial a while back that finishes with deploying to Heroku: http://adit.io/posts/2013-04-15-making-a-website-with-haskel...
I get the desire, but you'll never be able to popularize Haskell because the only people who want to use it are math majors, and most web devs are not math majors.
If you want to popularize Haskell you'll need to rework the syntax at the very least.
If you want to popularize Haskell you'll need to rework the syntax at the very least.
> the only people who want to use it are math majors
Edit: This is FUD and I kind of feel offended by it, though I'm not sure that is rational
I'm not a math major. I am a web dev. I want to use Haskell (and am using in a smaller capacity) because it means I have to be up late fixing things less. It means that I can worry about my sites getting hacked less because of the strong static typing guarantees which protect me against csrf.
On top of all that type annotations are great for documenting things. On top of that, composing functions and monads can allow you to do things much safer and much more quickly.
There are many teaching resources which show how some of Haskell's perceived cons can be pros such as these:
http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...
http://book.realworldhaskell.org/
http://learnyouahaskell.com/
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_... (with web dev applicable example) http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_H...
Honestly from my experiences in #haskell on freenode, /r/haskell, and Haskell related content on the web it seems like many more people are using it with the intent to make "real world software".
I haven't gotten the ivory tower vibe from anyone in the Haskell community yet. Quite the opposite actually, everyone seems very pragmatic.
Edit: This is FUD and I kind of feel offended by it, though I'm not sure that is rational
I'm not a math major. I am a web dev. I want to use Haskell (and am using in a smaller capacity) because it means I have to be up late fixing things less. It means that I can worry about my sites getting hacked less because of the strong static typing guarantees which protect me against csrf.
On top of all that type annotations are great for documenting things. On top of that, composing functions and monads can allow you to do things much safer and much more quickly.
There are many teaching resources which show how some of Haskell's perceived cons can be pros such as these:
http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...
http://book.realworldhaskell.org/
http://learnyouahaskell.com/
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_... (with web dev applicable example) http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_H...
Honestly from my experiences in #haskell on freenode, /r/haskell, and Haskell related content on the web it seems like many more people are using it with the intent to make "real world software".
I haven't gotten the ivory tower vibe from anyone in the Haskell community yet. Quite the opposite actually, everyone seems very pragmatic.
The syntax for "record types" - elements of named tuples - is really awkward and pollute namespace.
I.e., if I want a module in my app to have two different types containing an element 'customerID' that I'd like to refer by name in that context, then it's a bit painful - and it is a really common need if I need to quickly make a mostly-CRUD webapp, for which otherwise Haskell/Yesod would be as practical as Ruby/Rails.
I.e., if I want a module in my app to have two different types containing an element 'customerID' that I'd like to refer by name in that context, then it's a bit painful - and it is a really common need if I need to quickly make a mostly-CRUD webapp, for which otherwise Haskell/Yesod would be as practical as Ruby/Rails.
There are a few different solutions to the record name space problem that are due to land in the next year. And already some decent lens based solutions too.
Most frameworks protect you against CSRF, that is not unique to Haskell. Other languages also allow you to check your work using tests and static checks.
I would argue that it isn't quite the same, since with Haskell you can enforce it with the type system. While other frameworks are great pieces of engineering and usually well tested, Haskell is nothing without it's type system therefore tons of work is put towards ensuring that what the type system says is true, is true.
The other thing is I believe frameworks like Yesod use property based testing which IME catches a lot more than unit tests by themselves.
I feel like my point is unclear here, perhaps someone more experienced with Haskell and/or Yesod can articulate it better than I can.
The other thing is I believe frameworks like Yesod use property based testing which IME catches a lot more than unit tests by themselves.
I feel like my point is unclear here, perhaps someone more experienced with Haskell and/or Yesod can articulate it better than I can.
The syntax is not the problem for Haskell gaining acceptance for web dev.
Most web devs are frightened by functional programming idioms and will run away screaming when exposed to monads.
But the biggest problem imho is the type system that while great, makes things like making simple structs / named tupples or whatever you want to call them annoying and the lack of any "nice" way to just do OOP in it - and no, saying OOP is a bad idea and pretending it doesn't exist doesn't work.
Scala is a good Haskell for web dev. But it's too complex and has no chance of broad adoption against Node/Javascript, Ruby, Python and even PHP frameworks because for 90% of devs it simply doesn't bring anything good enough to make it worth putting up with the complexities stemming from the unholy OOP+FP mix.
Most web devs are frightened by functional programming idioms and will run away screaming when exposed to monads.
But the biggest problem imho is the type system that while great, makes things like making simple structs / named tupples or whatever you want to call them annoying and the lack of any "nice" way to just do OOP in it - and no, saying OOP is a bad idea and pretending it doesn't exist doesn't work.
Scala is a good Haskell for web dev. But it's too complex and has no chance of broad adoption against Node/Javascript, Ruby, Python and even PHP frameworks because for 90% of devs it simply doesn't bring anything good enough to make it worth putting up with the complexities stemming from the unholy OOP+FP mix.
I'm a Java dev in my day job, and I have to say that as a beginner in both Haskell and Scala, I surprisingly find Scala far more difficult than Haskell.
Scala's type signatures are even harder than Haskell's (or at least, mixing FP with OOP makes them harder for me) but you don't get the same guarantees about side-effects and the type inference doesn't work as well. And implicits scare me.
Scala's OOP may be good or bad, but it certainly adds an additional layer of complexity, and one you can't ignore when reading or using someone else's code.
Scala's type signatures are even harder than Haskell's (or at least, mixing FP with OOP makes them harder for me) but you don't get the same guarantees about side-effects and the type inference doesn't work as well. And implicits scare me.
Scala's OOP may be good or bad, but it certainly adds an additional layer of complexity, and one you can't ignore when reading or using someone else's code.
[deleted](2)
The syntax isn't the primary difficulty for a beginner by any means.
Please, if you've ever taken even an introductory college math course you'll understand Haskell's syntax. Heck, it's not that hard to reason about even if you haven't...
Clearly a troll, down-vote and move along.
It's a new company focusing on this exact problem. They offer tools like an IDE and deployment model. You can just sign-up on their website and start coding directly, you don't need to mess with setting things up. They also got School of Haskell which is a central place of really great tutorials ranging from tutorials on developing web apps to category theory stuff.
Check them out: https://www.fpcomplete.com/