U MENA HASKAL!

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.

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"

Talk about lazy!

>>40
So someone went and did it!

>>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.

Neat-o. I cannot see ever using it, but I'll keep in saved.

>>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?

Haskell can't do mutable arrays right:

http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/

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