131–140 of 208 posts
I just prefer to use languages without a Garbage Collector.
And spend time tracking down memory corruption?
Earlier quoted context omitted.
The IO monad doesn't involve actually recording anything...it's not like MVCC. What are you actually trying to say here?
It's that a monad looks pure, but actually isn't. Call addition with the same args and you should get the same answer. Calling next on a stream of io is destructive.
next :: Stream a -> IO a
Earlier quoted context omitted.
It's more complicated than that. Monads don't make a language more powerful, but they are an absolute necessity given Haskell's design, which is built around extensional/value semantics, which basically approximates a program/subroutine as the function it computes; this is a useful approximation as it lets us treat computations as if they were referentially transparent. That approximation has a cost, though, as compu…
It's not really Monads making the language more powerful. It's the taking away of non-pure primitives and libraries -- and replacing those with type-labeled effects. That these effects are composed monadically is a minor detail and unfortunately the thing that's emphasized. Haskell gains power in its framework for restricting code. In Haskell, you can know so much about what code doesn't do -- and that's what makes H…
PFP and typing are quite orthogonal. You can have effect systems in non-PFP, continuation-based languages (i.e. languages that don't equate computations with functions). You can have non-pure, non-monad-based type-labeled effects.
> Haskell gains power in its framework for restricting code.
Sure, but Haskell does this within a very specific design, based on extensional functional semantics. There are other ways of restricting what code can or cannot do that don't have the same semantics. Personally, I think that various effect systems may hold promise and are certainly interesting enough to try, but the PFP abstraction has so far failed to yield results commensurate with its cost.
Haskell, like Perl, is optimized towards writing code rather than reading code. I would like a language which is to Haskell what Python is to Perl.
Being able to read code is great (e.g. Python), but if you can't change things without fear the natural tendency of the codebase won't be in a good direction.
Haskell can actually take a while on the first write, but once you have the rails of the type system down it's sooooo easy to change things, even in a codebase you're new to or haven't touched in a while.
Earlier quoted context omitted.
Incidentally, this is why prefix notation seems so foreign. (+ 1 2) reads as "plus one two." It might just be the Lisp version of Stockholm Syndrome, but it seems perfectly natural to me to gloss that as "Add one and two."
Good point. (eq (+ 1 2) 3) would read "is add one to two equal to three?" though.
EQ is object sameness. Number objects of the same value are not necessarily the same object.
Haven't seen it listed neither here nor there, so not sure if I'm the only one, but: for me, the first and currently blocking obstacle is of "graphical" syntax. I'm of the kind of people who hear the words they read as a voice in their head, so when every line is interspersed with multiple "random" >>= -,-'-- and whatnot other ascii-art I can't verbalise, I distictly feel my brain stumble, mumble, and grind to a halt…
Earlier quoted context omitted.
It's not really Monads making the language more powerful. It's the taking away of non-pure primitives and libraries -- and replacing those with type-labeled effects. That these effects are composed monadically is a minor detail and unfortunately the thing that's emphasized. Haskell gains power in its framework for restricting code. In Haskell, you can know so much about what code doesn't do -- and that's what makes H…
> It's the taking away of non-pure primitives and libraries -- and replacing those with type-labeled effects. PFP and typing are quite orthogonal. You can have effect systems in non-PFP, continuation-based languages (i.e. languages that don't equate computations with functions). You can have non-pure, non-monad-based type-labeled effects. > Haskell gains power in its framework for restricting code. Sure, but Haskell…
They are orthogonal in 1 technical sense. But the benefits are reaped from the combination.
> the PFP abstraction has so far failed to yield results commensurate with its cost.
You say this based on what? Me and other Haskell users believe that the costs are very minimal and the benefits are quite huge.
Haskell has 3 major problems that are completely distinct in my opinion. Biggest technical problem: lazy evaluation. Other people have said more than enough here. Biggest cultural problem: technical oneupmanship and code golf. Haskellers can get so caught up in no-compromises stylistic competition that it makes it hard to get anything done. If you finally finish up something that accomplishes your goals, your teammat…
> They rant against and mock everything deemed inferior. They treat people like they're idiots for not understanding basic but unfamiliar principles of the language. And nobody ever seems to shut them down, despite the fact that the majority are pretty welcoming. I'm happy to try to shut them down but I've pretty much never seen it (perhaps because I'm not in those other communities). If you do, please point me to it…
Bryan Cantrill's take: https://youtu.be/0T2XFSALOaU?t=2021 My answer would be lazy evaluation by default. It's extremely unusual, and I've never seen a convincing enough justification for it, and it gives rise to performance bugs (space leaks) that can be fiendishly difficult to track down and fix and are disastrous in production. With the arrival of Idris, I think we can pretty conclusively say this was a mistake an…
My perspective on this is that lazy be default made sticking to purity much more compelling as if you just dropped print statements in you weren't sure exactly when they get evaluated. This lead to important developments like IO (they started with user input just being a lazy list! Very possible to accidentally block trying to read too much), which might not have happened otherwise. But now, I do feel like lazy is be…
https://ghc.haskell.org/trac/ghc/wiki/StrictPragma is coming in GHC 8.
I just prefer to use languages without a Garbage Collector.
Man! I'd never want to code in language that forces me to manage memory. A boring, solved problem the compiler/run time should handle for me.