The New Haskell Homepage • Hacker News Board

Re: The New Haskell Homepage

#251

Post by ufmace » Thu, Jul 10, 2014, 7:55 PM UTC

happimess wrote: post #243

ufmace wrote: post #191

Earlier quoted context omitted.

Thanks for the help, though Vim is already my choice for insanely-powerful text editor with 2k+ page user manual :) I tried emacs, but the dependence on the control key for everything makes it kinda painful on every keyboard I have. I suppose I could probably remap a bunch of keys or something, but Vim seems to work much better in the default configuration. I know this tends to be a big flamewar subject, so it is wha…

> Also checking out the other people's suggested Learn you a Haskell. Just to get the minority opinion out there, I found the style of Learn You a Haskell to be insufferable. Real World Haskell is available free online[1] and has a straightforward tone of voice. [1] http://book.realworldhaskell.org/

Well, to each their own. I just finished the third chapter last night, and I'm enjoying it so far.

Re: The New Haskell Homepage

#252

Post by akurilin » Thu, Jul 10, 2014, 11:24 PM UTC

platz wrote: post #245

akurilin wrote: post #220

Earlier quoted context omitted.

For me it's mostly about codebase scaling, refactoring and maintainability. Clojure is liberating and exciting when you're writing a tiny little project, but it's a whole other experience when you need to refactor dozens of files because you changed the format of the data being passed around, or you're changing an internal API that's called from a hundred different places. You better have perfect code coverage, or yo…

Would Prismatic/Schema address those data typing issues?

I'm actually a Schema user, I love it, it's pretty convenient for addressing the boundary issue, since you don't have types and cannot really enforce that outside input conforms perfectly to the expected schema without run-time validation.

Schema helps (I used to use Mississippi back in the day with all sorts of complex checks, it was ugly), but it's more of an "add-on" in the end. I actually have a reasonably convenient flow for validating outside API input, business logic constraints and performing the necessary operations against the data store all in one big error monad nowadays. The problems is that I still have to go out of my way to add these input/output validation checks to everything when I could just get it for free through the type system.

Look, don't take my word for it: I strongly encourage you to try the two paradigms yourself and see what you think. Unfortunately it's very difficult to see the downsides without a large project, but you can probably extrapolate.

Re: The New Haskell Homepage

#253

Post by protez » Fri, Jul 11, 2014, 9:03 AM UTC

I love Haskell and OCaml, and other functional languages. However, no matter how intelligent and higher-level functional language becomes, I don't think they can replace procedural language, especially for time-based programmings, such as user interface effects, animations, or network-dependent operations. Some features are inherently procedural by their nature, and functional language are not functional for describing them.

Re: The New Haskell Homepage

#254

Post by mkesper » Fri, Jul 11, 2014, 12:23 PM UTC

gamegoblin wrote: post #239

mkesper wrote: post #237

Earlier quoted context omitted.

What is pattern matching really used for? The way it's presented in these examples it feels like a complicated version of Python slicing.

Well, you can use it to match on any value. So it's more useful than just slicing up lists. Python has a primitive form of pattern matching in the form of unpacking , for example, this is legal code: def tuple_decomp( (a,b) ): return a+b You pass in a 2-tuple (1,2) and 1 gets put into `a` and 2 gets put into `b`. It will error on anything but a 2-tuple. As I showed in my examples, which I think you might have overloo…

Highly interesting, thanks!

Re: The New Haskell Homepage

#255

Post by codygman » Fri, Jul 11, 2014, 3:47 PM UTC

judk wrote: post #88

bignaj wrote: post #80

Earlier quoted context omitted.

If you ever wanted to know what a typical Haskell programmer sounds like, ^^this is it to a T.

No, typical Haskell programmers avoid talking about performance issues, because those highlight how awkward it is to write high- performance code.

I'm a Haskell programmer and I care about performance. So do many others, which is why you continue to see things like Conduit and more recently Haxl.

Re: The New Haskell Homepage

#256

Post by exDM69 » Sat, Jul 12, 2014, 5:08 PM UTC

dragonwriter wrote: post #185

exDM69 wrote: post #182

Earlier quoted context omitted.

> I guess primes is a thing (function?) that takes 2 or more things? Primes is an infinite list of integers containing all prime numbers. It's not a function, it's a value just like any other list of integers. You obviously can't do something like that in C++ or most other languages. I think that's a pretty good example to demonstrate the difference between a pure and lazy language like Haskell and the more mainstrea…

> Primes is an infinite list of integers containing all prime numbers. It's not a function, it's a value just like any other list of integers. > You obviously can't do something like that in C++ or most other languages. While the syntax is different, you can create a value just like any other iterable sequence that happens to be a generator for the infinite series of integers resulting from filtering another infinite…

> you can create a value just like any other iterable sequence that happens to be a generator for the infinite series of integers...

I know that. Almost every language out there has some kind of generator/iterator protocol for "lazy" sequences. But they're not a list like any other list out there. You can (usually) iterate through them only once.

And you can't apply a generator/iterator type of deal to, say, a tree structure or any other non-linear data structure.

In Haskell, every value works like that (unless you explicitly tell otherwise). This is what the "primes" example is trying to show.

Re: The New Haskell Homepage

#257

Post by johnny22 » Sun, Jul 13, 2014, 6:02 AM UTC

Pacabel wrote: post #78

rtfeldman wrote: post #73

Earlier quoted context omitted.

Yes - the practical reason is to focus on the newcomer's experience. Information overload is actively harmful to someone coming to haskell.org to learn about the language from scratch. Omitting content that is primarily valuable to experienced Haskellers is a feature, not a bug.

This sounds like a dangerous trade off to be making. It's reminiscent of what we saw with GNOME 3, or even Windows 8. The experience is made much worse for existing users, in a vain attempt to "simplify" the design to allegedly appeal to new users who may not even really exist in practice. It's obvious now that it didn't work well in those cases, and I don't see why this case would be any different. As an occasional…

i don't think you can speak for all gnome 3 users. I'm the happiest i've ever been with gnome 3. I don't have a bunch of options and other knobs to twiddle. It just works and stays out of the way.

Re: The New Haskell Homepage

#258

Post by 72deluxe » Wed, Jul 16, 2014, 9:01 AM UTC

orbifold wrote: post #186

72deluxe wrote: post #136

Earlier quoted context omitted.

Very true, but helpfully many other languages have a similar syntax (C, Java, JavaScript, even PHP's OOP system looks like Java) so it is easy to move between them. This looks very alien. Is there any language with a similar syntax?

The syntax should not really be a primary concern when evaluating a new language. It is easy enough to pick up if you understand the concepts behind the language. Haskell has not all that many keywords and a lot of syntactic sugar, there are no public final static member variables and no insane *((&a)++)++.

That's a good attitude to have when approaching a new language. I should try a new language, if and when I have a need or need to learn some new concepts.