/λ/ - programming

>>740
Haskell is an academic language. I have a hard time recommending it when you can use Lisp, Scala, F# etc. to learn FP principles, and have the advantage of experience with a language used in industry.

One advantage of Haskell I can think of is it is entirely functional (unlike Scala and F#), so it will force you to learn FP by the nature of it being the only paradigm available to you. Still, it's hard to beat the Scheme/SICP combo for learning FP.

>>740
Haskell would be a good language if you removed monads and gave it regular I/O and did not force lazy evaluation. Im not saying this a joke, It has an outstanding type system, it would be a top notch FP language if would stop pretending its a 'pure' FP language because its not.

>>762
> removed monads

whoa there boyo

>>762
Monads are actually amazing.

>>762
This is clearly a very polarizing opinion. Perhaps you should just use OCaml. Yes, you don't have typeclasses, but in practice it's not that bad as long as you use modules and type aliases appropriately.

haskell is not an academic language. it has plenty of good libs and documentation and you can use it for pretty much anything except maybe video games. less industrial use than scala, probably, but it's fully capable. also, it will teach you things that you won't learn from scheme

monads have nothing to do with IO. monad is just an interface. I can't imagine why anyone would consider more genericity to be anything but a feature. haskell does not force lazy evaluation, it's just that strictness is opt-in instead of out-out as usual. though, yeah, it sucks sometimes

i feel the same way as op - haskell is just nice to use, it lets me describe what i want in a slightly mathier way than other langs which just feels right to me. and referential transparency makes a lot of stuff easier to think about. it's comfy. it's not really objectively better than other langs except perhaps within a certain niche, though

As a beginner trying to learn Haskell again, I find the "Basics of Haskell" articles by Bartosz Milewski really concise and effective. More importantly it covers I/O pretty early so one can start making "real" program without waiting for the last chapters of a book where monads and I/O are usually finally covered.

I'm still far from implementing the simple ideas I have though, and the way he designs his calculator makes me realize how much lacking I am in software engineering

https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell

I also stumbled upon this very interesting meta-tutorial on how to learn Haskell, might give insight about why you should learn this language and what to expect from it :

https://acm.wustl.edu/functional/haskell.php

I'm not far into it but what really motivate me is everything related to the type system, from the ability to write the type signature beforehand to the way data can be modeled with custom types. Having said that even Java way of declaring value seems fine to me, given the language I'm used to dealing with (PHP, Js, Python)

I've attempted to learn it several times but never could actually install it, no matter which guide I follow it always ends up broken.

>>1211
I'm sorry anon, this is a sign that you need to get better at using and maintaining your computer in general. GHC has support on almost every OS unless you are using something obscure.

If you post what is happening in more detail we can maybe try to help you out.

Use Elixir if you want to use a useful functional language

>>1214
I don't remember the details, but it was probably caused by cabal fighting against packages installed by the native package manager.

>>772
> it's just that strictness is opt-in instead of out-out as usual.
With GHC you may turn it upside down using LANGUAE Strict (actually, no).

>>748

I don't know if this is true, I feel like the haskell ecosystem has really been evolving quite well these last few years. I know of quite a few companies now that use conduit and servant on their backends.

>>1216
This happened to me too.

>>740
>>762

Purely lazy evaluation is what got me really thinking about the concept of side effects and how hard they are to manage.

Haskell will still let you produce effects whenever you want (by using

unsafeIO

). "Unsafe" in Haskell does not mean "your computer might blow up so don't use it", it means "if you use this, I can no longer guarantee that your program is typesafe, as you could be doing anything in this call". The disdain for

unsafePerformIO

mostly comes from the futility of using Haskell if you are going to sequence your IO operations in a procedural manner.

In general, the real use for a program comes from its input, its interaction with the operating system and the output it performs, so thinking purely in terms of IO and how the operations should be sequenced is key to the proper use of monads.

>>748
Haskell has many uses outside of academia. Facebook uses it. I do not think that Facebook is an example of great software in general, although if Facebook considers Haskell production-ready, it certainly means something. Conduit is an awesome library, and so is Parsec.

Parsec made me realize how powerful Haskell's type system is. Playing around with parser definitions, I really liked being able to see how my program did not compile because, for example, I was actually returning a list of strings rather than a single string at one step. A dynamic language would have failed at run-time instead. The type system in itself offers a built-in test suite at no added effort.

>>772
>video games
You can certainly do video games in Haskell. In 2005, a Quake 3 clone named Frag has been written by an undergraduate student: https://invidio.us/watch?v=0jYdu2u8gAU

This 2008 video is jerky as hell due to capturing issues, but you can see that the framerate counter shows decent 60FPS average framerate.

Here's a Super Mario Bros. clone in Haskell. https://invidio.us/watch?v=gVLFGQGRsDw

I think that the video game is swamped with creative types, while the crowd who is interested in Haskell does not share much overlap with the creative types, thus severely limiting adoption of Haskell as a language suitable for video game development.

>>1500
I think that Haskell is more apt to writing a video game engine rather than crafting an individual game itself.

>>1211
You'll want to use stack (https://docs.haskellstack.org/). Install it from the package manager or separately, then let it handle everything else. It also lets you use different package versions for different projects.

If you're on arch linux the haskell packaging in the repos is messed up.

>>762
So you want PureScript?

The first thing is that as _a_ language, Haskell (more specifically GHC), for me is just a generally better than everything I've used so far, especially the more mainstream languages. It's not perfect, I have lots of gripes with it. But I have so little frustration writing haskell compared to the rest (especially stuff like C++ and C#). Every time I use another language I'm getting frustrated by thousands of pitfalls and special cases everywhere, or the famous "in haskell this is just". I wish every language would be designed in such a principled way and not cripple itself on purpose (elm, go, etc.).
Typeclasses for example, they're such a good feature imo, I absolutely hated that in Ocaml wherever we wanted the same thing with modules, we'd have to pass everything explicitly.
If you're into FP, I don't have to sell the merits of immutability. Now, there's a price you pay for immutability, so most other FP languages decided to just not pay that price by also not enforcing the immutability. Haskell took the road of purity, and from that choice naturally arises laziness (strictness is opt-in). Laziness is our best weapon to get back this huge asymptotic complexity we paid.
Then, a lot of people complain about the laziness by default. Part of it is certainly lack of experience, with time they'll reason about it more instinctively as well as exploit it better to their advantage. But more importantly, they don't realize that opt-in laziness, in practice, will never work how they claim it will: we'd just use it here and there, otherwise nearly every API would need a lazy version (if we want opt-in laziness _everywhere_).

The other big thing in haskell is types. I believe this is where haskell suffers the most. Mind you, its
type system is still eons ahead of most other languages. It's just that once you enter type-level land, everything becomes very clunky. Clearly, haskell was never designed to do dependent typing, yet that's what we're trying to reach. I Believe static typing isn't even a debate anymore in the FP community; types and FP kinda became synonymous, and when you look at how many talks are solely about types at ICFP for example, it's hard to deny it. There are so many things we could use types for, so much room for improvements, and Haskell being both popular and bleeding-edge (at the very least friendly towards research and experiments, see linear-haskell, liquid haskell, the 8.0 changes, etc.) it'll stay the language of choice for a little longer when it comes to statically typed functional programming.

Last but not least, performances are really good with GHC, even more so for a language which in appearance (or by reputation) is just academic wankery. It's funny, because today more people use it in the industry than in academia! I really doubt facebook would have picked haskell for their Sigma system if it wasn't as robust as shills make it sound.

>>1712
I think type classes are hard to follow. It's not fun to choose how you want to use the module every time, but it seems better than declaring newtypes anyway when you need a different monoid. Laziness and mutation aren't really important. Infinite sequences are straightforward enough to implement and use in call-by-value that doing it in the language isn't much of an improvement. IO is mostly for the compiler, rather than something informative for the user.

Even though types help explain what a program does, the term refers to completely different things based on context (see Stephen Kell, In Search of Types). I don't see what they're trying to achieve porting more expressive type systems into Haskell. Isabelle/HOL, Coq, and Agda already compile to it.

>>1720
Well, it's pretty clear this discussion won't lead anywhere and will be a waste of everyone's time.
I'll just keep it at clarifying
>Laziness and mutation aren't really important. Infinite sequences are straightforward enough to implement and use in call-by-value
this has nothing to do with streams, actually this, unfortunately, proves the point I was trying to make. I feel like people who clearly have no experience with a purely lazy language like haskell can only imagine laziness useful for streams, IO and memory leaks..
Anyways, mutation is very important to reduce the complexity of your algorithms. Otherwise you always get the worst complexity. The most simple example I can come up with is amortization (if you're unfamiliar with that lookup path compression for the union-find problem). You can't really have that without mutation. You can use a couple lazy tricks to get something similar, though. If you're taking the bet of purity, there's absolutely no reason for also going lazy.