"the legacy C++" Interesting reading but the author seems intent on pushing some buttons.
Rust as a gateway drug to Haskell
171–180 of 218 posts
Re: Rust as a gateway drug to Haskell
#172The similarities are striking. Both have a problem with undocumented or experimental modules for everyday tasks, both use compiler plugins to make sure that every package is using its own superset of the language (although in Rust this only applies to nightly), both tout lofty goals while rarely producing production grade systems. Rust is the first toe dip into the world of blog posts heralding the"coming of the age…
Yes. Complex languages are not required to solve complex problems. This is why Go and JavaScript are so popular.
Re: Rust as a gateway drug to Haskell
#173Earlier quoted context omitted.
It's not just laziness. Functional programming is what happens to the universe when you eliminate the concept of Time. It is a mega abstraction over the what's really going on under the hood. However we live in the real world and in the real world you cannot eliminate the concept of time, even in an abstraction such as functional programming. Therefore Functional programming is an utter lie. Reasoning about the perfo…
>Functional programming is what happens to the universe when you eliminate the concept of Time. I've heard this a lot but still can't find a good code example to illustrate this. Any help?
Re: Rust as a gateway drug to Haskell
#174Earlier quoted context omitted.
Do you have source code? It sounds like you were writing unidiomatic Haskell.
I actually posted the port on the Code Review SE, where (after almost a month of silence), someone stepped up and offered a CFFI solution. https://codereview.stackexchange.com/questions/157118/a-port...
As was pointed out, GHC is calling getCurrentTime too often. If you take advantage of GHC's laziness, the value will stay valid longer. I assume that is what fast-logger does.
Re: Rust as a gateway drug to Haskell
#175Earlier quoted context omitted.
Mutable hashtables: https://hackage.haskell.org/package/hashtables Mutable arrays: https://hackage.haskell.org/package/vector-0.12.0.1/docs/Dat... Strict by default: Put {#- Language Strict #-} at the top of files where necessary but usually you'd just use bangpatterns and unbox-strict-fields.
Well, these are mutable, but only in the ST or IO monad - which is a guarantee, but at the same time it is not quite the same thing. You cannot just accumulate state by mutating some stuff, then in a separate part of the program mutate it again. Which is intentional, of course, but quite opposite to the imperative mindset. About {#- Language Strict #-}, thank you - I was not aware of it. I think the first example in…
I think the first example in that post is a bit unfair. The Haskell code is unusually complicated because it avoids a complicated problem that exists in the C code. (Which is that 16-bit encodings can't cover all of UCS-4 with fixed character widths.)
Besides, I don't understand why they are making such a complicated solution. In this comparison [1], the first example in that post is the "target". The best performing solution is... you guessed it:
foldZip a b =
List.foldl' (\r (cha, chb) -> if cha /= chb then r+1 else r) 0 (Text.zip a b)
And a pet peeve: the way you say "only in the ST monad" is a funny rhetoric device. You make it sound like everyone agrees it's a bad thing to isolate mutation to local regions. Here's the thing: it's not. And the way you can integrate local mutation in your application with the ST monad is fantastic.By just typing "ST" a few extra times you get local mutation exactly where you want to, and nowhere you don't want it!
Re: Rust as a gateway drug to Haskell
#176Earlier quoted context omitted.
What is it lacking for imperative programming? I find it to be immensely good at it!
I tried implementing some simple imperative algorithms (like union-find) and found the Haskell code very noisy. For example, "var x = f(y)" in an imperative language might translate to "let x = f y" or "do x <- f y" in a Haskell do block, and the wrong variant won't compile. There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Writing code that mixes…
Well, yes, there is: general recursion. You can recreate any loop with plain old recursion.
But stating that as a problem is a little like coming to Java and saying that "there's no general purpose idiom you can use to replace goto, only tons of special semantic branching constructs you must memorize." Sure, a valid complaint if you've been forced to only use goto in your life, but not a reflection on good programming practise.
Re: Rust as a gateway drug to Haskell
#177Isn't the most significant line: "For work-related reasons, I had to recently get up to speed on programming in Haskell"? I was somewhat disappointed not to have a followup to what work-related reasons there might be. Note also that the About page says "work at Facebook".
Re: Rust as a gateway drug to Haskell
#178Earlier quoted context omitted.
>Functional programming is what happens to the universe when you eliminate the concept of Time. I've heard this a lot but still can't find a good code example to illustrate this. Any help?
The statement makes no sense. See FRP for a take on how to handle time-varying behavior.
Re: Rust as a gateway drug to Haskell
#179Earlier quoted context omitted.
It's not just laziness. Functional programming is what happens to the universe when you eliminate the concept of Time. It is a mega abstraction over the what's really going on under the hood. However we live in the real world and in the real world you cannot eliminate the concept of time, even in an abstraction such as functional programming. Therefore Functional programming is an utter lie. Reasoning about the perfo…
>Functional programming is what happens to the universe when you eliminate the concept of Time. I've heard this a lot but still can't find a good code example to illustrate this. Any help?
Re: Rust as a gateway drug to Haskell
#180I wonder if Idris could some day take Haskell's place. It sports default eager evaluation. Seems like the tooling (package managers etc.) isn't quite there yet, though.
Is a difference in a default option really enough for a language to take the place of another? And if it's not just a change in a default option, but the removal of laziness, we lose something, which will make the choice less obvious. I think it's more likely that, if dependent types prove really useful, Haskell will adopt these, and people will adapt their code, rather than port everything to a new language. As far…
What would we exactly lose?
>As far as I can see, Idris is too much like Haskell to take its place. Porting thousands of libraries to a new language is a huge effort, so a huge advantage is required, which I don't see Idris offering.
That is true, though. Perhaps Rust is the safer bet, even if it lacks many nice things. The sum is probably quite a lot better still.