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

101–110 of 120 posts

Re: Mastering Time-to-Market with Haskell

#101

Post by Steeeve »

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 would recommend none-of-the-above.

Having gone down the Haskell rathole, it's clear to me that the advertising is better than the product. It's complex and difficult to learn and the "less errors because of typing" mantra turns into 'how in the world am I supposed to find my error'. In practice, I very rarely run into errors caused by type problems.

I know nothing about F#, but that's actually my criticism of it. The F# community is small. I occasionally hear about people playing with F#, but even that is rare. (although it could be that I just don't know enough about it and F# and it's community is awesome)

Scala has a reasonably sized community and is being used in production plenty. I personally don't see any benefit beyond the fact that some people like the syntax better than Java and can do less boilerplate (which, if not paying attention could lead to higher resource consumption).

If I were looking for something new, I'd look into Go and Rust. Both have strong followings, a lot of active development to learn from, and strong job markets moving forward (IMO). Or alternatively reverse-expand back into C and start playing with embedded RTOSs - which has the benefit of both being very interesting and an area where senior people could make a significant impact.

... Now, if you really wanted one of the three - I would choose Haskell for learning, Scala for job market, F# if you are already a .net developer.

Re: Mastering Time-to-Market with Haskell

#103

Post by pron »

catnaroek wrote: post #99
pron wrote: post #91

Earlier quoted context omitted.

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…

> when most people say “pure”, they mean “effect-free”

But saying "effect free" doesn't mean much unless you define what an effect is, and what constitutes an effect depends on the language. I meant to define the same thing without referring to another vague definition.

Re: Mastering Time-to-Market with Haskell

#104

Post by saosebastiao »

the_af wrote: post #98
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…

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

1994 was well before the IO monad became the standard IO paradigm for Haskell, and a year before there was even a proposal on the table for monadic IO for Haskell. It makes me wonder what the language was like back then and whether the results would be repeatable with today's language.

Re: Mastering Time-to-Market with Haskell

#105

Post by pron »

willtim wrote: post #96
pron wrote: post #92

Earlier quoted context omitted.

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

Personally, I am a bit skeptical of language-level features in general (as opposed to runtime features) to provide significant benefit compared to their high cost[1], and doubly so in general purpose languages, but that is precisely why I am interested in good technical reports about the pros and cons of languages, and those are sorely missing. At this point, whatever public information we do have seems to suggest that no company is significantly better than most others when it comes to delivering complex large software. There are a few exceptions where specific attributes are concerned. For example, Altran UK (Praxis) do seem to be rather exceptional in their ability to provide large verified software (they use Z for specification and Ada SPARK for coding), and they do have technical reports that are not completely devoid of useful information.

[1]: This isn't even about a particular language (although different languages do have different cost of adoption). Any language that doesn't have excellent interop with existing libraries and legacy code has a very high cost of adoption (and yeah, we've tried Scala years ago, and the experience was far from good).

Re: Mastering Time-to-Market with Haskell

#106

Post by catnaroek »

pron wrote: post #103
catnaroek wrote: post #99

Earlier quoted context omitted.

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

> when most people say “pure”, they mean “effect-free” But saying "effect free" doesn't mean much unless you define what an effect is, and what constitutes an effect depends on the language. I meant to define the same thing without referring to another vague definition.

I already defined above what an effect is. My definicion is technically precise and language-independent.

Re: Mastering Time-to-Market with Haskell

#107

Post by kazinator »

hellofunk wrote: post #34
stanislavb wrote: post #14

And I believe that based on the enlisted properties/features, Elixir may qualify pretty well, too. What is more, Elixir may be a better choice in regards of time-to-market + developer happiness.

Yes, but that's a dynamically typed language and everything changes when comparing it. There are so many tradeoffs. Clojure is quite quick to write and time to market can be very fast, as with most lisps, but you pay the price at debug time. We recently shipped a production app that had a small typo that the compiler would have easily caught, but instead it crashed the site when this one particular task was run.

Your experience with Clojure might not in fact generalize to "most lisps", which have very good compilers that catch all kinds of errors. Certainly the "low hanging fruit" ones like references to unbound variables or functions and such.

What was the typo?

> it crashed the site when this one particular task was run.

Might that also be because that was the first time the task was run at all, since the code was written or altered?

Code that compiles (such that we are confident it is probably free of silly typos, other than those somewhat rare typos which play out in some way that still compiles), might not be correct; it still requires testing.

Re: Mastering Time-to-Market with Haskell

#108

Post by pron »

willtim wrote: post #97
pron wrote: post #93

Earlier quoted context omitted.

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

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

I'm only simplifying as much as the claims in the article. It's just pretty hard to understand what the claims about Haskell are given all of the vague hype. The article we're discussing says, "Haskell decreases development time by narrowing the scope of development to your domain." Obviously, I understand there are caveats, and it's unclear how big the savings are. I just want reports with some meat.

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

The question of being "completely satisfied" is irrelevant. I'm not a researcher and my goal isn't to dream up better approaches, nor do I have the resources to invest in experimenting with every new tool. I am, however, very interested if someone says they have a tool that can provide significant savings. If there were only some more actionable information, convincing me would be quite easy. I want to be convinced, but throwing general promises around serves to confuse more than enlighten.

Re: Mastering Time-to-Market with Haskell

#109

Post by pron »

catnaroek wrote: post #106
pron wrote: post #103

Earlier quoted context omitted.

> when most people say “pure”, they mean “effect-free” But saying "effect free" doesn't mean much unless you define what an effect is, and what constitutes an effect depends on the language. I meant to define the same thing without referring to another vague definition.

I already defined above what an effect is. My definicion is technically precise and language-independent.

OK, so you define effect-freedom using the language's equality operator. I agree it's a better definition than mine, but I think assembly language and BASIC would still qualify as effect-free (provided there's no concurrency) even though some people would not consider them pure.

Re: Mastering Time-to-Market with Haskell

#110

Post by catnaroek »

pron wrote: post #109
catnaroek wrote: post #106

Earlier quoted context omitted.

I already defined above what an effect is. My definicion is technically precise and language-independent.

OK, so you define effect-freedom using the language's equality operator. I agree it's a better definition than mine, but I think assembly language and BASIC would still qualify as effect-free (provided there's no concurrency) even though some people would not consider them pure.

> OK, so you define effect-freedom using the language's equality operator.

Not the runtime equality testing operator. Rather, the language's static notion of contextual equivalence.

It just happens to be the case that most high-level languages provide a built-in equality testing operator that works on primitive types, returning `true` iff its operands are contextually equivalent values.

> I think assembly language and BASIC would still qualify as effect-free

I don't even know what a good notion of contextual equivalence for any assembly language would be.

As for BASIC, I haven't used the old ones, so I can't comment on them. I've used Visual Basic, which most certainly has effectful procedures.

Post reply on HN