| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Learning / Teaching | Tools (ide, debugger, profiler, etc.) | Other backends | Mainstream usage | Laziness | Language | GHC | Packages, Libraries | Hackage | GUI | FFI | Support for other platforms | Cabal | Performance | Doesn't improve productivity | Stability / Backwards Compatibility | Culture | Distribution / Deployment | Documentation / Library Documentation | Integration? | |
2 | When people write about Haskell they quickly decend into abstraction and academic jargon that gets too far away from what is going on inside the programs. There is a hurdle to understanding to get over that can be pretty big especially if you can't follow the intermediate steps. | Leksah isn't stable enough. The latency between it and the compiler leads to not that painful yet bugging glitches, not to mention the debugging process seems like a visit to a circus to an average imperative programmer used to gdb for instance. | - CLR/JVM/JavaScript backends | - unfortunately lack of acceptance in real world | - lazy evaluation incompatible with strong analysis of algorithms - lazy evaluation and parallel computing seem to be at odds in GHC. Robert Harper has commented on that. | * not requiring type decls for top-level identifiers * namespace issues (not allowing record types to share field names) * semantic significance of upper/lower case in identifiers (because of not requiring explicit forall in polymorphic types) * over-emphasis on lists in Prelude (instead of other container types) | * (not Haskell per se, but ...) ghc minor version changes breaking (hackage) libraries | "academic" approach (vs. commercial/pragmatic) sometimes results in libraries that are hard to understand and/or use (proof-of-concept vs real word) | Haskell as an ecosystem has a big problem about Hackage's organization. We need to redesign it someday. | 2. Lack of Mac / Coco support. I would love to use Haskell for UI projects, but don't want to go the second-class linux UI route. Again, a major issue here is difficulty in integration with the OOP paradigm. | 1. Difficulty of integration with C++ (not C). Ability to import C++ headers directly and call C++ methods without inventing wrapper layers would help immensely here at Google. | 2. Windows support is usually an after-thought. | Cabal doesn't seem to be consistent enough (though it's genius otherwise), e.g. I'm unable to install a scion lib (for haskell eclipse plugin), because cabal will enforce the most recent ghc version whereas scion depends on a very narrow fork of versions from around 6.0. | Although it is generally regarded a good thing to have diversification, there are two items where I'd like appreciate an authoritatively dictated choice: 1.) The non-unified (esp. among libraries) Error/Exception handling, as well as 2.) the record-update problem (there are the lenses/fclabels/etc packages, but again, this is a non-unified approach, and it feels clumsy to have to use underscores to mark fields -- I'd prefer a GHC language extension) These are _the_ two things (among a few other minor issues) that I dislike the most | Although performance really matters, I find that the cost of annotating Haskell source code with compiler hints (bang patterns, unpack and inline pragma) just prohibitive. I use haskell because I like idiomatic, short, elegant code. If performance can't be reached that way, maybe it's time to re-think the language, or work more on the compiler. Just dreaming :) | Although the purity and strong-type-system sound all well and good, I'm not actually convinced yet that Haskell improves productivity. Perhaps I'm not "doing it right", but even after 8 months I generally write code and think, "I could have slogged through that faster in C++." And at least then I could have used it at work without fear of being 'that guy'. | API/language stability! When I come back to code I wrote back in 2009 and try to compile with current Haskell platform, new libraries cabal installs have different APIs, old version of libraries won't compile on current platform. This is very different to my experience with java/python, and makes it hard to conceive of putting Haskell into production products. Somewhat unusually, Haskell does have a good language definition, but it's almost useless since the vast majority of useful packages depend on non-standardised extensions. Haskell' needs enough features that the majority of Hackage can be built within the standard language so that it's feasible to code real world applications against a standard with long term support. | Culture of short and cryptic reference names like x, xs, fst, snd, and the likes. | Distribution of Haskell programs to others is still hard: at best I can tell them to get the platform, run a bunch of cabal commands, then build my program. | Docs docs docs. The running assumption is the type signature is all you need. But many libraries use complex types, monad.transformers, etc. Python has brilliant docs which include examples of good use. This should be emulated. | Integration with current main stream OOP environments. |
3 | difficult to grok complex things like monads, as there are a lot of mathematical explanations, but not too many practical guides | Personally, I love that Haskell remains a research language, but I also need to know what the 'stable/trusted subset' is in order to be confident about deploying those features. I want at least this subset to be supported by productivity tools that I can use reliably in a commercial software development environment. | - lack of cross-compiling abilities - missing ability to compile to jvm bytecode. | Bad public image due to FUD, such as "It is hard to reason about performance and space usage of Haskell programs" (not any harder in practice than for other mainstream languages given the same level of skill and experience, which is usually not the case for people who complain), "Haskell is not suitable for enterprise commercial development" (that's what I do for a living now and it's great; how hard have the people who complain tried to build a Haskell career?), etc. The problem with this kind of "survey" is that it tends to reinforce that kind of FUD. But it's good to look for ways to improve; I just hope you'll try to remove some of that bias in the tone of your results. Thanks for this great survey! | * lazy IO | Outdated Monads | Applicative | Arrows class structure (lack of Pointed class). | Diagnosing compiler error messages often requires much more sophisticated knowledge of the language and type system than a beginner has. Maybe this is due to more of the theoretical underpinnings being exposed to the user? But, the result is more stumbling blocks being encountered, thus slowing down progress. | An additional complaint is that the inclusion of OpenGL packages in Haskell Platform makes it inappropriate for use in virtual appliances and headless servers. To make Haskell Platform a standard base, it should not have UI dependencies. | 1. Dead packages on hackage (unmaintiened) | * lack of easy cross-platform GUI solution (surprise surprise...) | Calling C++ functions is hard | (slightly offtopic but the fact that GHC7 does not support OSX 10.5 - which imho would be trivial to solve with some conditional compiling - is an extremely sad thing). | Integration of Cabal with package managers. | - Haskell hackers talk a lot about program correctness but I'm still waiting to see any one in the Haskell world tackling program corrected as Dijskstra did. Actually ghc seems to have at least as many bugs as gcc, contradicting the idea that correctness comes for free with functional programming | Realtime -- such as a realtime modular synthesizer. (Mostly due to stop the world garbage collection). | - Haskell hackers talk a lot about program correctness but I'm still waiting to see any one in the Haskell world tackling program corrected as Dijskstra did. Actually ghc seems to have at least as many bugs as gcc, contradicting the idea that correctness comes for free with functional programming | * GHC is absolutely great but it would be good to have some serious alternative | From imperative world, good variables and function's names were more important than documentation. And examples that I get in Haskell, names, in most of time, seems irrelevant. Good names always help who read the code...(I don't know if this is a habit of my Java background, but help a lot for newbies). | Ease of deployment: Still have too many systems that are trying to be "all-Haskell", and so don't integrate well into the existing environments people have already in place. | As a hobby, I found educational material about library features that are supposed to be common knowledge - Applicative, for example - lacking. But why do closing thoughts have to be negative? Haskell is awesome! | Integration with other build systems. Pretending that cabal is the only true thing is only that, pretending. Until integration with at least auto* tools is better, Haskell project will be standalone and integration Haskell into a bigger system will be painful (one has to duplicate cabal's work in detecting libraries, library version, etc.). |
4 | It is very difficult to get up to speed on what libraries to use and when to use them. Also a cookbook of design patterns would be great to help people transition from the OO world. Kind of just a mapping of this is what you do in OO and now this is how you have to think about it. | * Diagnosing space leaks requires low-level understanding of how the compiler works, and even then, they are often tricky to track down and rectify in practice. Support in terms of tools and documentation (like the blogs by Edward Yang) are lacking. It's unclear what the consequences are under the hood if strictness is enforced in user code. Otherwise, I love the language and its community! | Accepted backends for common platforms such as JS/Browser, Java/JVM, .NET/CLR/CLI. | - adoption | Being lazy by default; | Too many string-like types. Abstraction over them that would provide stable and practical API would be nice. Change String from type to class? I'd realy like to see Functor (=> Pointed) => Applicative => Monad one day. | 2. No win64 ghc. | Second, some of the basic libraries would benefit from a refresh. Simple example, Data.Map is missing insertWith' that applies the insertion function strictly. Why? And since it does not export the constructors (design flaw) implementing it by hand is contrived. Another library that would need some love is Data.Array (maybe Repa could be a subsitute?). At least the basic libraries should be free of design/implementation defects. | Absense of the social Hackage promised long time ago | A GUI library that works out-of-the-box is stil needed, so that even beginners can write functional GUI programs. | Can't communicate with scripting languages like Python (actually possible but painfull). | * Some libraries fail to install on Windows or require i.e. minGW | "cabal install" usually fails. | ; confusion with Pascal! | hard to reason about performance, | API stability has been a significant impediment to commercial usage, but the situation has been improving in recent years. | http://willowbend.cx/2011/07/22/whats-wrong-with-learning-haskell/ | The fact that the versions of GHC and the libraries as included in most distributions (especially Debian) are too old. That makes it difficult for me to use Haskell in production at work. | Documentation must improve to attract new programmers. For a beginner not coming from a functional language, the road to Haskell is still stony. | Integration with other languages, like Java, C++ | |
5 | - difficult for those new to functional programming | 2. IDEs immature. 3. Hard to reason about runtime performance (Java and Javascript have issues too but the vm adapts at runtime so programmers don't have to care). | And if I could target .nets CLR directly I would start using Haskell in production at once - F# is fine but it's just not the same. | - Many libraries seem to attend just purpose of getting published papers. Example: Accelerate. | It's hard to understand exactly how much work is being done due to lazyness. | Lack of reflection/only being able to derive system type classes. Show et al should not be special. I implemented Data for a type with lots (>100) of Data constructors, resulted in a large amount of boilerplate code. | Compiler errors are unfriendly (especially for a newbie) | Image processing libraries, | Also incompatibilities of hackages wrt to dependencies and API. Platform is too narrow and gradually getting out of date. | Better GUI libraries (and integration with FRP) would be great, and would lead to wider adoption of Haskell. They're good, but could be much better. | In my opinion, it is - even if you use the FFI - extremly complex to write bindings to other languages that use structs for returning values / as arguments. It would be much simpler if there was a tool that could automagically translate a C struct to Haskell. | 1. Libraries won't necessarily build with other libs on all platforms. | * cabal can be pretty bad in figuring out dependency situations | 2) Lack of support for dev environments -- coming from Python where it's extremely easy and beneficial to build a virtualenv or sandbox environment, using cabal-dev requires a lot more work. And when you're trying to use it with packages like Yesod that rely on your main cabal folder or global variables, it either doesn't work or requires a lot of tweaking. I'd love to see a better way to build supported virtual Haskell environments to cut down on the headaches of managing multiple dependencies and different versions of packages | hard to reason about space usage | As long as Haskell's been around, it's still a very young language and community. Changes to the language or to libraries ripple out in minor little waves of destruction. That's both a strength and a weakness. The above weakness is particularly glaring when combined with academic library efforts, where a problem is solved, and the library pronounced "finished". That state may work for a couple years, but should a change happen which causes a build break or other problem, hackage is left with essentially useless entries. | It still suffers from an academic mindset in it's community that puts more practically minded people off / creates a larger barrier to entry than necessary. | We're not looking at easy distribution in a serious way yet. | Integration with current main stream OOP environments. | These days, it may be having a compelling selling point over something like Scala which offers all your FP goodness without having to leave the comforts of your Java world. Or put another way, lack of integration with the non-Haskell world. | |
6 | - hard to get started for Java-Programmers | - easy to use debugger; | Another problem for adopting Haskell at work would be that it doesn't run on JVM/CLR. So there is no option for polygoltting | 2. Lack of Developers | laziness | * The current module system has little to do with modularity. I propose to port Agda modules into Haskell. They are a lot simpler than ML-modules, but can be parametrized and applied. In the use cases that I have in mind a reader monad is sufficient, but honestly, using a monad for every function is the module is ugly to me. Ref: http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Modules | Error messages quality with advanced types. | More libraries: eg processing ontology files/owl | but there is also a serious problem with respect to hackage security and identifying reliable packages. It is too hard to find out what packages/libraries are stable and maintained, and it is too easy for a malicious user to inject code into existing libraries on hackage. | Developing GUI applications. | The difficulty of using it in tandem with another language.. most "bridge" projects to Objective-C, for example, don't work and are abandoned.. | 2. Lack of Mac / Coco support. I would love to use Haskell for UI projects, but don't want to go the second-class linux UI route. Again, a major issue here is difficulty in integration with the OOP paradigm. | * cabal-install needs more manpower; features I miss the most: uninstalling packages & installing profiling versions after you got the "normal" (had to do this by hand once -- nightmare) | Clearly can't choose only one. In approximately descending order of glaringness: - Abstraction carries a performance penalty In a language which prizes abstraction this is obviously absurd. Could maybe be helped with polymorphism-by-multiinstantiation (aka automatic specialization) with weak linking, like C++ templates do. - Orphan instances and packages The problem of "I want an instance for a class from package A for the datatype from package B, but that means one of them has to depend on the other or I have to make an orphan" hinders integration between packages way too much. My current preferred solution would be to allow parts of a package to 'weakly depend' on other packages, so that if some parts of package A weakly depend on package B, then B isn't required to install A - it will be built without those parts - but if B is installed later then the weakly dependent parts of A will automatically become available as well. This would remove a lot of the unpleasantness (and could be used for other things besides instances, of course). - The module system sucks Even as merely a means for managing names it's frustratingly under-capable. Importers have lots of control over how they import things (which is good), but are forced to exercise it too often because exporters have very little control over how they export them. It should be possible to (re)export names pre-qualified, for example, modules-within-modules, so that module authors can provide sane defaults, and importers should only need to manually tinker with them in exceptional circumstances. - Performance is hard to reason about, and performant code often looks ugly There's always a feeling of betrayal when you write beautiful code and have to dirty it with strictness annotations, pragmas, worker/wrapper transforms, and such to make it perform well. Having to provide both strict and lazy versions of every type, module, and function is stupid. Having to think about which to use is annoying. It's probably impossible to make this problem go away entirely, but I feel that significant advances should be possible relative to the status quo. - Many people like to stick to standards-conforming code, but the standard is very slow to evolve. | As noted and clearly in the mind of this survey's author, reasoning about space and time is the single most tricky thing when programming in a lazy FL. I can wax lyrical as much as anyone else about the representational benefits of Haskell and indeed all the robust compile-time type checking, but runtime performance _can_ be the thorn in the flesh. | Backwards compatibility/bit rot. Haskell 98 and 2010 help, but hardly anybody sticks to those. | Overuse of points-free notation, leading to vastly decreased readability. | By far the biggest problem is the lack of a "middle ground" in documentation. There is ample beginner/tutorial documentation, and extensive "academic expert" documentation (proofs, discussions of mathematical properties of zippers, etc). However, there is very little "application writing" documentation. The problem crops up most often with libraries. Often a library that does something very useful has no non-trivial examples included, and no discussion or tutorial of how to actually put it to use. The library's API functions are often described in terms of their mathematical properties rather than what you would use them for in a "real" program. A few libraries I've suffered this with include fclabels, data-accessor, fgl, and especially haxml. All of these are practically indispensable for writing applications, but have almost no application-oriented documentation. Haxml was a particularly sad case; I had to give up trying to understand it entirely due to the lack of useful documentation. This type of documentation may seem to "fall out" from a mathematically-oriented understanding of the library (such as haxml's combinator scheme, or the concept of "lenses" in fclabels), but an application programmer does not have time to work through proofs of lens properties and then figure out what they might be good for in a program. Instead, the application programmer needs cookbook-style documentation to get something up and running, and then s/he can come to understand and make use of the underlying math. One of the few libraries that does this right is Parsec. fclabels at least had a reasonable toy example, but data-accessor fails epically in this regard. If application programmers could "get their programs started" more easily, without having to burn so much time wading through math-oriented documentation, I believe Haskell would be more widely adopted. The existence of math-oriented documentation is a very good thing, and is quite helpful when you need to know about those properties, but such documentation is not sufficient for bootstrapping an application. | |||
7 | * difficult compiler messages (for beginners) --- maybe a "beginner flag" for GHC that gives type error messages and a link to haskell.org where there's a longer tutorial on what the heck that error means? | (a) We lack tools, that accurately find definitions and call sites of functions. Moreover, writing such tools in not trivial (due to -fth and -cpp). This makes source code navigation and automatic renaming of functions (ala Eclipse/Eclim) hard. (b) No location info when things go bad (no stack traces on exceptions, no line numbers for log messages). | Blind spots: missing compile once + run everywhere (virtual machine and byte code are so widespread today), | A lack of real-world example programs to review the source of. | laziness | 1st: Name scoping/precedence rules, i.e. lack of ability so say which variable should decide which function to bind to (something all object oriented and prototype based languages got using the "."- or "[ ]"-notation (in the case of ObjC)). | GHC's error messages. Which are wonderful, compared to most other languages/compilers I've used, but since so much is done at compile-time, error messages are correspondingly more important. | * the dependency hell situation is starting to get really grave | Hackage could need some improvements like a voting system or a "most popular" category for packages as it's quite hard to find the most useful library in the amount of different packages in a single section. A comment section would be very helpful aswell, as you could ask the author/other library users specific questions about that library or point out weaknesses in the library design etc. In general, more community integration is needed here. | Easy and stable out-of-box crossplatform GUI, | 2. Windows plattform is not well supported | cabal doesn't track executables, so sometimes there's a build error that indicates that happy and/or alex needs to be installed, but the message would be baffling to beginners. I wish cabal would use all my cores during builds. | Even after 20 years we are still struggling with some basic concepts and their implementation in Haskell. A good example is iteratees: the idea is rather new, the problem that it solves is one of the most basic ones, and there are several competing implementations, so it's not clear what should one use. | Difficulty in figuring out and controlling what will be fully evaluated when--I work with data sets too large to hold in memory and when iterating over them I often unintentionally leave unevaluated thunks in containers for accumulating summary data. | Big dependence on GHC, would like to see some new life for a lightweight implementation like nhc or Hugs. | Standardizing semi-widely adopted advances. | Documentation | ||||
8 | 1. Community is hostile to changes that would make it easier for newbies or programmers without strong CS / math backgrounds. 2. Compiler error messages aren't helpful to new users. Related: type syntax is difficult to understand. | * (also not Haskell the language, but ...) missing tool support for refactoring | GHC portability It would be great to support ARM devices. | a stereotype of being hard to learn, only used in research, not ready for the real world. | laziness by default | 2. Interpreting of code ('EVAL') is a mess. | Instability (as Haskell = GHC, for all intents and purposes) due to GHC being a research platform. | 1. Diamond dependency problem / linking against multiple versions of the same library / general managing different versions of packages. 3. Libraries relying on C libraries tend to segfault. An exception is preferred. | Hackage is a mess, it's very difficult to find libraries, it's very difficult to know which libraries are well designed for which tasks and there are no links between libraries that are similar. There are no statistics to know which libraries are widely used and no voting system. Old libraries that no longer work are sill in Hackage and it is not possible to filter them out. Package groups like yesod are a mess on Hackage, some packages are up to date, others are old, others have been folded into larger packages and will cause errors if you try to build them. Hackage by far the biggest problem in the Haskell community. | GUI | Build compatibility of libraries. | cabal specific: problematic build can kill your ghc-pkg system... dependency check based on md5 checksums is problematic for differently configured libs | Haskell shines at maths. Every function is really a mathematical function, and is a pleasure to explore maths with Haskell. I would like to see more math tools, for example: * a FFI interface to Maxima, or some kind of CAS written in Haskell * a graphics REPL like Processing * a FFI to pari/gp, etc. | Difficulty reasoning about performance especially when first learning Haskell | Even though Haskell is standardized, the old code seems to be breaking quite often! Either the API of the base libraries is changed, or GHC behaves differently, or cabal stops working. Sure, all languages have that phase in the beginning, but I think Haskell should be past that by now. I wish the Haskell ecosystem could be a bit more stable while still making progress. | Documentation is slowly improving, but often isn't very good even for larger projects. For example, there is little documentation via comments in Yesod, and the documentation on the website is limited and incomplete. When trying to use it I basically had to guess what I needed and try things until it worked. Given the size of the Yesod code base, you would expect more. And the same is true for a lot of other big Haskell projects. | |||||
9 | 1. Haskellers think that normal humans know what a "monoid in the category of endofuctors" is, and that this and similar language is a sufficient explanation. | * maybe it's just my ignorance but i find the heap-profiling tools inadequate | I do want to say that I think it would be cool if it ran on the JVM. As for the language itself, I think it's great! | Adoption hampered by its image of being difficult, different, and low performance. | Laziness in long-lived processes. | 3. IO should be easier. Unsafe IO should be the default. There, I said it. | LGPL. ghc cannot be used for developing commercial software products out of the box. Many Hackage libraries that are not LGPL are still infected by it indirectly due to library dependencies. | 1. Lack of Libraries | Hackage needs a package rating system. An official naming standard could help make using 3rd party packages easier. | GUI libraries | Cross-platforming is still pretty hard to do. | Difficulties of keeping versioning straight with Cabal | i think haskell is a very good langauge, but i would change the specific use on Ubuntu, because i had very much problems, i wish, that more people do haskell and i wish me a permanent haskkell platform, or a forum. If i see that someone descriminate me, i have to say: I have a lot of guns And i can shoot them good I'm a man of high society A boy from the Hood. My friend Sergay kills YOU!!! | Hard to reason about performance. | Haskell 98 vs Haskell+Extensions. | Documentation. In most cases, a function without examples (e.g. doctests) should be punishable by death. | |||||
10 | A lack of coding/design guidelines to prevent space leaks; trying to find space leaks afterwards is not good enough . | * space-leak analysis tools * really hard to analyze statically (C is easier) | It's missing a back-end targeting the JVM. | Biggest problem - Lack of commercial use. On the library questions - I'm generally pleased with the ease of finding a library for a particular task and with the quality of the libraries although I know that other languages have more extensive offerings. On the run-time performance - This is mostly a non-issue for me. Haskell is usually "fast enough" that I don't have to worry about it. Of course, it can be a pain to track down a space leak. | Laziness is hard to come to grips with. It's powerful and good, but it also causes strange problems that a beginner often cannot diagnose. #haskell on freenode is a must for somebody learning the language. I also recall that when I was first starting out, it was amazingly difficult to do simple tasks like generating a random number or getting the current UNIX epoch. Having acquired some degree of comfort, I still find libraries that model dynamic data, like Text.JSON, to be very clumsy to use. | A better record system (e.g. with scoped labels) would be helpful. Modules should be independent of files, the current Java-like approach (at least in GHC) is inconvenient. | Two other reasons why Haskell is not quite ready for prime time are that, in my experience, an inordinate amount of time is spent on: * Static type compiler errors, when behaviour is not as expected. Compiler diagnostic messages could be much more helpful. The user should not have to reverse engineer GHC and/or wade through weeks of sprawling academic reading material to discover what is going on. | 1. Libraries: dependencies on small parts of one library makes you depend at once on a lot of other, which are not really necessary | Hackage needs an overhaul, both UI-wise and security-wise. | GUIs are not quite pleasant enough to write. Gtk bindings are okay, but not much more. There seem to be a lot of abandoned projects regarding this on hackage. | Distro support. Ubuntu's pretty out of date until I manually use cabal. | The Cabal Butterfly Effect. | IMHO, we should also frankly admit that Haskell is the language that can be handle by the GHC compiler. | huge resource consumption | Haskell's biggest weakness is that every year that goes by increases our dependence on GHC. The ease of integrating modules that use different extensions is ensuring that every library has a handful of dependencies on GHC that will be very difficult to remove. As more libraries depend on GHC, we take the steam out of alternative implementations, and we will find ourselves a language with a single canonical implementation. | Documented examples and documentation. I can't tell how many times as a noob I've looked up the docs for a project and had no idea what module contained the tools to get things done. If I did manage to find that module, I often can't figure out a practical example of using the functions it exports. This is a huge barrier for entry for me coming from Ruby. While Rubyists usually neglect docs, the examples are usually quite good. | |||||
11 | a stereotype of being hard to learn, only used in research, not ready for the real world. | A good GUI-based Haskell IDE, and proper support for GUI devpt. I am using wxHaskell, stuck in a time-warp (Win 7 GHC 6.10.4) so I can run it in GHCi From an IDE - an easy way to see which modules use what from where... Module-level refactoring would also be nice.... | Lack of JVM target. This is why Scala is making the running in commercial use of FP at present. Look at job statistics for Scala versus Haskell. | Blind spots: "enterprise haskell", | lazy by default | And the String datatype... | GHC is great but there are times where there's no known "bug-free" stable version. Often bug fixes are not ported to the current stable version if the next version is already in sight. Advanced use (retainer profiling) sometimes crashes GHC. It's still much harder to track down space leaks than it is with Java/Scala or Objective-C Tools (Instruments). Lazyness makes unstanding what's going on difficult and the tools don't compensate for that, yet. | A lack of depth in Hackage. There are quite a lot of packages now, but few of real production quality. | Hackage. | Haskell covers most of the important toppics of programming, except in the areas of GUI (gtk or wx are too much and often not buildable) and RPC (e.g. Corba, Soap). | ecosystem/community weaknesses: * cross-platform compatibility seems to be worse now than a few years ago * many people doesn't really care about Windows/OSX compatibility. | This isn't a weakness exactly. In fact, having found cabal-dev, I find it is rather a strength. I would like to see more "official" development done with it, and would like to see it become a part of the Haskell Platform. Without cabal-dev, the "likelihood that a library will build on my machine" would be very low (a 1). With it, it jumps to 5. I put in a 4, to indicate that it is a solved problem, IF one has the right tools installed. Also, I have built up a lot of bash scripts to streamline my cabal-dev workflow. Also, I would suggest a "no basis to answer" option (or at least interpreting a "no answer" as "no basis") | In my opinion, the biggest weakness is an increasing fear of change as Haskell gains popularity. Compiling Haskell for embedded systems is going to continue to be a more and more pressing need. Programmer culture at large is still not ready to embrace Haskell and take risks with it. We might do well to make an attempt to educate the general programmer populace about the benefits of functional programming in general instead of focusing specifically on Haskell (perhaps while establishing a tighter definition of "functional" than most people seem to adopt). | I find it quite negative, only to ask for the weaknesses. :-( Thus I'll first answer the opposite question: Best of Haskell for me is the expressive type system, relatively high consistency in the language definition, higher-order functions. Problem for me are space leaks and non-predictable performance in the presence of fusion RULES. Laziness properties should be expressible in the type system. | haskell98 is a toy language. haskell2010 was disillusion. In practice every package in HackageDB utilize many language extensions beyond the above standards. Lack of good and up-to-date documentation of these extensions forbids us to lobby Haskell more aggressively. But are there good packages too! | Hackage library documentation. I would very much appreciate some *examples* of how to use the most important features of the library. | |||||
12 | Adoption barriers: it's difficult to have it be standardized because functional programming is so different | A good IDE / Cabal Ticket #282 (profiling) / installation of bindings on windows | Need to cross compile to iphone, android. | Haskell community, support, documentation, tutorials are very much geared towards solving small problems (<one screen of code). Personally, I have often been frustrated when developping bigger software projects about - how to design a good structure - how to refactor - how to use good tool support - how to handle it when I find out that I need to pull IO monad through to a deeply nested pure function - how to reason about strictness and performance (i.e. how to get a writer monad with non-strict semantics so that it will give debug output on a non-terminating program) | Lazy by default. | Arrays: the ones in standard libraries don't have rich interface. Vectors are not included in GHC's standard libraries. | A lot of standard problems involving IO are still awkard in Haskell because of the lack of good libraries. For instance, random numbers (if you don't have Unix). | I don't have the years of experience that some of your respondents will, but my experience with Hackage is leaving me with a strong feeling that the the time of free-for-all may be coming to a close and that there would be a very, very, very good benefit to having a curated list of 'best of' packages that are reasonably comprehensive and widely used. Perhaps the Haskell Platform will be that one day, but for the moment, it is so conservative in its choice of libraries that it functions more like debian stable than a truly 'batteries included' system; until the HP gets there, a 'Best of Hackage' list would save a lot of time looking for libraries and wondering which are worth adding an extra dependency. | Haskell doesn't have a great GUI story. I think I'm allowed to say this as I maintain wxHaskell, and it's not where I would like it to be. | Good support for platform-specific libraries (e.g., Cocoa on Mac OS X) | Cabal seems to be awkward. | Isn't used enough in academic courses, AFAIK, even though it has features that blow O'Caml out of the water (GADT, ...) and GHC/LLVM is more efficient (and can produce position-independent code). | I find reasoning about performance quite difficult in the face of laziness, and I don't consider myself an amateur. I'm not convinced that laziness adds as much to the language as everyone thinks - perhaps it should be dropped? | If the goal is for Haskell to be more widely adopted, I think a number of integration details are important. Things like a stable ABI, bindings to more OS-specific services (such as Mac and Windows GUI systems), and even things like smaller compiled executables would probably make Haskell more attractive in production environments. | I realize this question asks for one weakness, but if it's all the same: 1) Library documentation -- I'm used to narrative docs with lots of real world examples. It would be helpful to see something along the lines of "use function x when you want to perform task y", rather than reading through a list of functions and possibly choosing to combine functions a and b to perform task y because you misread function x. | ||||||
13 | Adoption hampered by its image of being difficult, different, and low performance. | Also, leksah is on a good way, but I'm stll more comfortable with Emacs' haskell-mode. | No production-grade compiler to JVM. | haskell isn't used in business | The biggest drawback is definitely reasoning about strictness / laziness. If I could rewrite Haskell, I would default to strictness and make laziness optional. | As a personal preference, I would like to be able to have a dependently typed sublanguage but I'm still learning and I think I could make things work with what we have. I find that most the deficiencies in Haskell are really deficiencies within myself | Although Hackage has a lot of high-quality libraries, there are still several niches where e.g. Python has much better library support. | Infrastructure: update Hackage to Hackage 2.0! | I think that the most important omission of Haskell is GUI. | Haskell is a phenomenal language but ...Having more packages that just easily install on Windows eg hmatrix,gtk, perl style regex (pcre), hdbc mysql without having to go through odbc etc | It would be nice if we could get a solution where cabal could provide a simple build platform / shell environment where the gnu tools from the ghc installation would be exposed. Something like a specialized msys setup with a package management system (perhaps like the one used in arch linux). Cabal should then also have its own lib & include folders (besides the current bin folder). It could also be improved with a separate tools package for cabal that would install additional build tools not found in the regular ghc installation. | Reconciling the parallel execution model and the sequential execution substrate | I think performance is a serious problem. | If you pick a random one-year-old library on Hackage, I don't think it will have even a 30% chance of building in the most recent GHC without source modifications. That's just wrong. | I think that the lack of good beginner/intermediate level documentation on using many of the available libraries imposes a huge burden on getting started with the language. When I was getting started with haskell, I found that trying to deduce the behavior of a function from it's type was impossible, and even having done more serious haskell development I still find that it often takes far longer than it should to get a good understanding on how to use a library. Having additional documentation on how to use the available libraries would also go a long way toward making haskell easier to learn as there would be a much wider collection of examples to refer to. | ||||||
14 | As a newbie coming from imperative languages, it is difficult to design software with regard to I/O (leaving most code outside of the IO monad), especially when using a framework (e.g. Web frameworks like Snap) that puts you in a custom Monad. Perhaps it is just an issue with my lack of experience in functional programming. I would like to see more example code of non-trivial programs dealing with IO (RDBMS, networking, etc) | better editors/tools - EclipseFP is a good start, but a true VisualStudio integration would be great. | Portability: eg no ARM support. | I think Haskell has a bigger potential for real world problems. I consider this a matter of time. | Using on-demand/lazy evaluation as default everywhere. | As for the language, the lack of a sane record system. | Bad core libs. E.g. Http | It is still not always easy to know what the "canonical" library for a given task is, although one often exists. Hackage feels too crowded at times. | If the goal is for Haskell to be more widely adopted, I think a number of integration details are important. Things like a stable ABI, bindings to more OS-specific services (such as Mac and Windows GUI systems), and even things like smaller compiled executables would probably make Haskell more attractive in production environments. | I'd like Haskell runs on Android. | To make a strained analogy, four years ago I felt I got on a train that would be going somewhere. It hasn't. Haskell is a fantastic tool, but the steepness of the learning curve hasn't changed, and I'm tired of evangelizing something that my coworkers aren't ever going to adopt. I'm evaluating go now as a language that can be evangelized with some hope of traction with the masses. I think you're going to see more of this...fatigue. I don't think anyone presumes haskell will take over the world, but it really hasn't made much of a dent at all in industry from what I can tell. I wonder how long the enthusiasm can keep people interested. Also, I really think many of the shootout submissions should be rewritten in a more idiomatic style. Haskell is promoted as a high-performance tool, but when it comes to benchmarks, we produce entrants that are not at all what we would consider idiomatic. I would rather see haskell move down the rankings with more honest, idiomatic submissions. Sorry for focusing on the shootout so much, but lets be honest, a lot of people look at that site. | I think that trade-off between space leak and avoding GHC's optimization by strict anotaton is the most weakness of Haskell. We can slove this problem if strictness ananlysis can find strictness in optimization phase, but strictness anlalysis isn't perfect currently. So, this is serious problem now.... | Lack of serious competition to GHC among Haskell compilers. | In order to grow this community, Haskell needs a more welcoming documentation culture. The API documentation tools (i.e. haddock) are excellent and it's perhaps because of this that few library authors write truly helpful discursive documentation. There's a big gap between Real World Haskell/Learn You a Haskell and actually using libraries on Hackage to do useful things. If every library author viewed their project as a platform for teaching a bit of Haskell to relative newcomers, the barrier to entry would be lowered considerably. | |||||||
15 | Authors assume too much knowledge, omitting explanations they think are trivial or redundant. | better type inference in vim would be awesome. I often find myself adding type annotations just to check the type of something. | I'd love for Haskell to become mainstream. Perhaps a good web development framework would provide the necessary impetus .... Following is subjective - 1. I could not get Hapstack to run ... so I dont like it 2. Snap ran out of the box but seemed to require libraries not present in Haskell platform .. I'd like it much more if it worked with things available in Haskell platform or perhaps things used by Snap becomes part of haskell platform | The community seems to largely believe that laziness is a weakness, when in fact it is very substantially important to getting both good performance and good compositionality. | Combinatory syntax (programs sequence of identifiers) Layout-based syntax as preferred format (terrible!) No inductive datatypes (without GHC.Prim) and thus no support for inductive reasoning Too implicit syntax, little semantic information in program fragments due to massive overloading (type classes). Bewilderingly many generic programming and type-level programming extensions, but few high-performance base libraries supporting associative access Too complex type inference (for programs requiring higher-ranked types) Documentation organized by overloading (by classes) rather than constructor/observer/destructor (by types) Lazy evaluation (no asymptotic cost model, leads to double indirection due to lazy evaluation and boxed data types, which, together with garbage collection, makes time and space performance particularly incomprehensible; plus complicates parallel implementation) | Competing and incomplete libraries. | Lack of interoperability between different packages on hackage - uptrading packages via cabal quite often leaves the package database in an inconsistent state where the only comprehensible option is to reinstall everything. | Lack of a serious idiomatic cross-platform GUI standard | If the goal is for Haskell to be more widely adopted, I think a number of integration details are important. Things like a stable ABI, bindings to more OS-specific services (such as Mac and Windows GUI systems), and even things like smaller compiled executables would probably make Haskell more attractive in production environments. | We have no general purpose CAS in Haskell | Impredictable memory and CPU performance because of lazy evaluation. | Narrowness of platform. GHC is the only real implementation; it seems mostly to target x86, many libraries depend on its non-standard language extensions, too many libraries only compile and work properly on Linux, etc. Contrast with the success of Python, Ruby, and Javascript in being implemented repeatedly by different groups targeting different platforms - I think this is important for a language's accessibility to industry, especially nowadays with so many popular cross-platform choices. On the other hand, ease of implementation does not seem to have done much for Scheme... | Lack of documentation. You need a lot of studying on new concepts in order to get trivial stuff done. | ||||||||
16 | Availability of instruction to go from beginner to intermediate | debugging | I'm not sure where the community is going. Will anyone pay me to write in Haskell unless I get a PhD? | Default methods for superclasses, class synonyms and everything else that keeps us from having, among other things, a sane Num library. Then, of course, the big HList elephant. It gives much needed expressivity and generalisation to everything having to do with records, and having appropriate type-level programming capabilities to write an easy to use and extend HList library would be awesome. The current state is almost as bad as C++ templates. | dependencies hell | Libraries are on Hackage instead of Git, but Hackage doesn't provide any insight into whether a library is active and widely used. You can't easily see which lib the community seems to think is best. You can't easily just start browsing the code either. Hackage is touted as a great feature of Haskell, but for a newcomer it's actually a glaring weakness. | Lack of GUI tools - both ways to write GUI's (wxHaskell and GTK are not as good as WPF/Winforms, and don't install nicely), plus no good GUI's for things like profiling (which I suspect is a reflection of the lack of ease of writing GUI's) | Lack of a portable compiler. | Most libraries are not ready for production use because they a) are incomplete (wrt. to conformance to specifications like XML / XML InfoSet) b) have inacceptable performance for non-toy use (i.e. use strings, too many allocations, etc) c) too often change APIs or don't have a stable maintained version along with an unstable development version GHC is great but there are times where there's no known "bug-free" stable version. Often bug fixes are not ported to the current stable version if the next version is already in sight. Advanced use (retainer profiling) sometimes crashes GHC. It's still much harder to track down space leaks than it is with Java/Scala or Objective-C Tools (Instruments). Lazyness makes unstanding what's going on difficult and the tools don't compensate for that, yet. Haskell is a beautiful language, but we wouldn't use it again for a really big, scalable server component because the cost/benefit ratio isn't as good as Scalas, yet. | In my paid work with Haskell, I've found that most of my work is around not being able to reason about performance. That, however, may be because of lack of experience and knowledge of the language. | Sticking with the "old" Prelude. | Lack of documentation/best practices around deployment of server-side Haskell applications. | |||||||||
17 | Better and simpler introduction material to advanced usages of Haskell and libraries. E.g., functional reactive programming. | Debugging | Lack of a strong community that is actively engaged in building real world applications. | Exceptions outside exception monads (i.e., no way to statically know from the type that a function is exception free). | Dependency hell. | New version/generation of Hackage is desperately needed. | lack of universal gui toolkit | My stuff builds ok on Linux (so others tell me) but I have yet to get it to build on MAX OS X (Snow Leopard) - fixing all of this would be very nice. | It is very hard to reason about performance and memory consumption. | Lack of examples, documentation assuming domain expertise | |||||||||||
18 | Difficulty of learning. The whole monad thing. | Debugging lazy code | Lack of backing in time and resources to take the language and turn it into a professional grade platform. The community has put in an incredible amount of effort, and it shows. But it just doesn't have anywhere near the polish of commercially backed platforms such as Java or C++. This is very disappointing since the language itself and a lot of the libraries on Hackage are so incredible. | Extensible records would be nice. | Dependency management in cabal - I got myself into such a tangle with some packages depending on different versions of other packages that I ended up giving up and reinstalling the whole platform. | Poor integration/collaboration on Hackage, with too many developers doing their own thing in their own way, making it frustrating for users to evaluate and choose between them. A failed cabal update/install from Hackage should not break your entire system! Resolving resultant lib conflicts can be messy and this alone would make me reluctant to suggest Haskell for a production environment. No version of a package should be allowed on Hackage without clearly indicating which versions of which dependencies are required The existing <lib>.cabal dependency specs do not go far enough: libs unreasonably force a single dependency version (or narrow range) when a range (or wider range) would do and the user should not need to manually patch & recompile every lib. Hackage has a lot of old/deprecated/apparently-unmaintained dependencies. There is a real need for some dependency version resolution between compiler, cabal and Hackage (a la aptitude on Debian). Ideally, Hackage uploads should be rejected if they do not correctly specify the widest possible dependency versions, or conform to official broad release timestamps. Hackage needs some kind of overall stewardship and review/feedback from users. Every kid doing their own thing in their own way is far too incoherent for real world use, and there is far to much partial overlap, and it's rapidly getting worse. Projects should declare their intentions, methodology/approach, relationship to existing Hackage projects, scope for contributions, etc., and this should be reviewed, before even being allowed to upload. Obviously there are legacy issues and ease of involvement should certainly not be discouraged, but maybe Hackage projects could be flagged with quality status badges for compliance or something similar? Incidentally, the package categories on Hackage are useless and should be done away with. They only add to the clutter. And it's time to stop being proud of how many packages there are on Hackage - there are far too many overlapping packages! | More focus needed on getting real-world, end-user products done: - GUI binding need to be easier to setup and use | plus there was that whole issue with GHC not building dynamic libraries on Mac OS X 10.6 (Snow Leopard) for the longest time... I was trying to get Hubris (the Ruby - Haskell bridge) working on my Mac system for over a year.. it won't work without GHC building DLs properly.. i'm not even sure if that is fixed yet, hence, I don't spend too much time with Haskell anymore, even though I want to.. | Non uniform performance. | Library documentation. | |||||||||||
19 | Example apps. | development environment tools / infrastructure are a huge hole, | Lack of commercial support/investment | For me, I wish there was more "easy things should be easy" in Haskell. For simple tasks and glue, I always end up using Python though. After a year of spending 2-3x more time studying Haskell than Python, I still feel more productive in Python. | Finding packages, installing packages, and updating installed packages. Overall: cabal/cabal-install is not up to the challenge (yet) cabal-dev is a nice approach, but a bit intrusive and still borks in certain use cases | The lack of a quality measure mechanism for hackage. | more standarized tools/libraries set as part of platform. including GUI libraries (e.g. GTK) | The story on Windows remains poor for certain library domains. Many libraries turn out to be wrappers around or dependent on Unix functionalities. | Performance and memory footprint is very sensitive to tiny code changes. | Library documentation. | |||||||||||
20 | Explaining iteratee style code is an example of how t get potentialyl blank stares in response | difficulty of tracking down space leaks difficulty of tracking down exceptions | Marketing: appearance of immaturity in various commercial application domains. | Haskell is a completely untyped language from the point of resource management. (I admit other languages are also untyped but for lazy languages it is a bigger problem.) | Haskell Platform was a step in the right direction; still the most difficult task for me is often finding the correct library and getting it to build. | The state of Hackage. | needs to have a blessed ui library in the platform ! | While my experience with Haskell is limited, and my opinion should be therefore taken with a grain of salt, I think Haskell's biggest weakness right now is it's availability on Windows. On Linux, I am able to install GHC (or any other Haskell compiler) and have things work exactly as they should, right away (including cabal and library installation). On Windows, I need to install MinGW to simulate a Unix environment in order to get things working smoothly (need bash, gcc, autotools, etc), and MinGW by itself isn't enough, as many other libraries need to be obtained as well (GTK, SDL). It takes a lot longer to set up. Once it's working, it works great, but the initial setup can cost you a good hour or two of your time. Also, on Windows, it's difficult to update cabal packages. Considering that most developers in the world are Windows users, I'd say that integrating a Haskell implementation into the existing Windows toolchain should be top priority. | performance instability | Many libraries are not so obvious easy to use, that it can justify the lack of documentation. I often miss at minimum just one or 2 examples in extend to the API documentation... | |||||||||||
21 | For a begginner, the lack of a patterns/best practices catalog. I would suggest something like More C++ Idioms http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms. | First, I think the lack of an excellent ide keeps many programmers away. There should be an haskell equivalent of what Eclipse is for Java, and it should *work*. I use emacs haskell-mode, but it's rather primitive, even the command/function tab completion in the ghci inf-mode does not work! There are poor languages which are popular just because they have great development tools. Haskell is already a super language and better tools would really increase its popularity (imho). | Marketing. | Haskell utterly fails at programming in-the-large. It's "module" system doesn't scale. | Haskell should have prescribed libraries which are considered standard like boost | Too many unfinished academic projects get thrown on Hackage and quickly bitrot. | or languajes for to create a GUI with haskell | Working with foreign libraries on a non-unix system (microsoft windows) is a pain. The build system could definitely need some improvements in that area. | Reasing about space usage. | Many libraries don't have good/any docs. This may not be a problem for seasoned Haskell programmers, but for folks coming from other languages, many potential 'teachable' moments, via some projects docs, are missed. | |||||||||||
22 | hard start for novice, need to start to think "completely other way"... | For me it's harder to debug than C/C++, but also the kinds of mistakes I make are different. Therefore I don't know if that comparison is really fair; segfaults practically do not happen (except some times when using gtk2hs in very wrong ways), what remains are the logic errors which are harder to find anyway. However, I think that a good debugger that lets me step through a program /quickly and comfortably/ would be a great help. The interface that Leksah provides is a good start, I think... wish I were already better at Haskell so I could make a real contribution here, but I guess I still have too much to learn. All in all, after a year or so of learning Haskell in my (scarce) spare time, I still have to say it's the language with the nicest syntax and some of the coolest features I have seen so far in my computing career of about 25 years (if you also count C64 times ;) ). Keep going, Haskell, you're way cooler than most others! | No any real life big project (product) that would promote Haskell. | I would like to have a better record system. | I think that as many libraries that Haskell has it has not yet reached the point where it has one for everything. If you ask me we should setup dummy projects that people can complete and make them small in nature so that Universities and random hackers can come in and spend a few weeks making one of these projects and then we have the libraries we need. They should be rather small so that they can be considered to be in a 'completed' state but it has the potential to allow us to outsource all of the low hanging fruit in the community. Or simply the libraries that do not get made because nobody has the time. | Too much crap on Hackage. Some sort of popularity-contest (cf. Debian/Ubuntu) might help. | There still does not exist an obvious GUI solution for OS X, or an obvious audio solution that does not require the writing of a great deal of "boilerplate" code. | Working with foreign libraries on a non-unix system (microsoft windows) is a pain. The build system could definitely need some improvements in that area. | Reasoning about performance in a lazy evaluation regime, together with a lack of strict functions in common libraries and laziness/strictness documentation. | Missing or incomplete documentation for many packages, especially a lack of tutorials and examples. There are some packages where the advice is to infer the usage by reading one or more academic papers. For me (currently a Haskell hobbyist) this might be, at most, irritating. At work, and under time pressure, this would make the use of Haskell a non-starter. | |||||||||||
23 | Haskell community, support, documentation, tutorials are very much geared towards solving small problems (<one screen of code). Personally, I have often been frustrated when developping bigger software projects about - how to design a good structure - how to refactor - how to use good tool support - how to handle it when I find out that I need to pull IO monad through to a deeply nested pure function - how to reason about strictness and performance (i.e. how to get a writer monad with non-strict semantics so that it will give debug output on a non-terminating program) | For the people used to Visual Studio kind of environment. Setting an environment for doing serious development is very tedious. Please nobody give me that cr** that real programmers use text editors. Then every programmer should only program in assembly language. Dependable IDEs (to explore, develop, debug, package the code) are crucial for successful adoption. | No big, successful Open Source projects. Such a beast would need internationalisation, a GUI, good documentation, a decent build system etc and could then be the 'baseline' project with which others could compare themselves, like the Gimp was for Gnome, or maybe Rails was with Ruby. | I/O code, while logically consistent, feels like a massive hack, with numerous oddball limitations. | I think the problem is the pendence the other libraries | User Interface. GTK is sadly out of date, hard to build on Macs. Other contenders are just as bad. So bad, it is making me think of using native tools (e.g., Objective C - and just having the Haskell program run as a server with a socket for connecting and sending events back and forth). | libraries too platform dependent, | Reasoning about performance, finding memory leaks | Most haskell libraries provide adequate reference documentation but most would really benefit for additional use case example documentation. | ||||||||||||
24 | Height of the learning curve. To write useful code, many concepts must be understood (laziness, functional programming, declarative vs imperative code, monads, monad transformers, applicative functors) which takes a lot of time. This makes writing Haskell code at work hard, since nobody will be able to understand it. Avoid success at all costs though, right? We wouldn't want a comunity like the Ruby one. | Good development tools. Our tools are only about-as-good as those offered for other opensource languages. GHC knows so much about your code, it seems like it'd be prudent to make use of some of this additional semantic information in an editing environment. | None of my fellow-students knows it, so we can't use it for toy projects. | In theoretical terms, the greatest weakness, IMHO, is that types and kinds are not first class objects. There should be no second class objects. There would be no need for many of the recent and ongoing research-driven extensions to GHC if this one simple issue could simply be addressed. For this reason alone, Lisp will always be more powerful and expressive and less awkward. Less crucially, a means to unify bindings at compile time would add to the expressiveness (alleviate the sense of semantic constraint) of the language. | I would like to see library base as rich as pythons one. | We need more depth in GUI and database libraries. | Space leaks are too easy to introduce and too hard to identify. | Need better documentation over theoric aspects that are all over haskell | |||||||||||||
25 | Highly-academic background, learning concepts such as Monads, Arrows do take lots of efforts. It force you to grok the whole language than just pieces of it. BUT nothing/no time's wasted on my way learning Haskell. Really. tl;dr: I love Haskell. | Haskell as a language is very good. Maybe the lack of a solid IDE (since unfortunately Leksah still isn't there), but that doesn't bite me often. | Not enough people working to bring outsiders in. With a larger community, many problems could be solved. | IO (Iteratee/enumerator too complicated, Lazy IO too imprecise) | I'm fairly new, so I couldn't really judge the Haskell libraries in the topics questioned (voted all 3s). Possibly there should be more, bigger libraries rather than lots of little ones. A big library. Too many small libraries might make haskell suffer from the lisp curse. | Space leaks due to laziness can be exceedingly hard to find. Adding a random seq/deepSeq fixes the issues for no reason i can fathom (-: | The Documentation of Libs. Similiar to the lisp curse, it is often easier to write a useful library in Haskell than to document and introduce it properly. Figuring out how a library works - or even how to just use it, often means interpreting the names of functions and their type signatures - which is tedious. | ||||||||||||||
26 | I am a newbie to Haskell (started just about a week back). I am a Ruby programmer by profession and I have been learning Clojure for the past few months. Clojure, even though being a relatively extremely new language has a lot of entry level books and then there is Joy of Clojure, which explains a lot of stuff about the language and truly excellent clojure videos. For haskell, there is Learn You a Haskell, which is a fantastic/fun book. But other than that there doesn't seem to be much choice. | I would like to have a better IDE. I tried leksah lately but I was not good enough (too buggy) to replace SubEthaEdit + Terminal. I have no time to participate in leksah at the moment. It is on my "When I finally have enough time and money, I will do"-List. | Not enough users. | it has no ML-style modules and functors | I've had problems with borking my packages when installing a new one. New req gets pulled in and causes global/user level dependency problems. If I didn't already know how to fix it, there's a good chance I'd give up. | Space leaks/how often we have to deal with them, and how difficult it can be to figure out where they are in large applications. | The lack of examples within the various library documentations. It's a bit daunting for a newcomer to search around for a while to find a reasonably simple example on how to use a certain library. While API docs are awesome, when one's not that experienced in Haskell yet, they're not enough yet. | ||||||||||||||
27 | I'm not a mathematician. I'm an engineer. My math doesn't extend to the theory that seems to crop up in most of what's written about Haskell. | I'd love to see some debugging (~step by step evaluation/run tracing) support. | Not used in pratice, good additional tools | it is becoming too bloated and complex, to the extend that there will never be a second-source compiler which rules out Haskell for serious projects | If you pick a random one-year-old library on Hackage, I don't think it will have even a 30% chance of building in the most recent GHC without source modifications. That's just wrong. | Speed (or at least, ease of finding out why a program is slow) | The lack of good library documentation. By good documentation I mean neat description of functionality with illustrative examples. For example, Qt documentation is good. | ||||||||||||||
28 | I'm not experienced, I'm only studying Haskell. In my case the language has taken a while to get a grasp on. I'm used to imperative programming, and Haskell is very different. | I'm missing a debugintool. | Probably that it's seen as very academic and not much use in the real world, and although there's some discussion about it in more 'ordinary' terms, people still tend to find the academic stuff first. I'm not saying that should stop, but that we need more talk in the style of "Real World Haskell" to show people what a good language it is. | Lack of dependent types / lack of compile-time checks of assertions and invariants | It is difficult to promote Haskell. Many libraries are experimental. | The difficulty of reasoning about time and space usage. | There aren't enough cookbook solutions available, it's mostly individual bits that you can put together. Let me make this concrete by giving an example. If I want to start working on a PHP project, I grab Zend Framework or Symfony and use the generator to kickstart a project, and choose the components I need from a rich set of (well integrated) libraries/components. Everything I need is provided by the framework, including the documentation which describes in detail how to lay out my application and how to use each individual component (possibly in combination with other components). With Haskell I find myself scanning for libraries on Hackage and hoping that the library I picked works sufficiently well. (granted, in most cases it does, unlike PHP libraries). The quality of the documentation on how to use the individual libraries varies greatly. Documentation on how to integrate individual libraries with frameworks is generally non-existent. Strong documentation that is easily accessible (or the lack thereof) is probably the most glaring weakness for Haskell. | ||||||||||||||
29 | I've just started learning Haskell a week or two ago, so I'm not that qualified to comment on the state of Haskell, but I can comment on what it's been like to start learning Haskell. * The community is very nice. A definite plus. * Every tutorial I've seen takes forever to get to IO and, honestly, to do anything useful with a program you kind of need IO. It would be nice if people realized this. * Haskell-ers have a tendency to talk in some kind of crazy pseudo-academic language, which can be very confusing for someone not familiar with the terminology. * The error messages produced by GHC are not very helpful for a newcomer. I never understand what it is trying to tell me. * It would be cool if the Haskell community had a webpage featuring prominent Haskell projects, like xmonad. I'd be interested in finding more programs written in Haskell and using them. | IDE should exploit the type system: refactorings, code completion, navigation, etc. | Public Awareness and Public Relations | Lack of dependent types. | It needs a port of some of the main statistical and econometric functions of R. | The fact that reasoning about the runtime behavior (especially space usage) is hard, because of lazyness. | To me, it's primarily about idioms and documentation. It's very, very hard to write beautiful and fast Haskell, not in the least because of the string situation. When introduced to Haskell, learning that String is just [Char] is very cool. Finding out that you can't really use it for anything because it's so slow is painful. A lot of libraries seem to rely on only having "reference" documentation, that is an index of every function. This is not enough: More documentation should be written geared towards use of the library. Index and reference is good for hacking the library or doing weird stuff, but when developing, I just want to grab the library and start using it in the way the developer intended. | ||||||||||||||
30 | Initial hurdle to learn and appreciate concepts such as Monads | IDE, Ecosystem, because of these it is impossible to program "in large". | Still largely rooted in the world of academia so it's difficult to find examples of 'real world' projects going on. Judging by the amount of "I've been learning haskell for a while now I want to create something but I don't know where to start" posts on Stack Overflow and Reddit, it's evident that the Haskell community needs to bridge that gap | Lack of good language-level tools for controlling laziness. Every time you define an arbitrary operator (like :<!>$| ), ghc should delete a random system file. | It's not very convenient to use for numerical code. HMatrix is good, but it's not good enough to compete with e.g. Octave on its own. One thing I'd _love_ to see is a typeclass analogous to Common Lisp's "Grid-Structured Data" package, which provides a uniform interface to a number of array backends. I'd love to be able to write algorithms and then use them with either Data.Packed.Matrix or Data.Array.Repa. Also nice would be an AD package that doesn't require instances of Traversable: I'd rather overload matrix arithmetic for AD using BLAS operations. It'd be much faster. Finally, plotting is a bit of a weak point. Python has matplotlib, which is quite attractive. | The last x % missing in optimization. An example is simd (isse). | whenever I use a new library its hard to find examples of how to use them. it took me a long time to figure out how to represent state. | ||||||||||||||
31 | Lack of video tutorials. | IDEs, I constantly use Hoogle, compared to VS/XCode/Netbeans it just takes more time without proper autocompletion. On the other hand I find it hard to imagine autocompletion in Haskell | That it's not widely used in commercial environments -- if your not into academia (or at least have a Ph.D.) it's practically impossible to work with Haskell fulltime. Also, commercial use usually leads to a richer ecosystem (ie. more problems solved already and available as libraries). | Lack of parameterized modules | It's probably wishful thinking, but I really wish the prelude and core libraries could be overhauled to fix a number of well-known warts, add commonly used functions, and generally make things more consistent. | Time/space analysis. | It is very difficult to get up to speed on what libraries to use and when to use them. Also a cookbook of design patterns would be great to help people transition from the OO world. Kind of just a mapping of this is what you do in OO and now this is how you have to think about it. | ||||||||||||||
32 | learning curve limited the target users | It's quite hard to debug haskell programs, even if you need to debug way less, mainly thanks to the typing system. | That more people don't use it :) I have not used it long enough to hit performance errors; I _fear_ they will be tricky to find and fix (but have no personal experience to back that up.) | Lack of parameterized modules ala ML (even if it can be approximated). The import syntax/semantics could be improved to make namespace conflicts easier to avoid. | It's the wild west when it comes to package versioning. Even package maintainers who know about the PVP and are trying to follow it correctly are probably making mistakes. | Unpredictable performance & the fact that it is a black art to fix the performance. | Actually using a library, I don't always find it very easy to pick a random library and actually begin to test the capability of it without getting some outside examples. | ||||||||||||||
33 | Making it easy for beginners to get started / convincing programmers that Haskell is worth learning. | Lack of a decent IDE. Leksah is the closest yet, but if you compare Haskell to other languages with good commercial penetration, it's a glaring omission. The IDE should be cross-platform and offer a single integration point for all Haskell's development tools, which I hope will continue to improve. | The fact that it's seen as a reclusive 'academia-only' toy language scares people away. | Lack of stack traces (and to a lesser extent debugger, thread and heap dumps on OOM, etc) for compiled code. This makes figuring out where you've done something stupid or trying to diagnose a problem with code running in production harder than it should be. | Iteratees/Enumerators should become some kind of one standard library. | tricky to improve runtime performance (e.g Core optimisation etc.) | libraries: no documentation, no tutorials. | ||||||||||||||
34 | Misinformation from other developers | Lack of an extensive, high-quality toolsuite, including a debugger. | The lack of people who know it. | Lack of stack traces. | lack of "standard" libraries, endorsed and maintained by experts | Also, some libraries are poorly documented, so it can be hard to use them even if the libraries themselves are good. | |||||||||||||||
35 | Monads are still challanging, As well As parallel stuff with haskell. Gnosis true for beginners and non-fulltime haskellers | Lack of decent development tools (IDEs, debuggers, profilers). Cabal is not a package manager. | The reputation as an "academic" language you can't do "real world" development in is still out there and hurts adaption. | Lacking a way of interacting with the real world other than Monadic IO. | Lack of a good set of libraries for distributed systems (such as what Erlang has). There are quite a few introductory Haskell books, but there are fewer on advanced topics, and it is somewhat difficult for beginners (or even advanced users) to have a good idea of what order advanced techniques should be learned. | ||||||||||||||||
36 | non-Haskell programmers see Haskell as scary and hard | Lack of declarative debugging since Buddha is gone, difficulty of monad transformers, asymmetry between pure and impure code (switching between do notation and lets is sometimes really heinous), difficulty of profiling and of switching on strictness. | too many blogs/articles deal with highly theoretical and abstract FP concepts but omit it's real world use. that's of course not necessarily a bad thing...it just doesn't help at all to endorse the usage of haskell in the real world. I feel a little more attention from a broader audience would benefit haskell. take nodejs as an example: the community is vibrant and a LOT of really god libraries and applications emerge. thus growing haskell more intensively outside the realms of theoreticians might give a real boost for us as well... having said this I really think haskell has done a tremendous job...especially with people like dons and Brian and tibbe. thanks for helping to put life into this wonderful language! oliver mueller p.s. longest text I ever typed on my nexus one...no fun AT ALL :) | language weaknesses: * the (ghc) type system is getting rather baroque and not very well suited for some tasks (eg. deeply embedded DSLs, encoding mathematics) * strictness control is not precise enough * lack of parametrized modules | Lack of a semi-blessed superset of libraries living on top of the platform (think debian-testing) | ||||||||||||||||
37 | Not enough teaching material that _bridges_ day-to-day use with theoretical foundations of the Language. | Lack of execution tracing. | Very little materials about real world usage of Haskell - the community appears to be entirely an academic non-pragmatic group. | language: ugly, unsafe prelude. | Lack of adequate libraries for statistics and scientific programming. | ||||||||||||||||
38 | Perceived complexity | Lack of high-quality tools other than the compiler | Locale-specific input/output. | Lack of canonical, high-performance libraries for solving numerical and data structural problems. | |||||||||||||||||
39 | Perceptions of complexity. | Lack of IDE support. Although I'm not an IDE user, the features that languages with good IDE support have are comprehensive. | Module system, records, lack of mature Qt bindings (or QML) bindings. | lack of cohesion between libraries. | |||||||||||||||||
40 | The complexity of the monad type class. It's a very essential concept to Haskell, but it's not easy to understand. (Once you understand it, it's immensely useful, but getting there is hard.) | Lack of IDE. | monad stacks are annoying, | Lack of consensus on questions like string type or IO mechanism (lazy IO vs Iteratees; which Iteratee library...). | |||||||||||||||||
41 | The Haskell "way" of doing things is so different, it's a lot of effort to adapt. That said there's not really a way round it I don't think. Things like LYAH and RWH help too. | Lack of support for debugging compiled applications. | Monads are excellent for modeling architectural concerns, but it's difficult to use multiple monads in tandem (i.e. monad transformers). There's usually a lot of lifting involved. It'd be easier if the type system and do-syntax would handle a lot of it for you. For example, to combine Maybe and IO: something :: () with (Maybe, IO) something = do x <- failableIOOperation :: Int with (Maybe, IO) y <- inputOperation :: Char with IO -- The same as IO Char z <- maybeOperation :: Int with Maybe return (ord y + x + z) That would solve some issues, I think. I also think more powerful macro integration like Lisp would be useful and help with some syntax issues, like custom sugar. Expressions on their own lines being implicitly wrapped in parentheses would be nice. For example: map \x -> x * x [1, 2, 3] ++ [4, 5, 6] Would be the same as (map (\x -> x * x) ([1, 2, 3] ++ [4, 5, 6])). | Lack of consistency in library interfaces, especially with text types (Strings vs. Text vs. UTF-8 encoded bytestrings...) - this can make it hard to use different libraries together. | |||||||||||||||||
42 | The Haskell community is really great. There are certain gaps that intimidate or deter broader adoption. Tutorial versus high performance code. Advanced programmers spend seem to spend a lot of time adding strictness, unboxing, and looking at GHC.Core. Pretty scary for a newbie trained on tutorial style code. Type language, versus value language. Haskell is really two languages working together. One is the language of values, which is elegant. Then there is the type system, which is where all sorts of magic occurs in a "difficult" language. It's takes a while to learn what to ignore when learning Haskell. Most programmers should not be worrying too much about advanced type system issues, but they need to know a little. The boundaries are not clear. | Lack of understandable and usable debugging tools for sizeable programs. | Needs linear types to make working with stateful structures easier. No proof assistance. No ability to state proofs. | Lack of giant common libraries (e.g. python standard lib, .Net standard libraries, etc.) | |||||||||||||||||
43 | The term monad. I cannot deside whether it is only scary or also misleading. | My major concerns are with runtime analysis. I find it difficult to get the stack when the head of an empty list is requested or to infer by profiling which part of a program is retaining memory which should be freed. | No dependent types; | Lack of libraries. | |||||||||||||||||
44 | Too large of a knowledge gap between academicians and coders who don't know much about type theory (especially with regards to type system extensions in GHC). | Poor IDE support | No real module system. Even more and more complicated extensions. | Libraries for web services / soap | |||||||||||||||||
45 | Type errors can seem very opaque to beginners and beyond. "Inferred" versus "Expected" took me forever to grok. Minor gripe. | Reasoning about strictness is often difficult, but even finding simple problems like circular computations that trigger <<loop>> exceptions in the runtime system and similar exceptions are hard to trace to a particular source. +RTS -xc -RTS helps, but is often not very precise. Debugging tools to make this easier would be the most useful improvement for me (or a more robust GHCi that won't choke on unusual projects). | No syntax for easy matrix manipulation | Libraries have extremely complicated dependencies, and it's often hard to figure out which versions of which libraries can be built and used together. Cabal-install can do it pretty well, of course, but I prefer libraries to be installed by the system's package manager, because I don't want to worry about all kinds of different mechanisms. I've spent almost a year trying to support Haskell packages an ArchLinux, for example, and it's been a challenging task. Generally speaking, distro support for Haskell seems to be not particularly great. Also, many libraries work great for smallish example projects, but their performance is not very good when they're given serious amount of data. | |||||||||||||||||
46 | While the community is very friendly and open, nephoytes (and no so novices) can be intimidated by advanced-level articles. Learning curve rather abrupt (a reason for that being we need to unlearn so many things before diving into a lazy pure functional language) | some kick-ass IDE would help.. in ruby i dont want/need such, but with haskell's hardcore typing tradition i think it would suit really well. | None, in the sense that I am extremely happy with Haskell as it is. Of course, there are things that could be improved, like record types and the module system, but it's more of a wish list than an problem to rage about. | Libraries tend to become needlessly complex for easy tasks when more and more abstractions and generalizations are dragged in. (Haskell makes it a joy to do such stuff.) | |||||||||||||||||
47 | The lack of a way to analyze code to see where laziness is hurting your performance or memory usage, or a thorough explanationof how to coax good perf/mem usage out of lazy code. There are a few blog posts, and some Haskell books devote a small section to light coverage ofthe matter, but there is no thorough and/or go-to source for help other than asking around. | Record syntax is awkward. | Libraries, package managers (cabal) and compilers do not always move together. So it is a risk to move to a newer version. Often this breaks dependency. | ||||||||||||||||||
48 | The lack of proper IDE support in Eclipse, the in my opinion best IDE out there. I want to be able to browse and find documentation, types, functions, etc. quickly, I want automatic import management (some shortcut for the editor to sort the imports and import only the ones used (if so configured) in a clever way. | Record syntax. | Library dependency hell and bitrot. | ||||||||||||||||||
49 | The lack of REALLY good ide's and refactoring tools. Integration between libraries could be better also. And standardization of libraries. There should for example preferably only exist one good and blessed iteratee- library so that it could start getting serious use across libraries. The same is true for parser combinators etc. I think its getting better though | Some fossilised mistakes in the Prelude, most particularly the inappropriate grouping together of unrelated concepts in the numeric type classes. | Library management. | ||||||||||||||||||
50 | Understanding run-time characteristics, diagnosing space leaks--esp concurrent/multicore. | Some of the cruft from ancient history, such as Monad not being a subclass of Pointed, Monad having “fail” and pure Prelude functions using exceptions would be nice to get fixed. Not that any of that is really a problem, just a wart. It would be nice to have a sufficiently powerful macro/metaprogramming system that is considerably nicer than TH (to the programmer who has to implement the generation of the AST). (Haskell is also missing PHP’s excellent Magic Quotes functionality.) | Library Maturity. There are lot (an lots, and lots) of vague experimental libraries with partial functionality. The community need to push some of them to maturity. In particular there is need for a solid graphics library and a solid GUI library. I will know a library is mature when I can build and manipulate reliant data structures then then pass just once into the IO monad for execution. | ||||||||||||||||||
51 | stack traces scattered documentation (wiki.haskell.org) can use some reorganization. missing learning documentation on advanced topics like type families, etc.. | Library versioning is still an unsolved problem. There also seems to be a segment of the community oushing to make Haskell programming ever more inaccessible and complex, and we're lacking strong advocates for simplicity, approachability, ad other related goals. | |||||||||||||||||||
52 | Still hard to get a simple stack trace. I still get a sinking feeling when my program crashes with "Prelude.head: empty list" I know how to coax GHC to tell me where the crash is, but a stack trace on exception should be the default, like Python or Java. | Many libraries serve to demonstrate abstract concepts or solve "hard" problems. Practical libraries like web kits and those allowing easy DB access are appearing more, though. | |||||||||||||||||||
53 | Strictness / boxiness polymorphism. I can't instantiate, say, IntMap to have strict values; I need to use a different set of API calls or have a value-strict and non-value-strict implementation of the API. Add to that the fact that different libraries make different decisions (strict API calls vs strict version of structure) and that strict API coverage is often sloppy and incomplete (eg support for strict unionWith) and it's just a mess. Containers is easy to single out here, because it's ubiquitous and I understand it well, but this is a common problem. | More focus needed on getting real-world, end-user products done: - one blessed XML library is needed | |||||||||||||||||||
54 | support for paradigms other than functional programming | more standarized tools/libraries set as part of platform. including GUI libraries (e.g. GTK) | |||||||||||||||||||
55 | syntactically awkward records | Most libraries are not ready for production use because they a) are incomplete (wrt. to conformance to specifications like XML / XML InfoSet) b) have inacceptable performance for non-toy use (i.e. use strings, too many allocations, etc) c) too often change APIs or don't have a stable maintained version along with an unstable development version | |||||||||||||||||||
56 | That the language has no execution model (it has an evaluation model, which is not the same). It is impossible from what I can tell (not "difficult" but literally impossible) to reason about program performance based on just the language spec. Even lazy evaluation (i.e. by graph reduction) is implementation specific. Strictness, function totality, etc. should be tracked by the type system. Runtime debugging (especially of thunk leaks) is way too hard, SML is an older and cruder language but seems to have take a more serious approach to specifying semantics, so I want to learn it sometime. | Need polish enterprise libraries in areas: rdbms access, web-frameworks, GUI to more wide adoption in enterprise-programing. | |||||||||||||||||||
57 | The biggest weaknesses within the language are those relating to instances (orphaned instances, overlapping instances, etc.). | Needs libraries to compete with python. | |||||||||||||||||||
58 | the class/module system!!!! what a bloody mess! | One of the most painful things I've found is interoperating between the different string/text libraries. Between String, ByteString (lazy/strict) and Text (lazy/strict), gluing together libraries that use different representations is a tedious task. | |||||||||||||||||||
59 | The flux in base infrastructure libs, e.g. ByteString/Text/String, Enumerator/Iteratee, mtl/transformers | Packaging system doesn't allow binaries to use a library that is part of the package. | |||||||||||||||||||
60 | The lack of whitebox inheritance (e.g. the inability to supply a default definition of fmap from Monad without making every implementor of Monad pay for it explicitly) causes Haskell to favor a few good abstractions over a deep accurate class hierarchy. This has led to a large number of compromises in places like the numerical tower, Functor not being a superclass of Monad, etc. that please nobody. | Poor library quality, even for day-to-day tasks. Eg: the HTTP library. One major problem: library designers often think type classes are Haskell's only way of abstraction. Excessive use of type classes unnecessarily complicates libraries. Eg: the MongoDB package. | |||||||||||||||||||
61 | The language still has a long way to go to find acceptance with a larger audience. To be really productive with the language you need to have a good understanding of concepts that are (too?) difficult to grasp for the masses. I envision that in the future even users that have not understood functional programming and monads still can learn to assemble monad stacks to create an environment with the required capabilities and just continue to program imperatively, but then in a more controlled fashion. In short: Haskell researchers still need to find a good abstraction from the language. Monads and monad transformers are a good start but currently still far from the ideal solution. | Problem №1 for me is lack of real-life 'enterprise like' usages, libraries and so on... I don't want to see Yet Another Monad Tutorial ) | |||||||||||||||||||
62 | The module and record systems are very basic; especially, it's impossible to hide class instances (without hiding the class itself) or choose among different ones. | Since I would like to use Haskell for scientific computing, I have to say that I would like to see some more effort put into this area. I think Haskell could excel at it, but many libraries and some performance are missing. (See NumPy and SciPy, and Matlab.) | |||||||||||||||||||
63 | The module system is a bit weak. | Some sort of standard toolset/libraryset seems to be missing from my point of view. E.g. a Testsuite with easy integration into cabal, a standard library for better record types... But maybe it is just hard to find out, what the best library/tool would be | |||||||||||||||||||
64 | The module system. It is not representative of the abstraction power of the rest of the language -- I have on numerous occasions reached for Agda's module system (only to lament Haskell didn't have it and I'm not smart enough to program in Agda). | Standard library is weak (overuse of strings/lists, poor System.Random etc). Compare to Python's "batteries included". | |||||||||||||||||||
65 | The type system is the biggest strength compare to other languages, because it imposes a discipline that creates almost bug-free implementations. But it is also the biggest weakness, because it enforces odd compromises. Besides, the mix of type classes with types is awkward and unnatural. | still need more libs- although getting better at using FFI where appropriate | |||||||||||||||||||
66 | The way _|_ is reported can make tracking down calls to Prelude.head on the empty list problematic, especially if these calls end up being in a library that you didn't write. Not that I'm asking for one, but because you can't get a stack trace, it's very difficult to find where exceptions are coming from sometimes. High level exceptions are often descriptive enough to track down the issue, but low level stuff like calling Prelude.head on the empty list can be nightmarish to track down. The type system prevents a great deal of runtime errors, but if you slip through a crack the runtime tools for debugging are not great. Ideally we could prevent low level issues at compile time. Hopefully I feel this way because I haven't discovered the way to debug these kinds of errors yet! | The "stability" level of all the Haskell libraries is "experimental". Even libraries as fundamental as Data.Bool are marked "experimental", so it is impossible to tell which libraries are properly supported and tested and which are just toys. | |||||||||||||||||||
67 | the weak record system which is caused by the lack of type directed name resolution | The biggest weaknesses in the community as a whole relate to library support (particularly coverage). | |||||||||||||||||||
68 | There are too many feature in this language. One will never be sure when he/she be able to read others code fluently. | The fragmentation of Hackage libraries, wherein you need to depend on a large amount of packages in order to obtain relatively common functionality. This is not an immediate problem, as cabal has excellent dependency tracking, but gives me doubts as to the longevity of my code. | |||||||||||||||||||
69 | Too focused on methematical concepts. No way to hide (typedef) big type definitions. | The hackage package overview is not very helpful. Something more CPAN-like (and library names that reflect what the library is doing, including proper namespaces) would be great. | |||||||||||||||||||
70 | Very unintuitive syntax - monad operators, backticks, etc. | The hs platform is an excellent thing however the process is too slow overall. For example theres no process to deprecate current libs in favor of better one. (http vs http-enumerator, binary vs cereal, etc. you might disagree with my listed choices, however i think i m still right about the lack of process.), also adding libs is really hard (text for example) and it's done very rarely (no other proposal despite lots of good libs since text)... Its wouldnt be too bad if the quality of package on hackage was less "random", but at the moment the only thing trusted is the platform. | |||||||||||||||||||
71 | The lack of a broader standard library. | ||||||||||||||||||||
72 | The lack of libraries. I'm coming from a Perl background and Hackage has a long way to go before it obtains the breadth and depth of CPAN. I ofter fall back to Perl for various tasks because I can't find a library on Hackage. | ||||||||||||||||||||
73 | The package/build-management system should be on par with Apache Maven, and the large numbers of libraries that duplicate functionality need to be curated to point out the best choices. | ||||||||||||||||||||
74 | The quality of 3rd party libraries. Evolving hackage seems to be a good solution to the problem. Integrating testing reports, establishing a process to adopt orphan libraries and such may help improving this. | ||||||||||||||||||||
75 | There are a million array libraries and they all suck. I would like to see a standard array type built it into GHC with full polymorphism (like DPH). | ||||||||||||||||||||
76 | There are too few libraries defining interfaces that can be implemented by other libraries, à la Data.Foldable and Data.Traversable. Better modularity should also be built into the language, allowing ranges and list comprehensions for any monad, string literals for any string type, and so on. As it is now, it's too difficult to get modules to work with each other, without resorting to overly generic and inefficient solutions such as arrows, functors, ... | ||||||||||||||||||||
77 | There should be built-in support for handling large chunks of binary data, or (if it is there) it should be better documented. | ||||||||||||||||||||
78 | There's now a useful core of Haskell libraries that fit together fairly well, which is great. However, out on the frontier of iteratees, restricted monads, etc. more polish and integration with this core is required. | ||||||||||||||||||||
79 | Too many libraries that were some kid's thesis that half work and were since abandoned. | ||||||||||||||||||||
80 | Too many similar libraries | ||||||||||||||||||||
81 | too many string libraries | ||||||||||||||||||||
82 | Too mnay libraries, which are not all well documented and difficiult to compare. versioning problems. | ||||||||||||||||||||
83 | We generally don't know what to expect from a library from hackage, may it be about API stability, performances, etc, except for the "well known" libraries. | ||||||||||||||||||||
84 | |||||||||||||||||||||
85 | |||||||||||||||||||||
86 | |||||||||||||||||||||
87 | |||||||||||||||||||||
88 | |||||||||||||||||||||
89 | |||||||||||||||||||||
90 | |||||||||||||||||||||
91 | |||||||||||||||||||||
92 | |||||||||||||||||||||
93 | |||||||||||||||||||||
94 | |||||||||||||||||||||
95 | |||||||||||||||||||||
96 | |||||||||||||||||||||
97 | |||||||||||||||||||||
98 | |||||||||||||||||||||
99 | |||||||||||||||||||||
100 |