221–230 of 322 posts
Stack's main advantage was that packages (essentially everything, including the compiler if I remember correctly) are installed in project-space, so that two different projects don't conflict, anyway.
Earlier quoted context omitted.
To answer your questions literally without much nuance: Yes, Haskell is viable for production. There are caveats, as with any other language. Haskell has more caveats that most other languages you would be familiar, but it's nonetheless perfectly suitable in the right environment. No, don't use Agda or Idris in production, they're totally unfit. Agda is not intended to be. Idris may be but it will take 5 or 10 years.…
There's ReasonML, which compiles to JS and seems intended for production
Earlier quoted context omitted.
Personally I don't want an IDE, just solid integration with existing editors. I didn't fully understand the power of this until I started working with Rust and VS Code. It's a really first-class experience. Hints and type errors show up so immediately and responsively in the editor with complete contextual information that I can develop essentially an entire library or application without ever running a build once. I…
What you are saying is that you do not want an Integrated DE, just a DE with Integration.
I've never been able to productively use HIE with any editor despite claims here in this thread that it works and is ready for general use. Whenever I have managed to get it mostly working, it breaks as soon as I try to use it with a different Haskell project.
It strikes me that I need to be a mathematician to use Haskell. Especially when someone like Rob Pike makes claims that "I cannot read the syntax of Haskell and understand it."
Earlier quoted context omitted.
I'm the CTO at Mercury ( https://mercury.com/ ) and we have 100% of our backend written in Haskell. It's gone really well so far. Answering another commenter's question, I would say the "secret weapons" are: 1. Hiring: Haskell is a very in-demand language by very good engineers. For a startup, it's absolutely amazing for recruiting and I can't overstate how important recruiting good people is for a startup. 2. Correc…
> 1. Hiring: Haskell is a very in-demand language by very good engineers. For a startup, it's absolutely amazing for recruiting and I can't overstate how important recruiting good people is for a startup. Although for engineers, supply-and-demand favoring employers typically means it disfavors employees: you may effectively be taking a pay cut to use Haskell compared to more popular languages.
As a guy who casually (definitely not in-depth) reviewed working with Haskell about 2 years ago I'd say the most relatable part of the article to me is: complexity in tooling and unnecessary tension when working with libraries. Also the String situation (several types of them). A lot of the other points could be addressed but the community's seeming unwillingness to tackle everyday productivity sends to me the messag…
I find this criticism very bizarre. C++ and C have several different string types, as does python. This comes down to the fact that what programmers think are strings are often not really and vice versa.
To be clear, a 'string' is a sequence of characters or glyphs meant for human consumption or that are produced by a human as input. A string is not a sequence of bytes. C++ and C get this really wrong, and we pretend char* or std::string is actually a string, but they're not -- they're sequences of bytes. The best string in C is wchar* and the best string in C++ is std::wstring or even better a string from the ICU library. std::string completely glosses over the various encodings of real strings.
Python gets the string situation much better. str is for strings, and bytes is for bytes. str can contain actual human characters, and bytes can't (unless you encode a str to bytes properly).
From this perspective, Haskell really has only one string type: Text. ByteString is actually just a sequence of bytes, and it's an accident of history that Roman characters fit into bytes.
String is an iterator over human readable characters, akin to str in python or std::wstring::iterator in C++.
Earlier quoted context omitted.
Is that flag really ever smart to switch on? I've heard StrictData makes a lot more sense but turning Strict on prevents the compiler from making some quite crucial optimizations, resulting in degraded performance.
Which optimisations does it prevent? I've heard laziness prevents a lot of optimisations, because it makes bottom an instance of every type, and the compiler has to account for that.
- GHC can do less unpacking (moving heap allocations to registers)because of laziness
- laziness as an implementation detail is slow
To implement laziness, GHC puts a closure with it's environment on the heap. When the value is used for the first time, the closure is called. Then the result is put on the heap, the closure is replaced with an indirection to the result, and the program continues.
But this also has some advantages:
- For values that might be used zeor or multiple times, this often actually saves time on average over both strict or call-by-name evaluation
- This is faster than any equivalent code you can write by hand because compiler and runtime system heavily optimize around it
- This gives you mutation through the backdoor which allows asymptotic improvements over strict pure languages in some cases
But the main thing is that laziness allows runtime dead code elimination - if you have an unpacked vector of pairs and only use the left element of each pair, only those values will be allocated - still in a dense bytearray.
Does Cabal still have issues with multiple, conflicting versions of packages installed globally? Stack's main advantage was that packages ( essentially everything , including the compiler if I remember correctly) are installed in project-space, so that two different projects don't conflict, anyway.
Earlier quoted context omitted.
I think you are missing a lot of details about when it is wise vs. unwise to rely on generators and coroutines in Python for lazy evaluation. Some of the most common mistakes I see Python beginners make are using list or tuple when they could use a generator instead. Rarely it leads to serious memory consumption issues, more often it just leads to messy list-append-copy style code, which is very forgivable. Some of t…
> not realizing the memory footprint of this can be far, far worse than just materializing the whole list in memory, depending on the situation. you need to reference a particular Python implementation at this point
Earlier quoted context omitted.
I fully grok monads. I’ve done enough reading and usage of them to understand them. They are not a useful abstraction for programming. They’re mathematically correct, but that’s not the same as what an industrial engineer needs. The big warning sign is monad transformers. Alone, monads are totally fine, but the issue is that you rarely want one . So you end up with this unwieldy tower of transformers that would make…
>They are not a useful abstraction for programming. They’re mathematically correct, but that’s not the same as what an industrial engineer needs. Pray tell then, how do you sequentially compose functions operating on values wrapped in an ADT like Maybe or Either?