sfvisser

25 ms·

271.
by sfvisser 11y ago
> Trying to debug a memory leak caused by insufficient strictness --- why do I need to care about this? The runtime should just take care of it for me; the whole point of a lazy language is that I shouldn't have to care when evaluat
272.
by sfvisser 11y ago
> The benefit of proofs in code would only be worthwhile if it was relatively easy for common programmers to prove the absence of bugs that would have been more costly to find and fix using other methods, and that that ease would not com
273.
by sfvisser 12y ago
> Too bad Haskell is such an impractical language. When does this nonsense ever stop?
274.
by sfvisser 12y ago
No we usually don't deploy in weekends. Only if we break stuff just before the weekend. :)
275.
by sfvisser 12y ago
Yes, but with the same syntax you could have written '\x -> b x', changing that assumption entirely.
276.
by sfvisser 12y ago
>Honestly I think the differences in that example are pretty superficial. For most instances the difference is superficial, but for some problem domains the difference can have a pretty big impact. All of this is because Applicative comp
277.
by sfvisser 12y ago
It's not entirely right to call this a misconception. The monadic bind is inherently sequential. The right hand side of the bind might compute a computation based on the result of the left hand side of the bind.
278.
by sfvisser 12y ago
This isn't true. They are absolutely not the same and don't yield the same behavior for every monad/applicative pair. First, you probably meant: do x <- a y <- b return (x + y) -- not: a + b Wit
279.
by sfvisser 12y ago
> I don't understand why this is an issue, there are tons of great tutorials: ... > Don't be afraid to use libraries such as jQuery, ... So, bad specs are not an issue because there are tutorials explaining how to use them a
280.
by sfvisser 12y ago
Much easier to read to who? Not to me at least. Code readability is subjective and depends on experience and familiarity.
281.
by sfvisser 12y ago
> static typing is for example by definition anti-modularity and anti-adaptability This is so painfully wrong. Static types are not in the way of modularity and type correct programs are not hard to adapt to another type correct program.
282.
by sfvisser 12y ago
I think your comments are valid and I mostly agree very much with this sentiment. Thank you for sharing. But let's look at it differently. This framework has been developed and shaped over a few years in a corporate environment by a sm
283.
by sfvisser 12y ago
> I kind of feel less confident about the choice around `rest` since there are many interpretations and implementation choices which may lead to a desire for competition here. I feel the same about lens :) Note that we didn't even u
284.
by sfvisser 12y ago
It could, but would be extremely messy. We think hs-src-exts is really the right tool for the job here.
285.
by sfvisser 12y ago
Really doesn't matter, the target audience will either use Hackage (Haskell's package database) or will prefix Haskell to their search term.
286.
by sfvisser 12y ago
Interesting 'triple' they use :) // Our triple struct, used throughout. type Triple struct { Sub string `json:"subject"` Pred string `json:"predicate"` O
287.
by sfvisser 13y ago
The ideas here are similar in a sense. I'm not an expert on Angular, but their focus seems to be on templates that update automatically using data bindings. Our framework focuses more on compositionally of reactive data networks, conne
288.
by sfvisser 13y ago
Fixed, thanks!
289.
by sfvisser 13y ago
Inspired by the client side FRP library we use internally, I've build a small Haskell version as well: https://gist.github.com/sebastiaanvisser/9639321 Although the implementation is different, I tried to keep the
290.
by sfvisser 13y ago
Haskell too much syntax? That's a very weird claim. Haskell's syntax is one of the leanest around. You could even argue the lack of syntax can be confusing sometimes. Beginners often mix up types, patterns and expressions, because
291.
by sfvisser 13y ago
Why the 'but'? There seems to be quite some type theory involved in Sage.
292.
by sfvisser 13y ago
Even when this is true, this special case of static typing gives you exactly none of the advantages of general static typing.
293.
by sfvisser 13y ago
Nice job! Seems you could have put the TypeEnv in a ReaderT as well, might make things slightly easier.
294.
by sfvisser 13y ago
> This is missing a key term: "in scope." True, of course. Sometimes I wish Haskell would have made shadowing variables into a compile error. Shadowing is the number one reason that substitution doesn't always work like yo
295.
by sfvisser 13y ago
> ...I don't see myself using much Haskell precisely because its tools for modularity seem limited. > Dynamic languages are naturally more modular Why is that? I'm pretty convinced pure and especially lazy languages allow fo
296.
by sfvisser 13y ago
More of a programming than a CT introduction, but very useful nonetheless: Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (1991), by Erik Meijer, Maarten Fokkinga, Ross Paterson
297.
Programming Haskell doesn’t require any category theory(fvisser.nl)
1 points by sfvisser 13y ago|0 comments
298.
by sfvisser 13y ago
I still think it's truly awesome that I can just hapilly write my code in Haskell on a very high level, while in the meantime other people will hack on the compiler and core libraries and magically make my programs run faster! Seriousl
299.
by sfvisser 13y ago
It's a trade-off. You can either use direct mutation using some sort of impure reference type, or use a pure mutation using first class accessor labels. Impure references are probably easier to use, but are harder to reason about and a
300.
by sfvisser 13y ago
Nice writeup. Although I really like the fact that lenses (from the `lens` package) can be composed using regular function composition, instead of the more generalized category composition like `fclabels` uses, I still think it's weird

More ›