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

101–110 of 134 posts

Re: Why Not Haskell?

#101

Post by radarsat1 »

kisielk wrote: post #64
radarsat1 wrote: post #25

I've been doing a whole lot of scientific Python lately, and every time I let my program run for like an hour only to crash on an array of the wrong dimensions, or pass in a scalar where an array is expected or vice versa, I swear and wish I was using a strongly typed language like Haskell. If only it had the same tools as SciPy I'd be all over doing my scientific work in Haskell. (Not to mention it would have faster…

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…

Funny that you mention ad-hoc data analysis in the bottom part of your comment, because while i was reading the top part, i was thinking "ha, no _way_ am i going to be writing extensive unit tests while doing exploratory data analysis..."

For what it's worth, of course i do rudimentary testing before running things for an hour, but there's often small things that are missed that don't show up on smaller datasets for one reason or another. Of course it couldn't catch every possible runtime error, but in my real-world experience I have definitely come across things that would have shown up during compilation with strong type, _especially_ if the array sizes were encoded into the type system.

There's something practical about how Haskell makes you think about program structure and data representations ahead of time instead of it being an afterthought; but I agree, this can also be restrictive when you are being exploratory.

Re: Why Not Haskell?

#102

Post by SkyMarshal »

gnuvince wrote: post #78
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…

I found that one of the largest difference between Haskell and OCaml is the amount of time I spent figuring out how to make code go fast. Because OCaml is eagerly evaluated and that its compiler is extremely simple, I find that the "tools" that I learned in school and in my time coding in other languages apply to making OCaml code fast (and predictibly fast). With Haskell, you need to be more keenly aware of how eval…

>because I still have problems making really simple Haskell functions that don't crash.

Do those functions compile, and then crash anyway? I'd be interested to see examples. In my limited experience, if you can get your code to compile, it's pretty stable. Would be interesting to see counter examples.

Re: Why Not Haskell?

#103

Post by jules »

waqf wrote: post #95
jules wrote: post #84

Earlier quoted context omitted.

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

I have a hard time imagining how such a thing would actually work. How would the compiler decide that mutable state somewhere is encapsulatable and somewhere else it is not? A compiler can (very easily in fact) monadify all code for you, but what you get is an inefficient imperative language.

It seems to me that a much better approach is to allow mutable state everywhere, but to inform the programmer of the consequences via the editor/IDE by showing the result of a static analysis that analyzes which functions are pure and which are not.

Re: Why Not Haskell?

#104

Post by SkyMarshal »

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.

Regarding Haskell's type system, it's not even remotely like any type system you're familiar with if you haven't used Haskell yet.

Haskell is 'meta typed' (not a real term, just made that up). In Haskell, vars have data types, functions have type signatures, and even type signatures have types called kinds. A type signature is a specification of what types of parameters a function takes, and what type of result it returns. A kind specifies how many rounds of currying a type signature requires.

And it gets more sophisticated from there. Languages like Java with just mere data types are baby typed at best. Not even remotely comparable.

Re: Why Not Haskell?

#105

Post by lobster_johnson »

jberryman wrote: post #35
j_baker wrote: post #31

Earlier quoted context omitted.

Indeed I have. And most of those libraries are unfinished, poorly documented, or both. In short, it's great that people are putting the effort in. But Haskell has a long way to go still before it can compete with languages like python or ruby. Don't get me wrong. I love Haskell, and am willing to put up with things I wouldn't put up with in other languages. But it makes it difficult for me to sell the language to oth…

Sorry, but if we're talking about the quantity of poorly documented, broken, shat-straight-onto-github libraries out there, then ruby wins by a mile. This isn't a challenge, but I'm curious what standout libraries that ruby or python have for which Haskell is lacking in a good alternative.

It's not the quantity, it's the proportion.

I discovered this when I looked at using Scala for a particular project. The ratio of good-to-unfinished/poor libraries was much lower than for Ruby. It was also evident that code style/programming conventions had not solidified yet; it looked like the early stages of Ruby, where people weren't yet quite sure how to write "rubyesque" code. (Take a look at Ruby's standard library; it's for the most part very much out of date with "modern style" Ruby.)

I see the same kind of uncertainty with some Haskell projects, like the Text.Regex package, which I tried to figure out how to use, and failed, even with repeated google searches to find examples. The author seems to attempt at a certain ambitious programming style based on typeclasses, but since its usage is undocumented (or was, at the time I tried it ~6 months ago) you have to be a level 15 Haskell wizard to untangle its API. Similar Ruby experiments exist, and are eventually deprecated because of "too much magic".

Sure, Ruby developers create way too many projects that are never finished (or equally bad, are abandoned). But the stable of good-or-great libraries is actually very solid. Probably more so for web development than other things (Ruby doesn't have anything like Python's NumPy, for example); if you start a web project with Ruby you can get absurdly productive by just harnessing a few existing gems.

Re: Why Not Haskell?

#106

Post by gtani »

gtani wrote: post #54
teaspoon wrote: post #40

Earlier quoted context omitted.

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

http://haskell.org/haskellwiki/Keywords

(too late to edit above)

The haskell wiki link is not adequate, relative to the RW Haskell hard copy index (not avail. online unfortunately), which starts with 1.3 pages of symbol function names (and is missing a few relatively common QuickCheck symbol names).

I was looking for something like the Scala staircase book, first edition freely available online, which has a complete list for that language.

Re: Why Not Haskell?

#107

Post by mseebach »

outworlder wrote: post #97
mseebach wrote: post #92

Earlier quoted context omitted.

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.

Try harder what? Not seeing bugs I don't see?

Yes, I'm aware what "inputs" are. One property of what I consider well written software is the absence of global state. "External files, and so on." are, unfortunately, necessary for any program, even Haskell ones, to do anything useful.

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

Plus, so what? I'm not even beginning to compare Java with Haskell.

Re: Why Not Haskell?

#108

Post by gnuvince »

SkyMarshal wrote: post #102
gnuvince wrote: post #78

Earlier quoted context omitted.

I found that one of the largest difference between Haskell and OCaml is the amount of time I spent figuring out how to make code go fast. Because OCaml is eagerly evaluated and that its compiler is extremely simple, I find that the "tools" that I learned in school and in my time coding in other languages apply to making OCaml code fast (and predictibly fast). With Haskell, you need to be more keenly aware of how eval…

>because I still have problems making really simple Haskell functions that don't crash. Do those functions compile, and then crash anyway? I'd be interested to see examples. In my limited experience, if you can get your code to compile, it's pretty stable. Would be interesting to see counter examples.

I'm at school all day, but I'll post something tonight.

Re: Why Not Haskell?

#109

Post by SkyMarshal »

vidarh wrote: post #91
gaius wrote: post #88

Earlier quoted context omitted.

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…

Haskell frontloads type considerations and tests via a required, tightly-coupled type system. Dynamic languages backload them via optional testing.

In either case you still have to think about those issues when correctness is a requirement. When it isn't (ad-hoc analysis, prototyping), dynamic languages are more pleasant to work with. When it is a requirement, Haskell is uniquely powerful.

Problem is, many projects are subject to both requirements at the different times. Exploratory at the start, strict once the problem to be solved is identified. Know the tradeoffs and pick your poison.

Re: Why Not Haskell?

#110

Post by stonemetal »

Periodic wrote: post #38
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…

Can you explain a little more what you mean about the dataflow? When I was writing some game simulations I ended up creating a few different monads for different execution contexts. I would have my main world monad which contained configuration data, world state, information about all the actors, the random number seed. Then I would have other contexts like AI which is where the AI would figure out what to do, having…

That sounds interesting. Any chance the code is open sourced somewhere? I would love to read it.
Post reply on HN