Live data from Hacker News

Mastering Time-to-Market with Haskell

fpcomplete.com

91–100 of 120 posts

Re: Mastering Time-to-Market with Haskell

#91
post #48

Earlier quoted context omitted.

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

You've just defined “pure” as “can be given a denotational semantics”. I have news for you: even ALGOL can be given a denotational semantics. --- @pron Nowadays I prefer the terms “effect-free” and “effectful”, rather than “pure” and “impure”, since I don't want to suggest that effects are somehow “wrong” or “evil”. By definition, values are effect-free. An effect is anything that invalidates some equational law that…

Yeah, I know my definitions are problematic. Remember that the term "referential transparency" was introduced to computer science by Strachey in his Fundamental Concepts in Programming Languages as a property of procedural, imperative languages. How would you define pure?

---

> An effect is anything that invalidates some equational law that holds for values.

Ah, I can certainly accept that as a definition, except that I'm not sure how different it is from mine, because the equational law you refer to applies to syntactic terms (`foo` in your example) and the language's equality operator (`==` in your example). It's easy to come with an equivalence relation that would hold for `foo`, but not at the syntax level (e.g., equality that takes `foo` to mean `foo`'s definition and the content of the heap, and the value of `foo` would not be its return value but its behavior -- i.e., the behavior of foo for equal heap contents is always the same).

Re: Mastering Time-to-Market with Haskell

#92
post #85
post #79

Earlier quoted context omitted.

> We can certainly say that uncontrolled side-effects We most certainly cannot say that. There's no indication or even a hint that uncontrolled side-effects are a cause of expensive bugs. As a Haskell developer, however, I assume that you consider mutation to be a side-effect (because in pure-FP mutation is a side effect), and it is true that uncontrolled, non-transactional global-state mutation is not such a great i…

> There's no indication or even a hint that uncontrolled side-effects are a cause of expensive bugs. Uncontrolled side-effects destroy the ability to reason about software and when one can no longer reason effectively, bugs will happen. This is obvious to anyone who has worked on large systems. Whether it matters or not, depends on the domain. In finance, it is absolutely critical that we can reproduce a calculation…

> Uncontrolled side-effects destroy the ability to reason about software and when one can no longer reason effectively, bugs will happen. This is obvious to anyone who has worked on large systems.

I have worked on systems comprising 10MLOCs over a career of ~20 years, both as a developer and as a manager, and this isn't obvious to me at all. But I separate mutation from side-effects, because mutation is better defined, and what side-effects mean varies by language. Global mutation is important to control, but there are lots of ways to do that. Other side-effects (and especially IO)? Not so much.

> Having the compiler guarantee this for us is a huge win.

It is almost as trivial to guarantee that in Java, although maybe not during compilation.

> What do you actually know about the cost of Haskell adoption? If you want to accuse me of making unsubstantiated claims, your position would be more tenable without making them yourself!

Oh, while I haven't written much more than Hello, World programs in Haskell (but I have programmed in SML a bit years ago, and a fair bit in Scheme and Clojure), I am no stranger to the theory of pure-FP (simply typed LC w/ polymorphism, functional semantics, monadic composition etc; I'm less familiar with call-by-value semantics, though). It is pretty radically different from most other styles of programming, including imperative-functional, both in terms of coding as well as tools such as debuggers and profilers.

Re: Mastering Time-to-Market with Haskell

#93
post #75
post #57

Earlier quoted context omitted.

> If enough FUD is spread about Haskell, for example it being a failure at CS, then it becomes difficult to convince management. Haskell is not yet at an adoption level where anything said about it would qualify as FUD. If I told you I have a great cold remedy and all of my friends really like it, you saying that you may want some more carefully researched information first doesn't qualify as FUD. I don't see why any…

> carefully researched information first doesn't qualify as FUD How carefully researched was your very public assessment of what happened at CS? > Do we all need to try Elixir, Kotlin, Clojure, Scala, Haskell, F#, and Go? Of course not. Those interested in learning more about pure functional programming should try Haskell, the others have different niches they are trying to fill. > If Haskell had had a huge advantage…

> How carefully researched was your very public assessment of what happened at CS?

It wasn't. I simply stated that it's a negative signal; that's not FUD. It is a negative signal whether or not I mention it. Mentioning it gives Haskell advocates a chance to address it. You don't have to, but whatever you do, the signal is there. But it's just one signal. I don't think anyone should make a decision based on just one signal.

> Those interested in learning more about pure functional programming should try Haskell, the others have different niches they are trying to fill.

What should those interested in increasing productivity learn? This entire discussion isn't about learning a new programming style, but about achieving a goal of reducing development costs.

> No one is claiming Haskell is some sort of magic bullet for all use cases.

So what is the claim, and is there actual evidence (even anecdotal) to support it?

> I suspect that most of our industry isn't really interested.

The industry is extremely interested in anything that can significantly reduce the cost of developing software. We don't care if it's called Haskell or an omniscient debugger, or a static analysis tool.

> and will continue to be successful in that niche, with or without further productivity studies.

That's terrific, but don't blame the industry for being short-sighted and investing heavily in something that has little evidence of a great promise. You can only blame the industry for ignoring evidence, not for ignoring hype.

Re: Mastering Time-to-Market with Haskell

#94

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…

There's a reason Real World Ocaml has a section dedicated to the run-time system and no book on Haskell will ever go near it.

Re: Mastering Time-to-Market with Haskell

#95
post #72
post #57

Earlier quoted context omitted.

> If enough FUD is spread about Haskell, for example it being a failure at CS, then it becomes difficult to convince management. Haskell is not yet at an adoption level where anything said about it would qualify as FUD. If I told you I have a great cold remedy and all of my friends really like it, you saying that you may want some more carefully researched information first doesn't qualify as FUD. I don't see why any…

> Haskell is not yet at an adoption level where anything said about it would qualify as FUD. If I told you I have a great cold remedy and all of my friends really like it, you saying that you may want some more carefully researched information first doesn't qualify as FUD. I don't see why anyone can be expected to make a rational decision based on nothing but marketing from enthusiasts. Haskell is not even at the poi…

> Maybe "FUD" isn't precisely the right term, but Haskell does seem to attract a special level of attacks that isn't applied to other languages at a similar level of maturity.

It's a level of attack reserved for a special level of unsupported hype. I have absolutely no problem with those who say they really like Haskell, it fits well with how they think, and they feel more productive with it. I even have no problem with those who say that they believe the language has objective benefits in some domains and circumstances and that it deserves a closer look. But if you go around claiming that we can significantly reduce the cost of software development using your language (or any tool), I think an intsy-bitsy amount of even anecdotal evidence is required, especially after two decades.

You may not believe me, but I truly admire Haskell's elegance (even though I believe pure-FP is not the right path for most kinds of software; I have my own pet hypotheses). I just don't like the religious ecstasy that surrounds it.

> and they don't seem willing to pay what it would cost to study these questions to a scientific level.

Because in order for a business to invest in a costly experiment, there should first be some evidence that there's a good chance for the experiment to pay off significantly. Businesses aren't research institution, and they can't afford to invest in researching every new technology that somebody really likes.

> anyone who does that runs the risk of being outcompeted by those who pick a better lanugage.

As soon as the competition pulls ahead, people will be quick to flock to the new language. That's what happened with late Java adopters.

> would come with a high risk factor.

You're right that the risk isn't nonexistent, but it's relatively low (and Kotlin is backed by a larger company than the ones backing most new languages, with the exceptions of Go, Swift and maybe Rust). There's automatic translation and seamless interop, and gradual adoption is very easy. You can pick a class at random and translate it to Kotlin to test if build/debug/profile/deploy etc. works well, and then translate more classes. I'm not sure such a tool exists, but it should be fairly trivial to translate Kotlin back to very readable Java if the need arises to revert for whatever reason.

> but the business incentives don't seem to be there for those early-adopter businesses to publish that kind of report

I think that the business interests are there. If you invest heavily in a language, you'd want it to gain wide adoption so you get more maintenance, more libraries, easier recruiting, more tools and lower risk. The business interests would not be there if Haskell provided an incredible boost in productivity, that is so large that the competitive advantage offsets the downsides of low adoption. I don't think anyone is even making that claim.

Re: Mastering Time-to-Market with Haskell

#96
post #92
post #85

Earlier quoted context omitted.

> There's no indication or even a hint that uncontrolled side-effects are a cause of expensive bugs. Uncontrolled side-effects destroy the ability to reason about software and when one can no longer reason effectively, bugs will happen. This is obvious to anyone who has worked on large systems. Whether it matters or not, depends on the domain. In finance, it is absolutely critical that we can reproduce a calculation…

> Uncontrolled side-effects destroy the ability to reason about software and when one can no longer reason effectively, bugs will happen. This is obvious to anyone who has worked on large systems. I have worked on systems comprising 10MLOCs over a career of ~20 years, both as a developer and as a manager, and this isn't obvious to me at all. But I separate mutation from side-effects, because mutation is better define…

I also have ~20 years experience developing software. I have worked on 10+ MLOC Java and C++ systems at UBS, Deutsche Bank, Morgan Stanley, Lehman Brothers and others. I came to Haskell precisely because of my experience working on such large scale systems with mainstream languages. I have spent the last 4 years as a professional Haskell developer, first at Barclays, now at SCB.

While I could probably stomach giving up purity in a small project, you'd only be able to take away sum types and pattern matching from my cold dead hands.

Re: Mastering Time-to-Market with Haskell

#97
post #93
post #75

Earlier quoted context omitted.

> carefully researched information first doesn't qualify as FUD How carefully researched was your very public assessment of what happened at CS? > Do we all need to try Elixir, Kotlin, Clojure, Scala, Haskell, F#, and Go? Of course not. Those interested in learning more about pure functional programming should try Haskell, the others have different niches they are trying to fill. > If Haskell had had a huge advantage…

> How carefully researched was your very public assessment of what happened at CS? It wasn't. I simply stated that it's a negative signal; that's not FUD. It is a negative signal whether or not I mention it. Mentioning it gives Haskell advocates a chance to address it. You don't have to, but whatever you do, the signal is there. But it's just one signal. I don't think anyone should make a decision based on just one s…

> What should those interested in increasing productivity learn?

Productivity for whom? And over what timescales? As I have been trying to say, it is not that simple, you are oversimplifying.

> So what is the claim, and is there actual evidence (even anecdotal) to support it?

It sounds like you are completely satisfied with existing approaches, in which case there is little point in me trying to convince you.

> The industry is extremely interested in anything that can significantly reduce the cost of developing software.

Industry as a whole, does not have a good track record of adopting even good ideas in a timely manner. c.f. Garbage collection. So again, I think you are oversimplifying.

Re: Mastering Time-to-Market with Haskell

#98

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…

> 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

There's some evidence Haskell is pretty good at rapid prototyping.

Are you familiar with this '94 paper on rapid prototyping [ http://www.cs.yale.edu/publications/techreports/tr1049.pdf ] by Paul Hudak (RIP), sponsored by the Office of Naval Research & ARPA? The paper is a report on an experimental comparison of programmming languages for prototyping, and it's pretty cool because they were asked to implement a portion of a (heavily simplified) AEGIS weapons system! Unfortunately the paper and experiment are dated and have a number of methodological shortcomings (results were self reported; the examining panel didn't look at running code; requirements were very vague and mostly determined by each team, which makes the comparison difficult), but the results are pretty interesting regardless:

- Of all the teams, only the two Haskell teams delivered working code (though the examiners didn't look at working programs). This must be stressed: no other team delivered running code at all, much less on time!

- One of the Haskell prototypes delivered more features than the initial requirements asked for.

- The programmer of one of the Haskell teams had NO experience with Haskell before the experiment.

- Both Haskell prototypes were also the shortest in line count. Way shorter than the C++ prototype, which wasn't even finished or working in time!

I'd like to see the same experiment repeated under more rigorous conditions and with more modern languages, but the results certainly hint at Haskell being more than adequate at prototyping.

Re: Mastering Time-to-Market with Haskell

#99
post #91

Earlier quoted context omitted.

You've just defined “pure” as “can be given a denotational semantics”. I have news for you: even ALGOL can be given a denotational semantics. --- @pron Nowadays I prefer the terms “effect-free” and “effectful”, rather than “pure” and “impure”, since I don't want to suggest that effects are somehow “wrong” or “evil”. By definition, values are effect-free. An effect is anything that invalidates some equational law that…

Yeah, I know my definitions are problematic. Remember that the term "referential transparency" was introduced to computer science by Strachey in his Fundamental Concepts in Programming Languages as a property of procedural, imperative languages. How would you define pure? --- > An effect is anything that invalidates some equational law that holds for values. Ah, I can certainly accept that as a definition, except tha…

> except that I'm not sure how different it is from mine, because the equational law you refer to applies to syntactic terms

An effectful language can be given a denotational semantics. At least from what I've seen, when most people say “pure”, they mean “effect-free”.

> It's easy to come with an equivalence relation that would hold for `foo`, but not at the syntax level [emphasis mine]

Yep, indeed, that's the whole point.

Post reply on HN