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

Why Not Haskell?

neugierig.org

Post reply on HN
Print view View original

91–100 of 134 posts

Re: Why Not Haskell?

#91

Post by vidarh »

gaius wrote: post #88
kisielk wrote: post #64

Earlier quoted context omitted.

Sounds to me like you're doing it wrong. I write scientific Python code every single day for work and I (nor anyone else who works with me) never run in to those kinds of problems. Why are you running simulations that take an hour before you even know your code work? Where are your unit and integration tests? Every piece of our software stack has (or should have...) tests that verify all the bits fit together correct…

The point is that a whole class of things that you would have to write unit tests for, you get "for free" with strong typing, and for a lot of the others, there's QuickCheck. Or as the old saying goes, why get a dog and bark yourself?

Except you don't get them "for free". You get them in the form a ton of restrictions on you that you need to be mindful of when writing it in the first place. You just pay for it in different ways. The biggest difference is that in dynamic languages, you can sometimes get away with being lazy and not writing the tests to verify the things static languages enforce to varying degrees (whether or not that's a good thing is another issue).

Re: Why Not Haskell?

#92

Post by mseebach »

neilk wrote: post #85
mseebach wrote: post #82

First, the title annoys me: "Why not X?" is almost always the wrong question to ask, because it implies that X is so great that don't even need a reason to use it. If you want me on board, the relevant question is "Why X?". Second, A resulting correct Haskell program is likely more reliable, maintainable, and perhaps faster seems fallacious to me. It might as well be that because Haskell is hard, only people with a d…

I am guessing that you have never worked with Haskell? Your hypothesis -- that difficult languages result in more bug-free code, due to selection bias -- is, to say the least, somewhat of a minority opinion. But even if we accept this, Haskell is different. The difficulties of Haskell are not arbitrary. Nor are they related to the difficulty of understanding the machine at a low level. In fact, Haskell insulates you…

No, I have not worked with Haskell.

I agree that a good type system eliminates an entire class of bugs (being strongly typed is what makes Java bearable), but I rarely see bugs in well-written software caused by not having considered the full range of inputs to your function.

Re: Why Not Haskell?

#93

Post by stonemetal »

pnathan wrote: post #17

I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work. To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the PPC. Well - I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community & documen…

Does the lack of multithreading in Ocaml matter for your applications, I think that is the only thing that would push me towards Haskell over Ocaml.

Re: Why Not Haskell?

#94

Post by aangjie »

pnathan wrote: post #17

I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work. To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the PPC. Well - I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community & documen…

//would it be a good ROI? I am only a haskell beginner but i think we can break down this question a little more specific by talking about exact timespan of the projects. From what i understand haskell's maintainability is a huge advantage in some projects with never ending specification changes and feature requests.(ERP??) Anyone has tried haskell for something like that? or were stopped by the chicken-egg problem of finding ppl to maintain the code?? Would be good to have some data points.

Re: Why Not Haskell?

#95

Post by waqf »

jules wrote: post #84
waqf wrote: post #12

Earlier quoted context omitted.

> I started writing a game in Haskell and found that the scaffolding necessary to do randomness in the "right" way was just too painful. It could be that I hadn't learned the idioms well-enough to see a better way of doing things; but if I had trouble, I think it's fair to say that most people would. This. My current opinion as to what would constitute a perfect language is: something built on top of Haskell which wo…

> My current opinion as to what would constitute a perfect language is: something built on top of Haskell which would, in some as-yet-unconceived-of way, make it easy to thread mutable state exactly where it needed to go in your code. What's the difference between that and an imperative language?

The difference is that it only makes well-defined, encapsulatable dependencies on your mutable state easy. It doesn't make totally screwing up easy.

Re: Why Not Haskell?

#96

Post by pnathan »

teaspoon wrote: post #40
pnathan wrote: post #17

I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work. To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the PPC. Well - I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community & documen…

Special operators out the wazzoo...Google doesn't help here - I don't even know the verbal names for some of them. Operators are just functions, so try Hoogle: http://www.haskell.org/hoogle/?hoogle=%3E%3E%3D

FYI: Hoogle dies on :: and `, and gives a wrong result for =>.

Please note that this is just a simple problem, with a solution of printing out the right reference cheatsheet.

The real difficulty comes (IMO) when looking at piles of symbols in code and trying to determine what kind of meaning is coming from the symbol soup (C++ and Perl are notorious for this too).

Quite often (usually?), of course, public Haskell is written in a very clear and readable style. That's a major reason to use Haskell - to write in a readable language.

Re: Why Not Haskell?

#97

Post by outworlder »

mseebach wrote: post #92
neilk wrote: post #85

Earlier quoted context omitted.

I am guessing that you have never worked with Haskell? Your hypothesis -- that difficult languages result in more bug-free code, due to selection bias -- is, to say the least, somewhat of a minority opinion. But even if we accept this, Haskell is different. The difficulties of Haskell are not arbitrary. Nor are they related to the difficulty of understanding the machine at a low level. In fact, Haskell insulates you…

No, I have not worked with Haskell. I agree that a good type system eliminates an entire class of bugs (being strongly typed is what makes Java bearable), but I rarely see bugs in well-written software caused by not having considered the full range of inputs to your function.

Really? Try harder :)

Remember that the "inputs" in non-pure languages are not only the function arguments, but can be global variables, objects (singleton or otherwise), external files, and so on. These are all inputs.

Plus, Java's type system is a toy compared to Haskell.

Re: Why Not Haskell?

#98

Post by pnathan »

aangjie wrote: post #94
pnathan wrote: post #17

I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work. To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the PPC. Well - I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community & documen…

//would it be a good ROI? I am only a haskell beginner but i think we can break down this question a little more specific by talking about exact timespan of the projects. From what i understand haskell's maintainability is a huge advantage in some projects with never ending specification changes and feature requests.(ERP??) Anyone has tried haskell for something like that? or were stopped by the chicken-egg problem o…

The key reason I am looking at this kind of technology is because I have a large block of code in a situation where it is very difficult to do functional or unit tests due to system design. Being able to write in a language that statically analyzes my code for all the errors it can before my poor customers encounter it sounds like a huge win. The maintenance goal is being able to catch my fat-fingers and design flaws prior to rollout.

* I suppose if I had to quantify the maintenance timespan, I'd make a WAG of 5-7 years, possibly 10.

* It's also probable that after its solid now, in 5-7 years I will be doing other things and unable to be reassigned to work on this full-time. So it has to be other-people-hackable.

Re: Why Not Haskell?

#99

Post by nathanwdavis »

uriel wrote: post #90
gaius wrote: post #87

Earlier quoted context omitted.

Well they ain't gonna use or promote C# are they?

Google is a very big and diverse organization, I'm sure there are some that do promote pretty much every language you ever heard of (and many you didn't). Actually, I remember some years ago reading about some Googlers that used C#, no clue what for, and it was a while ago, but it is not unrealistic.

John Skeet?

Re: Why Not Haskell?

#100

Post by JoshTriplett »

monopede wrote: post #75
abi wrote: post #47

Earlier quoted context omitted.

With regards to generating random numbers, the Foreign Function Interface is also really useful. Here's a one-line wrapper around random(3). foreign import ccall "stdlib.h random" c_rand :: CDouble -> CLong

That will most likely bite you since you're giving a pure type to a non-referentially transparent function. There is a reason why random functions are in a state monad or IO.

In particular, while you don't really care what order the compiler makes the underlying calls to the C function, you do care that it actually makes all the calls rather than CSEing them away. As a pure function, the compiler has every right to optimize away multiple calls to your FFI-bound random function, in favor of a single call and multiple references to the value.
Post reply on HN