Haskell a shit

I don't care if it's slower than C even by 100 times, but if Haskell gives no control over time complexity, it's useless. I refuse to believe that it's useless!

>efficiently update an element of a list
why do you need that? what are you using the list for? are you sure you need it?

But it is user, imperative is truly the only good way to control time complexity

>but if Haskell gives no control over time complexity
it does, what are you trying to do? update an element of a list means nothing when it comes to real problems, why do you want to update an element of a list?

that's like asking how do you append elements in constant time to a C++ vector, vectors are not for that, and i doubt you really need it either way

Have you tried it?

Might not be as bad as you think. I know java 8 can skip a lot of operations in its stream and even reduce complexity if you use the collectors correctly.

Protip is probably to worry less and live more.

>Why would one need to edit data? You don't need that haha
You really got to high on shilling your f*nctional bullshit today brah.

>wait, op! maybe you don't need write sane programs
Is this the power of pure functional programming?

>it does, what are you trying to do?
I just want a data structure that has O(1) updates to random elements, and amortized O(1) appends---Just like you get in imperative languages.

>why do you want to update an element of a list?
what the fuck does it matter?

I shouldn't have said "list". I want a data structure that works like arrays do in imperative languages.

i'm not shilling anything, what actual problem are you trying to solve in haskell? i can help with approaches about what algorithm/data structure you may use to do it efficiently. "efficiently update an element of a list" is a pseudo-problem

>I just want a data structure that has O(1) updates to random elements, and amortized O(1) appends---Just like you get in imperative languages.
if that's what you want use an imperative language

or use mutable arrays
hackage.haskell.org/package/array-0.5.3.0/docs/Data-Array-MArray.html

but you shouldn't be using haskell by that point probably

>>why do you want to update an element of a list?
>what the fuck does it matter?
it matters because you are trying to use haskell in a way that it wasn't designed to be used so it will be clunky. you can still do it if you really want
hackage.haskell.org/package/array

I am not the op. I wouldn't try to solve any problem using Haskell as it is a problem itself.

so? why should i care about your life?

I vaguely recall lenses being used for this?

>or use mutable arrays
>but you shouldn't be using haskell by that point probably
So Haskell is basically useless unless you eschew one of it's key selling points, which is immutability?

I can sort of get the behaviour I want with Data.IntMap, but it just seems retarded.

Do they help with time complexity?

>pseudo-problem
More like X-Y problem probably

It’s not useless. It’s an academic language, like Idris. It’s a testing ground for new developments. Have you ever been to a car show? There are cars there which will never hit the streets. They’re called concept cars and used as proof of concepts.
Haskell’s main use isn’t in the real world industry. Although there are a few very niches where it’s great. But absolutely not as a general purpose language.

wiki.c2.com/?LinearTypes
Wait for linear types ...
Some people tried find type theory allow O(1) insert/update data structures or remove GC for small operations or streamers.

Ocaml,clojure and more functional languages allow single thread imperative code/ mutable datastructures for fast, but haskell muh theory

>So Haskell is basically useless
useless for what? what do you want to do?
>a data structure that has O(1) updates to random elements, and amortized O(1) appends
that is not an actual problem, what do you want to use that for?

>that is not an actual problem, what do you want to use that for?
a problem that'd be trivial in an imperative language:

hackerrank.com/challenges/dynamic-array/problem

yes, a problem designed to teach you an imperative language feature would be trivial in an imperative language, bravo

that's like saying that C is useless because you can't easily implement a generic "foldr" function you can find on some random exercise designed to teach you functional programming

`List` is the wrong datastructure for this task.
in languages like javascript or python they use hashmaps but don't tell the user to speed things up.
you would most likely want to use a hashmap and just ignore the safety aspects
using a vector is also good but you would combine it with `unsafe write` because obviously you get this beahviour only if you are experienced enough to know when and how those mutable references become a problem

midground would be using a `zipper`
it only constant time update (write only updates the element at hand)
but you have to navigate the list, which is also O(1), but only for moving the pointer a single element.
so for a textbuffer where most of the time you only do `insert` and a single `move right` this is constant time.

if you can use zippers, do so!

if it's just a couple of references just do unsafe writes and reads to Handles. `writeIORef ` from Data.IO.unsafe

I could not find a good diagram for zippers, so I'll give a short and easy example.

imagine you would have two stacks and a single element, instead of a list.
on the right stack are the elements to come next.
the single element is the pointer to the current element in the list.
as you move forward through the list you first push the current element on the second stack which holds the previous elements
then you pop the next element and move it to the current element.

e.g.
(A -> B -> C, D, E

>that's like saying that C is useless because you can't easily implement a generic "foldr"
No, it's like saying that any language where you can't do a constant-time operation in constant-time is useless.

>you would most likely want to use a hashmap and just ignore the safety aspects
Wait a minute. I just realised that getting the size takes linear time in the size of the hashmap. Why is it not constant? It seems like implementing it would be trivial, but the Haskell devs decided not to! What the fuck, man? How do I fake an array without constant-time size?

Why do haskell programmers hate performance and low memory use?

Just use Data.Array, it does the exact thing you're asking while not being mutable. I really don't see the problem here

Because if you allow mutable state you lose the benefits of purity. For example, if you allowed mutation of data then Haskell's guarantee to run in parallel without data races would no longer be valid. No one claims Haskell is a systems language and it's primarily a research language.

Can't you just have an ownership system like Rust's and make it so on a type level you're not mutating the array at a distance but consuming it and receiving a new array as a return value, even if internally you really are just mutating the input?

That's somewhat how mutable vectors work in Haskell. You operate on them with a monadic interface and generate a string of operations similar to how the IO monad works. Additionally the type interface means you can't reuse an old reference to a mutable vector.

then use vector

length :: Vector a -> Int

O(1) Yield the length of the vector

just keep in Mind that a lot of languages did get some concepts wrong and they mixed up the words or symbols and the actual meaning.

e.g. most lanuages abuse the "is equal to sign"
x = 3;

because what they actual want to say is "assign"
x

>intensive purposes
brainlet confirmed

>then use vector
Then I don't get constant-time updates.

Anyway, I think I'm done with Haskell for now. I'll check again in 5 years to see if it's usable yet.

>doesn't understand jokes
autist confirmed

Attached: I have given up.jpg (480x480, 85K)