Just started to learn about it, it looks kind cool, but do you guys think it's better than oop?

Just started to learn about it, it looks kind cool, but do you guys think it's better than oop?

Attached: hask.png (512x512, 27.27K)

FP? OOP? Procedural programming?
we have them all

Attached: lisplogo_alien.png (256x150, 20.29K)

>is a programming language better than a programming paradigm

and i oop

Well, is it?

Show me a non-destructive setf and I'm set.

yes

Almost anything is better than the enterprise architecture astronaut style of OOP. I'd even take pure procedural C over that crap.
Regarding Haskell, it's in a weird spot where it has both some amazingly futuristic things and some retarded things. The ultimate judgment is a matter of personal preference. You'll have to learn it and see.

>amazingly futuristic things and some retarded things.
please elaborate
I like haskell personally but I'm always interested to hear a reasonable criticism
overuse of math terms?

IMO the main thing is the module system and having to manually disambiguate imports. Even record fields had to be manually disambiguated until very recent versions of GHC

shitty import system, flaky tooling, strings are linked lists (lol), records used to be painful to use, emphasis on laziness sometimes causes performance headaches, just to name some issues
no language is perfect though. haskell is still overall very good and GHC can shit out surprisingly fast binaries

>Even record fields had to be manually disambiguated until very recent versions of GHC
yeah agree with you there
consequence of haskell treating record fields access as functions and function application, rather than just making it a first class thing which is what basically every language does

>strings are linked lists (lol)
also a good point although you can use -XOverloadedStrings with Data.Text to not have to deal with that in your own code
sucks that String being a list is baked into most of the standard library tho

based
which lisp to use tho?

>-XOverloadedStrings
true, but GHC extensions are a sort of learning curve in their own right. literally every real world project uses at least a few.
haskell is standards-defined on paper but implementation-defined in practice

>rather than just making it a first class thing which is what basically every language does
I understand the sentiment of wanting better records, but the fact that all functions, constructors, values, and records are treated as the same first class construct is one of the best advantages of using FP and Haskell specifically. Allows for very intuitive syntax and function application without having to think about anything other than types. I would much prefer that records stay relatively painful to disambiguate then create a new concept of some either kind of first class entity other than just a simple function.

>please elaborate
>I like haskell personally but I'm always interested to hear a reasonable criticism
Sure. I'm sympathetic to Haskell too, my post was from the perspective of someone who likes the general idea and wishes the details were better.
>overuse of math terms?
Not for me. The willingness to apply an extreme level of abstraction is actually what makes Haskell unique and great. If Haskellers were as reluctant to come up with new, potentially unintuitive abstractions as mainstream programmers are, there would be no reason for Haskell to exist at all.
My complaint is different: that while Haskell does some very valuable envelope pushing in the realm of advanced abstractions, this attention to detail doesn't trickle down into the standard library and the language's ergonomics suck for many simple, everyday programming tasks.
For example, the module system encourages things that we know to be bad practices now. A module declaration exports every symbol by default, and a bare import statement brings in every exported symbol into your namespace.
The usability of records is really disappointing for such a high-level language. This is being addressed with RecordDotSyntax, but it's way too late.
But my biggest complaint is the embarrassment that is the standard library, which feels like an academic toy rather than a practical tool. The default String type butchers performance and memory efficiency, and while you can use a better type, the fact that the standard library uses String everywhere and that there are AT LEAST FOUR commonly used alternatives means that your supposedly high level code will be littered with ugly explicit conversions.
The standard library also lacks basic data types such as a hashmap, treemap and array. This means that rather simple programs which would be self-contained in Python, Java or C# will require a package manager and a wall of imports in Haskell.

cont. A side effect of the above is that while Haskell has an amazing type system, it's generally not used for many types of containers. For example, in Java it's common to use generic interfaces like List or Map to abstract over the particular implementation, while the Haskell equivalents are often specialized to a concrete type. Very disappointing.
These are my main pain points with Haskell. Note that I still like the language, you just asked about the negatives.

>List or Map to abstract over the particular implementation, while the Haskell equivalents are often specialized to a concrete type
could you please explain this to me? Haskell seems to do a very good job of being generic with types. Unless you mean in a specific package or std lib module?

>array.
good point, but hopefully -XLinearTypes means we'll be able to do stuff safely with mutable arrays in the near future without having to resort to a mixture of STArray and Vector
would be nice to have a single array type that's as close as possible to a C/C++ array, and mutable depending on the context rather than making mutable arrays their own type

>non-destructive setf
a what?
>which lisp to use tho?
common lisp

pure lambda calculus

Attached: osidjfosdijfoijf.jpg (1024x640, 97.71K)