Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mastering Time-to-Market with Haskell

fpcomplete.com

Post reply on HN
Print view View original

41–50 of 120 posts

Re: Mastering Time-to-Market with Haskell

#41

Post by pron »

Tehnix wrote: post #19
pron wrote: post #2

> In summary we've seen that: Haskell decreases development time... Have we actually seen that or have you just asserted that? Is this really true, and if it is, by how much? Haskell has been around for a couple of decades now, and has had least two hype cycles (I remember that when I was in university in the late '90s, Haskell was the next big thing). It does not seem to expand significantly even within organization…

>Have we actually seen that or have you just asserted that I'd say they have probably seen it. The author of the post himself works at FPComplete, and they use Haskell for their consulting business. That and there are some case studies on their site (I'm fairly sure they all have experience in other languages too).

There aren't any case studies. Under the headline "case studies" they only have some marketing material.

Re: Mastering Time-to-Market with Haskell

#42

Post by cageface »

almata wrote: post #13

If you were a developer with 10 yoe looking for something new to get into, what would you choose at this moment and thinking about the near future: Haskell, Scala or F#?

I've always liked OCaml and with Facebook putting some real momentum behind it and the OCaml/JS story getting better and better all the time I'd say now is a good time to pick it up. It's more pragmatic than Haskell, simpler than Scala, and not tied to the .Net ecosystem like F#.

Re: Mastering Time-to-Market with Haskell

#43

Post by douche »

Every couple of months, I think to myself that I ought to buckle down and make an effort at really learning Haskell. And I go through some books and some toy projects, and then I hit the wall. The problem is, I can't actually use Haskell in anything production, because nobody else that I work with is going to be able to figure out how it works, and if I move on to some other job, my employer is never going to find somebody with Haskell experience in this area - at least for what they'd be willing to pay.

F# looks like a more pragmatic choice, and I've been looking hard for a good place to bite off to use it going forward. But again, it'll be bad for the bus factor.

So the best option I've found is to just start using more functional concepts and patterns in Java/C#. C# in particular seems to be leaning in this direction with the features added in the latest language versions.

Re: Mastering Time-to-Market with Haskell

#44

Post by willtim »

pron wrote: post #33
willtim wrote: post #18

Earlier quoted context omitted.

AFAIK, Credit Suisse only used Haskell for one particular project and that project came to a natural end. CS did end up adopting functional programming and F# became their strategic choice. I never claimed "orders of magnitude" productivity from a language alone. Haskell has every weakly-typed mainstream imperative language as a valid subset. You need good people, teams and processes to get the best out of the langua…

First, anecdotal case studies are much harder to dismiss than the nothing we have now, and as case studies accumulate they become harder and harder to dismiss. Also, dismissal is not the point. People and organizations are free to make their own considerations and choose their tools. I'm not talking about a marketing campaign. It's about information. If I don't have information, choosing Haskell would be far less rat…

> People and organizations are free to make their own considerations and choose their tools.

Not true. If enough FUD is spread about Haskell, for example it being a failure at CS, then it becomes difficult to convince management.

> If I don't have information, choosing Haskell would be far less rational than not choosing it

No one is suggesting choices be made blindly. Managers should hire good people and then delegate those decisions to those people. If they want to use Haskell, don't stop them due to lack of case studies.

> For the sake of argument, suppose Haskell has a 5% improvement in maintenance cost over Python but a 10% higher cost of adoption, then it's not worth it.

I don't subscribe to nineteenth-century management science. My point was that software development is more about people than technologies. You will never be able to compare Haskell and Python like that, without comparing the people behind the code. What we can say for sure, is that many good developers are asking to develop in Haskell. The best way for other developers to understand why, is to try it.

> That's great, but doesn't have much to do with Haskell.

You were implying that Haskell had failed somehow because SC had stopped using it. Decisions within large organisations are rarely made on purely technical grounds. I can assure you there are many Haskell advocates still there.

Re: Mastering Time-to-Market with Haskell

#45

Post by oblio »

cageface wrote: post #40
tmptmp wrote: post #12

Warning: be warned before you commit to Haskell. Not all is rosy about Haskell. You may find yourself in quagmire if you don't know for sure what you are going to get from Haskell, especially from the libraries. Although this is true for other languages also, the library support for Haskell is yet far from satisfactory as compared to the library support found for Python/Java. The Haskell community seems to have been…

You would think that a really rigorous language like Haskell would foster a better ecosystem of libraries than ad hoc languages like Python or JS but that has not been the case at all so far. I'm not sure exactly why but it's one of the main reasons I'm taking a wait and see attitude to Haskell.

> a really rigorous language

Is it rigorous in theory or in practice?

An academic veteran might want to better express his ideas in code while a professional veteran might want more readable code with better test coverage. And that's just 1 axis where the two viewpoints might diverge or even come in conflict.

Re: Mastering Time-to-Market with Haskell

#48

Post by pron »

vog wrote: post #32
amelius wrote: post #30

Earlier quoted context omitted.

You mean non-purely functional languages.

I assume you mean strict (the opposite of lazy) instead of non-pure (which means imperative). Well, even then, Rust does not only give you control over execution order, but also tight control over memory management, while keeping it safe. Haskell allows for good reasoning about correctness. In OCaml, you can additionally reason about execution order, but memory management and garbage collector are still somewhat "unp…

> pure (the opposite of imperative).

Pure is not quite the opposite of imperative; declarative is the opposite of imperative, although in practice it is true that pure functional languages tend to be more declarative that imperative functional ones.

You can have pure (AKA referentially transparent) imperative languages if they are synchronous[1]. The synchronous style is especially well suited to reactive/interactive applications, and quite popular in hard realtime applications.

Also, we don't really have exact definitions to any of these terms (imperative, pure, functional, declarative). Here is my attempt for approximate, problematic definitions:

* Functional -- a language that models most/all computations as (possibly partial) mathematical functions, and constructs a program by assembling those functions.

* Imperative -- a language that models computation as state transitions, specifying what state should the computation have at each step.

* Declarative -- a language that describes what result should the program give (as a function, a relation or a behavior) rather than at each step.

* Pure -- a language where the semantic value of the composition of syntactic terms can be determined by the semantic value of each of the component terms and no others.

[1]: https://en.wikipedia.org/wiki/Synchronous_programming_langua...

Re: Mastering Time-to-Market with Haskell

#49

Post by pka »

millstone wrote: post #15

IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way: you have to declare up-front which functions do I/O, etc. But once the core abstractions are settled, you start to reap its power. The type system catches tons of potential errors. Combinators allow for enormous expres…

> Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way

The opposite is true: here Haskell helps to find the right data structures/abstractions incredibly fast. The ability to quickly construct and reconstruct a high-level skeleton of your program without actually having to implement anything makes prototyping much easier and faster than in comparable dynamic languages.

> But then you hit a wall. Laziness makes for brutal debugging.

Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug.

> Singly linked lists actually suck.

Just replace them with the right data structure then? Even for big codebases and fundamental program abstractions that's a 15min job, because of types.

> Performance optimization is a black art.

I agree. But then again - you don't have to write everything in Haskell. Writing the critical 1% in C, testing the shit out of it and calling it from Haskell is absolutely fine.

Re: Mastering Time-to-Market with Haskell

#50

Post by paulajohnson »

oblio wrote: post #45
cageface wrote: post #40

Earlier quoted context omitted.

You would think that a really rigorous language like Haskell would foster a better ecosystem of libraries than ad hoc languages like Python or JS but that has not been the case at all so far. I'm not sure exactly why but it's one of the main reasons I'm taking a wait and see attitude to Haskell.

> a really rigorous language Is it rigorous in theory or in practice? An academic veteran might want to better express his ideas in code while a professional veteran might want more readable code with better test coverage. And that's just 1 axis where the two viewpoints might diverge or even come in conflict.

I'm trying to imagine what "rigorous in practice but not theory" might look like. It seems to me that rigor derives from theory and can then be applied in practice. Haskell is rigorous in both.
Post reply on HN