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

Standardized Ladder of Functional Programming [pdf]

lambdaconf.us

Post reply on HN
Print view View original

111–120 of 146 posts

Re: Standardized Ladder of Functional Programming [pdf]

#111

Post by grumpyprole »

pron wrote: post #43
tikhonj wrote: post #18

Earlier quoted context omitted.

A lot of these techniques are things that take a bit more up-front effort but pay off over the long (or even medium) term. I think that's why it might make people seem less productive—although of course a lot depends on your perspective and experience. Measuring productivity is an open problem in software engineering and, in my experience, people's intuitions about it are all over the board, which means that nobody's…

> with the first style, productivity is constant at best—getting things together in the first place is a struggle, and then adding features or fixing bugs continues to be a struggle. On the other hand, the second style of project is even more of a struggle at first, but once it works it's like magic: new features are easier to add than you'd expect, and I've had way more things work after my first attempt than anyone…

Again, I answered this for you last week. Both Standard Chartered Bank and Barclays have many millions of lines of very successful production Haskell code. Both codebases are solving complex problems not solved at other banks and both make extensive use of types and purity. We do not regard pure functional programming as "aesthetics".

Re: Standardized Ladder of Functional Programming [pdf]

#112

Post by pron »

willtim wrote: post #108
pron wrote: post #103

Earlier quoted context omitted.

Load bearing materials actually carry significantly higher loads than mud; those Haskell constructs have not even been used to build software as intricate as common industry practice, let alone break new ground. Are they truly more powerful? That's a popular hypothesis among those who are aesthetically drawn to those concepts.

I gave you an example last week, which you are conveniently ignoring. We have millions of lines of Haskell code at Standard Chartered bank. The type safety and purity have helped us build a more reliable and maintainable codebase compared to previous efforts. Ultimately the language is just a tool. If you are not interested in type safety, purity or expressivity then it isn't the tool for you.

I am not ignoring anything. On the contrary: You yourself have said that the kind of software you write isn't any bigger or more complex than similar software written in more mainstream languages, and that you have no evidence of significant bottom line benefit (except claim that your software is more maintainable, but without any metrics). I never claimed that Haskell can't be used to write simple software as well as other languages, or even marginally better (for some definition of better). But the commenter I responded to claimed that those advanced abstractions are analogous to building materials that are used to build much bigger buildings than those possible without them. You have not even made that claim.

No one is interested in type-safety or purity for their own sake (except for aesthetic reasons). I'm interested in better, cheaper software. If Haskell's purity (there are simpler languages with similar type systems) provides that then there should be evidence of that before the claim is made. You have not provided any such evidence, and even implied that you're not even carefully collecting metrics that can be used to construct such evidence.

Re: Standardized Ladder of Functional Programming [pdf]

#113

Post by pron »

grumpyprole wrote: post #111
pron wrote: post #43

Earlier quoted context omitted.

> with the first style, productivity is constant at best—getting things together in the first place is a struggle, and then adding features or fixing bugs continues to be a struggle. On the other hand, the second style of project is even more of a struggle at first, but once it works it's like magic: new features are easier to add than you'd expect, and I've had way more things work after my first attempt than anyone…

Again, I answered this for you last week. Both Standard Chartered Bank and Barclays have many millions of lines of very successful production Haskell code. Both codebases are solving complex problems not solved at other banks and both make extensive use of types and purity. We do not regard pure functional programming as "aesthetics".

You are not addressing my point at all, and millions of lines of code (that include a Haskell compiler) do not necessarily make a large software system. If you are building software that is significantly more complex than could be achieved by other, simpler means, or you're building comparable large software systems for significantly cheaper, you'd only do Haskell and the world a great service by collecting and publishing relevant data. Without it, I have no idea how big your systems are, how complex they are compared to other projects, and how costly they are to build and maintain. I have no doubt you're happy with Haskell, but there are plenty of far more mainstream languages that people are happy with. Without any data, we can't make any comparison, so claims of superiority are nothing more than just claims. I find it puzzling that you don't see my reaction as a reasonable one for a marketing campaign that has been going on for nearly two decades, that has so far produced no evidence and negligible adoption. I truly and honestly want to be convinced. I am familiar with the theory of FP (up to about monad transformers, but not profunctor optics) and have programmed in SML. I just don't see any signs whatsoever that adopting Haskell can improve the bottom line significantly enough to be worth the cost and the risk, so the most logical thing to do is to wait and beg people for data.

Re: Standardized Ladder of Functional Programming [pdf]

#114

Post by grumpyprole »

pron wrote: post #113
grumpyprole wrote: post #111

Earlier quoted context omitted.

Again, I answered this for you last week. Both Standard Chartered Bank and Barclays have many millions of lines of very successful production Haskell code. Both codebases are solving complex problems not solved at other banks and both make extensive use of types and purity. We do not regard pure functional programming as "aesthetics".

You are not addressing my point at all, and millions of lines of code (that include a Haskell compiler) do not necessarily make a large software system. If you are building software that is significantly more complex than could be achieved by other, simpler means, or you're building comparable large software systems for significantly cheaper, you'd only do Haskell and the world a great service by collecting and publi…

You said:

"I would like to challenge that by pointing out that not a single piece of large software ... has ever been written using the skills/concepts of the higher levels of this chart."

To which I gave two counterexamples (today and on other occasions). All software systems should be modular to some degree, so I am not clear exactly what your criteria for a large software system is. In both my examples, the Haskell codebases are monolithic repositories where everything is typed-checked and built together.

You keep asking for quantitative data for a comparison with other languages. But my answer is the same as last week. It's good people that make software efficiently and cheaply. Give engineers PHP and they'll still manage to build something good. Haskell is just a tool, but it's a tool that increasingly good people are asking to use. The system at Barclays and Standard Chartered were built and are currently maintained very cheaply because good people were hired. Haskell just happened to be their preferred tool.

Re: Standardized Ladder of Functional Programming [pdf]

#115

Post by willtim »

pron wrote: post #112
willtim wrote: post #108

Earlier quoted context omitted.

I gave you an example last week, which you are conveniently ignoring. We have millions of lines of Haskell code at Standard Chartered bank. The type safety and purity have helped us build a more reliable and maintainable codebase compared to previous efforts. Ultimately the language is just a tool. If you are not interested in type safety, purity or expressivity then it isn't the tool for you.

I am not ignoring anything. On the contrary: You yourself have said that the kind of software you write isn't any bigger or more complex than similar software written in more mainstream languages, and that you have no evidence of significant bottom line benefit (except claim that your software is more maintainable, but without any metrics). I never claimed that Haskell can't be used to write simple software as well a…

> I never claimed that Haskell can't be used to write simple software

I can assure you our software is not at all simple. Standard Chartered has industry leading portfolio compression and XVA compute. Barclays has industry leading pricing of exotic derivatives (including pricing on GPUs). Both industry leading solutions built in Haskell on top of frameworks/APIs in Haskell.

> No one is interested in type-safety or purity for their own sake (except for aesthetic reasons).

So are all forms of static verification just aesthetics to you? Or just those offered in Haskell?

> I'm interested in better, cheaper software.

Then hire good people and let them use the tools they want.

The only evidence I could ever hope to offer is that good people build good software. But that would never make an interesting management report.

Re: Standardized Ladder of Functional Programming [pdf]

#116

Post by jpt4 »

pron wrote: post #112
willtim wrote: post #108

Earlier quoted context omitted.

I gave you an example last week, which you are conveniently ignoring. We have millions of lines of Haskell code at Standard Chartered bank. The type safety and purity have helped us build a more reliable and maintainable codebase compared to previous efforts. Ultimately the language is just a tool. If you are not interested in type safety, purity or expressivity then it isn't the tool for you.

I am not ignoring anything. On the contrary: You yourself have said that the kind of software you write isn't any bigger or more complex than similar software written in more mainstream languages, and that you have no evidence of significant bottom line benefit (except claim that your software is more maintainable, but without any metrics). I never claimed that Haskell can't be used to write simple software as well a…

> Haskell's purity (there are simpler languages with similar type systems)

For my own curiosity, to which languages do you allude in this statement?

Re: Standardized Ladder of Functional Programming [pdf]

#117

Post by pron »

willtim wrote: post #115
pron wrote: post #112

Earlier quoted context omitted.

I am not ignoring anything. On the contrary: You yourself have said that the kind of software you write isn't any bigger or more complex than similar software written in more mainstream languages, and that you have no evidence of significant bottom line benefit (except claim that your software is more maintainable, but without any metrics). I never claimed that Haskell can't be used to write simple software as well a…

> I never claimed that Haskell can't be used to write simple software I can assure you our software is not at all simple. Standard Chartered has industry leading portfolio compression and XVA compute. Barclays has industry leading pricing of exotic derivatives (including pricing on GPUs). Both industry leading solutions built in Haskell on top of frameworks/APIs in Haskell. > No one is interested in type-safety or pu…

> So are all forms of static verification just aesthetics to you? Or just those offered in Haskell?

As someone who makes use of formal methods regularly, I am aware of how weak Haskell's static guarantees are. That is not to say they may not be useful in practice, but that's an empirical question, and the one that I'm desperately waiting for answers to.

> The only evidence I could ever hope to offer is that good people build good software. But that would never make an interesting management report.

It also doesn't support the claims made that Haskell makes a significant contribution.

Re: Standardized Ladder of Functional Programming [pdf]

#118

Post by pron »

jpt4 wrote: post #116
pron wrote: post #112

Earlier quoted context omitted.

I am not ignoring anything. On the contrary: You yourself have said that the kind of software you write isn't any bigger or more complex than similar software written in more mainstream languages, and that you have no evidence of significant bottom line benefit (except claim that your software is more maintainable, but without any metrics). I never claimed that Haskell can't be used to write simple software as well a…

> Haskell's purity (there are simpler languages with similar type systems) For my own curiosity, to which languages do you allude in this statement?

Any of the MLs, really. Their type systems aren't necessarily equivalent to Haskell's, but given the lack of evidence for Haskell's superiority over pretty much any modern language, I doubt those differences make for even a marginal difference. The big thing about Haskell is that it's pure functional. Rust's type system is definitely in that ballpark, too, and maybe even Kotlin's.

Re: Standardized Ladder of Functional Programming [pdf]

#119

Post by pron »

grumpyprole wrote: post #114
pron wrote: post #113

Earlier quoted context omitted.

You are not addressing my point at all, and millions of lines of code (that include a Haskell compiler) do not necessarily make a large software system. If you are building software that is significantly more complex than could be achieved by other, simpler means, or you're building comparable large software systems for significantly cheaper, you'd only do Haskell and the world a great service by collecting and publi…

You said: "I would like to challenge that by pointing out that not a single piece of large software ... has ever been written using the skills/concepts of the higher levels of this chart." To which I gave two counterexamples (today and on other occasions). All software systems should be modular to some degree, so I am not clear exactly what your criteria for a large software system is. In both my examples, the Haskel…

> I am not clear exactly what your criteria for a large software system is.

Let a "software system" mean any assembly of processes that communicate to provide some shared functionality, with the components being coupled to one another in some non-trivial way (i.e., there are correctness conditions that cross processes boundaries, so that changes to one program may necessitate changes in others). Excluding the compiler, how many lines of Haskell code do you have in your largest system (using my definition)?

Re: Standardized Ladder of Functional Programming [pdf]

#120

Post by willtim »

pron wrote: post #117
willtim wrote: post #115

Earlier quoted context omitted.

> I never claimed that Haskell can't be used to write simple software I can assure you our software is not at all simple. Standard Chartered has industry leading portfolio compression and XVA compute. Barclays has industry leading pricing of exotic derivatives (including pricing on GPUs). Both industry leading solutions built in Haskell on top of frameworks/APIs in Haskell. > No one is interested in type-safety or pu…

> So are all forms of static verification just aesthetics to you? Or just those offered in Haskell? As someone who makes use of formal methods regularly, I am aware of how weak Haskell's static guarantees are. That is not to say they may not be useful in practice, but that's an empirical question, and the one that I'm desperately waiting for answers to. > The only evidence I could ever hope to offer is that good peop…

Yes Haskell makes a significant contribution. The person responsible for our industry leading portfolio compression joined us because we use Haskell.
Post reply on HN