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

71–80 of 120 posts

Re: Mastering Time-to-Market with Haskell

#71

Post by paulajohnson »

oblio wrote: post #52
paulajohnson wrote: post #50

Earlier quoted context omitted.

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.

I'm not talking about Haskell "the language", but about Haskell "the ecosystem". Industrial rigor regarding code means: * consistence in using a coding style * having adequately named modules, functions and variables * having adequate comments * having an adequate level of code coverage through automated tests * having performance and regression tests * having good release notes * etc. Many of those things, required…

So, like anything, the available libraries vary, but the important ones score pretty highly. Haddock documentation (like Doxygen) is considered a basic part of the job. "cabal test" will run embedded test harnesses. Stackage contains a set of libraries considered to be stable and of sufficient quality that most projects don't need to have qualms about using them. See for instance https://www.stackage.org/haddock/lts-7.10/http-client-0.4.31...

Re: Mastering Time-to-Market with Haskell

#72

Post by lmm »

pron wrote: post #57
willtim wrote: post #44

Earlier quoted context omitted.

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

> 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 point where management is the part of the organization that needs convincing.

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.

> Is every company supposed to just try each one? Do we all need to try Elixir, Kotlin, Clojure, Scala, Haskell, F#, and Go?

Well, companies have to make the choice one way or another, and they don't seem willing to pay what it would cost to study these questions to a scientific level. And the decision to stick with "industry best practice" (probably currently Java) is not a safe option either - anyone who does that runs the risk of being outcompeted by those who pick a better lanugage.

> A language like Kotlin is nearly free for Java shops to try.

Oh? To my mind a language that young, backed by a relatively small company, and whose popularity is heavily based on marketing (including a history of repeatedly announcing features before they were actually implemented) would come with a high risk factor.

> The best way for other developers to understand is, therefore, for the few early adopters to research and report on their experience, with some actual data (cost, duration, size etc.).

Sure - but the business incentives don't seem to be there for those early-adopter businesses to publish that kind of report (whether the outcome is positive or negative). How can we make that happen?

Re: Mastering Time-to-Market with Haskell

#73

Post by marcosdumay »

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

If you don't know Haskell or Lisp, I do recommend that you learn those. Now, I don't think they will open any immediate job stream for you (at least not now - Haskell is improving on that direction), but if you want to improve as a developer, you should know those two.

Re: Mastering Time-to-Market with Haskell

#74

Post by marcosdumay »

kinkdr wrote: post #5

Although very fresh into the Haskell world myself, I tend to agree with the author that, when I know what I am doing, my Haskell code is usually written in less time and has less bugs. Having said that, Time-to-Market is only partially influenced by my-code, the biggest part is the code that I don't have to write, i.e. third-party libraries. In my Haskell adventures I am having trouble finding third-party libraries f…

Yes, when working in Haskell, expect to do some yak shaving.

It's some incredibly productive yak shaving, it's even fun, but it's still yak shaving.

But I'll point that Haskell has also many wonderful libraries, for stuff you won't see in other communities. The libraries that are available are of an unmatched quality. Odds are a library marked as experimental on Hackage is more reliable than a mature one on the Python Index.

Re: Mastering Time-to-Market with Haskell

#75

Post by willtim »

pron wrote: post #57
willtim wrote: post #44

Earlier quoted context omitted.

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

> 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, it wouldn't have been abandoned

No one is claiming Haskell is some sort of magic bullet for all use cases. If you require ease-of-use, are writing disposable software, or high performance software, then it may not be the best choice.

Nobody is arguing against further studies, but I suspect that most of our industry isn't really interested. As I have said elsewhere, Haskell does not optimise for ease-of-use or aesthetics. It has a growing niche and will continue to be successful in that niche, with or without further productivity studies.

Re: Mastering Time-to-Market with Haskell

#76

Post by jstimpfle »

pka wrote: post #70
jstimpfle wrote: post #69

Earlier quoted context omitted.

Why, in your opinion, is it faster to construct a "high-level skeleton" than in dynamic languages? > Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug. The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. The answer I got was "yeah, in GHC 8 there will be some support for stack traces".

Because of types, basically. You can construct the core data structures of your program and the types of the functions operating on those data structures without having to actually implement said functions. When the types fit together, i.e. your program is logically consistent, you can start filling in the actual code. This is much faster than writing a large chunk of code, playing around in the REPL thinking everyth…

The error was my own. Only I couldn't figure out where exactly.

Such errors can't be avoided. I need arrays for performance.

If performance is no concern I can use Maps, but I still need indexing ("partial functions") for architectural reasons: separation of concerns - can't make "safe" graphs where everything holds a reference to everything "related".

I just don't buy the idea that partial functions can be avoided.

Re: Mastering Time-to-Market with Haskell

#77

Post by natec425 »

pka wrote: post #70
jstimpfle wrote: post #69

Earlier quoted context omitted.

Why, in your opinion, is it faster to construct a "high-level skeleton" than in dynamic languages? > Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug. The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. The answer I got was "yeah, in GHC 8 there will be some support for stack traces".

Because of types, basically. You can construct the core data structures of your program and the types of the functions operating on those data structures without having to actually implement said functions. When the types fit together, i.e. your program is logically consistent, you can start filling in the actual code. This is much faster than writing a large chunk of code, playing around in the REPL thinking everyth…

> For example, Elm, a language largely inspired by Haskell, doesn't have partial functions.

I may be wrong, but I don't think this is technically true. I don't think Elm has only total functions, but it does avoid a lot of common, error-prone partial functions (e.g. accessing elements from a collection).

Re: Mastering Time-to-Market with Haskell

#78

Post by Ixiaus »

jstimpfle wrote: post #69
pka wrote: post #49

Earlier quoted context omitted.

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

Why, in your opinion, is it faster to construct a "high-level skeleton" than in dynamic languages? > Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug. The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. The answer I got was "yeah, in GHC 8 there will be some support for stack traces".

It is faster for large programs. For small programs, I think Python is great but you also have to consider that there is no such thing as prototype code and a small script (usually but not always) balloons into something more involved than was originally intended.

THAT is where Haskell shines, the ability to refactor and expand fearlessly and aggressively.

I think for large or complex programs Haskell is much faster for constructing a skeleton because it's usually not the logical operations that trip us programmers up, it's the data flow and correct alignment of types, which are implicit in a dynamically typed language and explicit in Haskell.

So, it's kinda-sorta like writing your ideas down in a structured language which enables you to "see" the abstractions in a rigorous light, then the ability to refactor aggressively and safely kicks in so once you can see your abstractions you can quickly adapt for better ones.

So I think the initial work is made quicker in that it forces you to excogitate then because it's in some concrete form you can see it clearly and take advantage of quick turnaround time in refactoring.

Re: Mastering Time-to-Market with Haskell

#79

Post by pron »

willtim wrote: post #66
pron wrote: post #59

Earlier quoted context omitted.

Nobody knows if Haskell's design is great for software development, and if it is, by how much and whether it justifies the costs. That's precisely why we need data. > Haskell just happens to have come from academia and is still heavily used in academia. Haskell isn't heavily used in academia at all. My guess is that most CS professors -- like most developers -- have hardly even heard of it, let alone used it. It is h…

> Nobody knows if Haskell's design is great for software development We can certainly say that uncontrolled side-effects, manual memory-management and dynamic types is bad for software development in the large. I'll stop here because I don't which to argue the semantics of what does are does not constitute significant use or significant research.

> 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 idea, but most developers know not to do that in any language, and if you want language-level enforcement on mutation, you can get that for a fraction of the price of Haskell. There's also nothing to suggest that Haskell's approach is a good one (as opposed to, say, Clojure's or Erlang's) or even that Haskell's cure isn't worse than the disease.

> manual memory-management

Absolutely, and you can get automatic memory management for a fraction of the cost.

> and dynamic types

You get static types for a fraction of the cost, too.

> argue the semantics of what does are does not constitute significant use

It's fine for a language to not have wide adoption. That doesn't mean it's not good or even not great. It's also fine -- and I do that, too -- for people to say, I really like that language, I find it elegant, and I feel it helps me develop. What isn't fine is endless hype with claims of significant bottom line benefit but little effort to collect even anecdotal evidence (and I don't mean evidence that Haskell programs can run, or that you really like the language; I mean evidence of the extent of the claimed benefit).

Re: Mastering Time-to-Market with Haskell

#80

Post by pka »

jstimpfle wrote: post #76
pka wrote: post #70

Earlier quoted context omitted.

Because of types, basically. You can construct the core data structures of your program and the types of the functions operating on those data structures without having to actually implement said functions. When the types fit together, i.e. your program is logically consistent, you can start filling in the actual code. This is much faster than writing a large chunk of code, playing around in the REPL thinking everyth…

The error was my own. Only I couldn't figure out where exactly. Such errors can't be avoided. I need arrays for performance. If performance is no concern I can use Maps, but I still need indexing ("partial functions") for architectural reasons: separation of concerns - can't make "safe" graphs where everything holds a reference to everything "related". I just don't buy the idea that partial functions can be avoided.

I.e. look at how PureScript does it [0]. Haskell could do the same.

[0] https://pursuit.purescript.org/packages/purescript-arrays/3....

Post reply on HN