Founded by Microsoft Corporation alumni Aaron Contorer, FP Complete is dedicated to bringing the Haskell programming language into the mainstream software market by being the leading developer of commercial Haskell software tools and services. Haskell is the new way to make software that accelerates time to market, boosts programmer productivity, lowers cost, and increases product quality. It changes the economics of software development and delivers the competitive advantage that enterprises need in a global software-driven economy.
After successfully launching the first web-based IDE for Haskell, FP Haskell Center, FP Complete has begun implementing software development tools for target industries like quantitative financial analysis, biopharmaceutical research and consumer Big Data. With the announcement of the Integrated Analysis Platform (IAP), FP complete has introduced a powerful, fully integrated, end-to-end solution that enables analysts to perform model explorations, build prototype models which turn into production code, and directly integrate them into existing production systems in one seamless development environment.
FP Complete is addressing the fact that software projects today suffer unacceptably high rates of failure, delays, cost overruns, and inconsistent quality because the imperative languages and tools in use today all suffer from one fundamental problem: their approach is inherently complex, manual, error prone and unscalable. Errors are compounded as you add people and code to the project over time. That’s why up to 50% of a software project’s cost is wasted on the test-debug-rework-maintenance cycle. You can’t solve these problems by throwing money and bodies at them. You need to solve the problem fundamentally and Haskell is the solution.
Haskell was created by advanced academic researchers over 20 years ago and has since then been sustained and enhanced by an enthusiastic and dedicated open-source community around the world. FP Complete was started in 2012 with the help of some of the leaders of the community and is committed to continue working with the entire community to advance the technology and expand Haskell adoption in the commercial market.
>>11 That Lisp comparison is silly. delay/force-induced messiness is a problem in Scheme, but not in Haskell, the language where knowing the intricacies of evaluation is necessary for any non-trivial program?
Name:
Anonymous2014-04-30 2:47
>>10 A hammer is purely a hammer, doesn't mean I can't tape it to my foot and call it shoe.
>>8 Everyone who does Common Lisp knows how imperative as fuck it is. Scheme is functional but not purely functional, though it does encourage functional style more than Common Lisp. The original functional language is ironically not functional.
Haskell is pure in the sense that effectful computations happen at the type level, that's what people mean by ``IO only happens inside of the IO monad'': you can't get side effect outside of the type IO a[1] _____________________________ [1]: which is actually also a lie, because unsafePerformIO :: IO a -> a
Name:
Anonymous2014-04-30 15:14
>>15 Exceptions do not contradict purity, actually. If a function throws an exception every time it gets called with some fixed argument, then it's pure because its behavior is defined purely by that argument.
exceptions like the one I listed does, think of calling the same function 2 times with the same arguments bbut the second time you have allocated all the memory of your system
Name:
Anonymous2014-04-30 16:36
>>21 Well what did you expect, a magical infinite memory?
main = Control.Exception.catch (error "kaboom") (\ (Foo f) -> f ())
Result:
temp.hs: internal error: stg_ap_v_ret (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>>28 TH is still pure though, save for that one function to generate a Q value from an IO value which I don't remember the name and have never needed to use. Everything else is indeed impure, but how come non-termination being impure?
>>32 I thought they had at least gensyms. Puzzled I was when a name generated with the newName function evaluated to a different value with each consequent use in a supposedly pure environment. Had to scrap it and use just fixed names with "__" shit tacked on.
Name:
Anonymous2014-05-08 13:16
Haskell is unusable for real programs unless you use non-declarative things like `seq` and ! everywhere.
I just wrote a haskell program to parse infix expressions, it takes almost two seconds to parse "a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|b&c"
>>39 How are they non-declarative? Both lazy and strict evaluations are necessary for real programs, so some strictess annotations are necessary in any language, whether it's strict by default or lazy by default. C# has explicit laziness, Idris has explicit laziness, Haskell has explicit strictness.
Name:
Anonymous2014-05-09 6:31
Neat-o. I cannot see ever using it, but I'll keep in saved.
Name:
Anonymous2014-05-09 7:08
>>39 So what you mean to say is that declarative languages as a whole are unusable for real programs? E.g. it's possible to represent a left fold of a collection as a thunk
(f a[n] (f a[n-1] (f ...)...)
but it's too inefficient for real-world data sizes. And the only way to break that is to use explicit strictess annotations but they break declarativity (e.g. it's been proven that the fusion laws don't hold in the presence of "seq"). Right?
In the current GC design, mutable arrays of pointers are always placed on the mutable list. The mutable list of generations which are not being collected are always traversed; thus, the number of pointer arrays corresponds to a linear overhead for minor GCs.
But most Haskell users seem to get by fine; mostly because Haskell encourages immutability, making it rare for one to need lots of mutable pointer arrays.
I.e. mutability is evil, just don't do it! Or be ashamed of yourself because ENTERPRISE HASKAL PROGRAMMERS GO IMMUTABLE